Subject: [MMUSIC] updated ICE spec

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Oct 2004 02:00:05 -0400

Folks,

I submitted an updated ICE spec yesterday. Until it appears in the 
archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-03.txt

This is a fairly sizeable revision, but much of it is cleanup and 
addition of further clarification material. A lot was also the "dotting 
of the i's and crossing of the t's" - completion of IANA registrations, 
adding diagrams, added explanatory material for call flows, etc.

We're currently debating on the list what I think the main issues are - 
how/when to do the checks - STUN vs. other things, mid-call vs. not. -03 
proposes a specific resolution which is consistent I think with some of 
the recent threads, but we should debate that furhter. Beyond that, I 
believe we have resolved issues discussed in the past. I've sent a 
summary of how past open issues were resolved, including responding to 
several older emails with comments and issues.

Please raise any furher issues or comments to the list.

Below is a detailed list of diffs from -02 to -03:

* changed name of "alt" SDP attribute to "candidate" to avoid conflict with
3gpp attribute of the same name.

* removed derived-from SDP attribute, as it is no longer used

* changed username SDP attribute component to user-frag

* updated XML schema for ICE messages to allow both an IPv4 and IPv6
default.

* updated the mapping procedures for ICE to SDP based on the new
schema and SDP attribute definitions

* noted how performing the address gathering while the user is being
alerted, or upon entry of the user into the address book or buddy
list, can reduce call setup times

* changed TURN and STUN for the purposes of unilateral allocation to
SHOULD implement from MUST. Added a long-winded and ranting paragraph
on why you really, really to think hard before violating that SHOULD.

* allow, at MAY strength, other protocols for creating derived
transport addresses

* added requirement that password have 128 bits of randomness, and
that protocols that do ICE must provide and should use encryption and
integrity services. In the case of SIP, made sips usage a SHOULD,
SMIME a MAY. Passwords have to differ for each media stream for each
session. Usernames are just unique per transport address.

* added text describing Pete's scenario where a stun connectivity
check is received by the wrong host.

* removed mid-session connectivity checks, resulting in adjusted FSM.

* STUN service needs to only run until a media packet is received; at
that point you can safely switch to media-only operation

* added discussion on selecting of default address. Note that
TURN-based address from a public relay won't always work. Describe a
case where it won't, but still RECOMMEND to use such an address. Add a
note on deployment considerations to obviate this, by deploying ICE to
communities in whcih joint communications is common (i.e., do the
whole enterprise).

* adjusted algorithm that runs on receipt of stun requests,
simplifying the case where a new candidate address is learned

* added pictures to describe turn derived stun addresses

* added basic ice model call flow for tutorial purposes

* previously, a client obtained local transport addresses and then
both used those in its SDP, in addition to deriving perhaps several
derived transport addresses from it. No longer. No, there is a single
local transport address for each derived transport address, and that
local transport address is never advertised in ICE. This turned out to
be needed to figure out whether the local stun service could be turned
off when an RTP packet is received. Unfortunately it also required me
to introduce more terminology to describe.

* added a section on application layer keepalive issues. Namely, how
to deal with "RTP on hold". This basically replaces the STUN-based
connectivity checks

* removed concept of sourceable addresses; it fell away with the above
change where different local transport addresses are used to obtain
each derived transport addresses.

* if a gathered transport address is equal to a local transport
address, use that local transport address

* rewrote security considerations section, which was wrong. Focus on
showing how the attacks present in "regular stun" are completely
eliminated with ICE

* updated and simplified example and filled in textual description

* added discussion on handling of re-invites in SIP; the technique
allows for connectivity checks to be redone by changing the username
fragment. Otherwise, a re-invite where the SDP has not changed has no
effect.

* filled in details of IANA registration of the candidate
parameter. Added registrations of the XML namespace and schema.

* fixed incorrect assumptions on 6to4 behavior in IAB considerations

* moved TURN to a normative reference

* added missing space between RTP and RTCP information in SDP
attribute grammar

* removed stale derived-from SDP field

* RTCP information is optional in ICE now

* provided sample algorithm for selecting username fragments

* justify the inclusion of the id component of the candidate attribute

* specify what to put in the CHANGED-ADDRESS element in a STUN
BindingResponse.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Awais Ali <[email-masked]>
Date: Tue, 26 Oct 2004 15:33:24 -0700

