Subject: [MMUSIC] updated ICE and ICE-TCP specs

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Oct 2005 17:59:18 -0400

Folks,

I've just submitted an update to the ICE spec, along with a new draft on 
TCP extensions to ICE (extracted from the main ICE spec per agreement at 
the last IETF meeting). Until they appear, you can pick them up here:

http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-06.txt
http://www.jdrosen.net/papers/draft-rosenberg-mmusic-ice-tcp-00.txt

I put a lot of effort into ICE this time, more than any other revision I 
have done. Thats because I wanted to bring it to the point of being 
done, and I now believe its there. There are no issues I know of, and 
the previously missing pieces, like security considerations and example, 
are all in there, including the largest call flow example I have ever 
done (23 pages!). Terminology is filled in and complete. I had some 
colleagues review an early draft to catch bugs and issues, and that has 
led to, what I think, its a pretty solid document at this point.

Here is a list of the changes:

* extracted TCP. Restructured the document so parts that were
transport independent were more separated from parts that were
transport specific. Call out the places where behavior is UDP
specific.

* TCP fits in much more naturally now; its done by having the tcp
connections learned through the peer derived candidate mechanism in
ICE

* added password back to a=candidate. It was my error for removing it from
the last draft. Its needed.

* added a=candidate extensibility

* added massive call flow example that shows off the most complicated
parts of ICE - learning peer-derived candidates, connectivity checks
over TURN relays, and usage of the a=remote-candidate attribute. 23
pages, 73 messages.

* completed security considerations section, including brief
documentation of the voice hammer attack

* improved state machine picture

* lots of work on terminology and clarity, filled out the definitions
section completely, made several passes through the document for
consistent terminology usage

* removed extra SP at end of grammar for candidate attribute

* defined keepalive behavior more generally, covering non-ICE endpoint
behavior as well. For non-ICE, mandate sending in a format supported
by peer which is conducive to keepalives, and list no-op and comfort
noise as examples; choice of which is a matter of local
implementation.

* TURN allocations only happen from a single local candidate

* Allocations are paced out at a rate of a new STUN or TURN
transaction every 50ms (configurable). An upper bound on the total
number of allocations is defined (10 is recommended), and the
allocations are ordered based on priority. When a candidate is
validated, you do an updated offer and cease any further checks.

* Defined the a=remote-candidate attribute. This is used to eliminate
a race condition pointed out by Magnus. A sends an offer to B, B sends
an answer to A. B sends a STUN request to A for some candidate pair C1. A
gets this, sends a response. A sends a request to B, gets a
response. As far as A is concerned, the candidate pair is valid, so it
sends an updated offer. However, B hasn't gotten the stun response
yet. So, it doesnt know what candidate is valid with the one in the
m/c-line of the offer. The a=remote-candidate attribute tells it which
one to use

* Stun chekcs are also paced at out once every 50ms. Each side paces
out checks at 1/Ta. However, on receipt of a request, a request is
sent for the same transport address pair right away. This improves
responsiveness. It makes the total rate of checks from one agent equal
the sum of the values of Ta for each agent.

* added the concept of a component. RTP and RTCP are the two
components of an RTP-based candidate. Each candidate has a candidate
ID, and each component has a component ID, starting at one and incrementing
by one. The concatenaion of the candidate ID and component ID,
separated by colon, form the
tid. This is the transport group concept Magnus had posted about. SDP
grammar updated to reflect this

* allow for differing numbre of components in candidates for the same
media stream, within a single offer and answer, and between
agents. Connectivity is only checked against those that match.

* RECOMMENDED that for RTP, there are two components per candidate -
RTP and RTCP. RTP always has to have component ID of 1.

* changed addr production in grammar to reference rfc3266, allowing
IPv6 support

* changed candidate-id grammar to base64, to allow fewer characters
needed for 128 bits of randomness, and to allow easy generation from
128 bit integers

* removed discussion of interactions with connectivity precodntions;
this is discussed in the preconditions draft

* added discussion around which SIP messages to use for the
offer/answer exchanges. Recommend usage of RFC 3262 and 3311 (PRACK
and UPDATE) with ICE, allowing the entire ICE process to occur before
the user even answers the call. This eliminates any additional
post-pickup delays. Early media may clip though unless preconditions
are additionally used. Also discuss procedures for endpoints that
don't support PRACK or UDPATE, in which case the answer is sent in an
unreliable 18x, allowed connectivity checks to take place while the
phone is ringing. Recommending retransmission of the 18x until stun
binding responses are received.

* Eliminated usage of the 430 to retry the Binding Request in order to
deal with the answer/Binding Response race condition. Instead, the
offerer just sends a Binding Response immediately as long as the top
part of the USERNAME matches a local candidate. Then, when the answer
comes, it updates the state machines. This reduces network traffic,
eliminates a timer that would otherwise need to exist and be tuned
(the Tg timer), and improves speed of ICE negotiations

* Now, 430 is an error condition, and happens when I get a binding
request with a username I dont recognize at all. This causes the
candidate to become invalid as far as the other side is concerned.

* Clarified that, when you get a connectivity check over a TURN
derived transport address, the "source IP&port" that gets populated
into the MAPPED-ADDRESS of the Binding Response is the source IP and
port when it arrived at the turn relay, not after it was forwarded to
the client.

* Added discussion on using a=inactive to skip selection of an initial
active candidate. You'd do this if you are worried about glitches in
the jitter buffer, and would rather start sending media only once the
final candidate has been selected by ICE. Doing this is MAY.

* changed the way in which candidate ordering is done in cases of
equal priority; when it happens, ordering is based on REVERSE
lexicographic order. Turns out this actually has security benefits,
because it prefers peer-derived candidates over their generating
pairs, and its harder to fake a peer derived candidate than it is a
stun-derived one.

-- 
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