> to introduce more terminology to describe.
If I understand correctly to fulfill this requirement a device that uses 
both TURN and STUN and is starting an RTP/RTCP session will open six 
sockets(3 for RTP and 3 for RTCP) and run a STUN server on each of them

The advantage of this approach as you mentioned is that the STUN service 
can be stopped when an RTP packet is received. What will be the downside 
of keeping the STUN service running?

Thanks,
Ali Awais

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Oct 2004 13:32:29 -0400

inline.

> sockets(3 for RTP and 3 for RTCP) and run a STUN server on each of them

Yes.

> can be stopped when an RTP packet is received. 

Right. Let me explain why you need this.

Lets say I have a local socket S1 listening for UDP packets. I use STUN 
and TURN to derive two additional address/port pairs for that socket. I 
send them out in an invite. THere is one stun server listening on S1. My 
peer in the call will perform connectivity checks to *all three* 
address/port pairs, all three of which will be stun requests against the 
single server on S1. Now, S1 gets an RTP packet. Presumably, this is 
because at least one connectivity check has succeeded for the peer. 
However, it has three connectivity checks to do, all three of which are 
against the same socket, all three of whicih, if successful, could 
result in an RTP packet being received on that socket. Unfortunately, I 
cannot tell from the RTP packet alone *which* of these three checks has 
succeeded and thus generated an RTP packet. As a result, there is no way 
for me to know if I may still get valid STUn requests which need to be 
checked in order for connectivity checks to continue.

With TURN, you can sort-of guess by looking at the source address of the 
packet, and if that is the TURN server, you know that the RTP was sent 
to the TURN derived address. But, with STUN derived addresses this won't 
work.

By maintaining a single socket, single server, single username, single 
password, single advertised address model, this problem went away 
(receipt of an RTP packet on a socket means that connectivity was 
established to the one transport address advertised for that scoket). It 
also simplified other parts of the protocol.

Now, I well recognize that there is a cost to this in terms of socket 
resources. I concluded that in practice it didnt look like an issue, but 
it is something to take note of, and I welcome broader feedback on this 
point.

What will be the downside
> of keeping the STUN service running?

If you keep it running, you need to specify what happens when these 
checks fail, specify the periodicity of the checks, worry about 
congestion control for them. Its interesting to note that these are very 
much application layer (i.e., rtp and payload format) kinds of issues 
generally. Furthermore, folks have complained about the difficultty in 
demuxing RTP/STUN perpetually. With this approach, a socket starts stun 
only but waits for an RTP packet, and when one arrives, the socket 
becomes RTP only. There were some on the list who favored this.

If you ake it optional about whether it runs or not, you need to solve 
some negotiation problems as I described in another note.

-Jonathan R.

---

From: Awais Ali <[email-masked]>
Date: Wed, 27 Oct 2004 15:09:41 -0700

Jonathan Rosenberg wrote:

>>
>> The advantage of this approach as you mentioned is that the STUN 
>> service can be stopped when an RTP packet is received. 
>
>
> Lets say I have a local socket S1 listening for UDP packets. I use 
> STUN and TURN to derive two additional address/port pairs for that 
> socket. I send them out in an invite. THere is one stun server 
> listening on S1. My peer in the call will perform connectivity checks 
> to *all three* address/port pairs, all three of which will be stun 
> requests against the single server on S1. Now, S1 gets an RTP packet. 
> Presumably, this is because at least one connectivity check has 
> succeeded for the peer. However, it has three connectivity checks to 
> do, all three of which are against the same socket, all three of 
> whicih, if successful, could result in an RTP packet being received on 
> that socket. Unfortunately, I cannot tell from the RTP packet alone 
> *which* of these three checks has succeeded and thus generated an RTP 
> packet. As a result, there is no way for me to know if I may still get 
> valid STUn requests which need to be checked in order for connectivity 
> checks to continue.
>
Ok I understand that it is not possible to determine from the RTP packet 
which connection was used. Why can we not use the Giveup timer to 
determine when the client has stopped its connectivity checks?. If a 
maximum Giveup-time is specified, a peer can stop its STUN server, 
Giveup-time after receiving the first RTP packet.

Ali