Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
Note: This ballot was opened for revision 19 and is now closed.
(Jari Arkko) (was Discuss) Yes
(Lisa Dusseault) Yes
(Cullen Jennings) Yes
(Jon Peterson) Yes
Magnus Westerlund Yes
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lars Eggert) (was Discuss) No Objection
There were some bug fixes to -17 by Adam Fisk and others on the MMUSIC list that JDR said he'd include - is an RFC Editor Note with those missing? Is the plan to have this go to "revised ID needed" to incorporate these? There was a comment on the MMUSIC list about the length of username fields: "I am not sure 1023 character long username are that great really. For a start, after concatenation (2047 characters), you'll get connectivity checks that exceed the typical Internet MTU." Has that been resolved? (What is the max. size of connectivity check packets, anyway?) Should something be said about how ICE interacts with standard source address selection (RFC1122, RFC3484) for the media flows? Doesn't using ICE circumvent those standards? Section 188.8.131.52., paragraph 1: > protocol. Procedures are specified here for UDP. Does "here" mean "the remainder of this document?" If so, please state this much more prominently. Finally, with ICE now being pushed as a more general middlebox traversal scheme (cf. the discussion of using ICE for HIP), it would have been good to refactor this specification, extracting the media-, SIP- and RTP-specific pieces into a different document. The current description of ICE is so intermingled with RAI-specific stuff that it is not obvious as to which mechanisms need to be extracted to use ICE outside that application area. (I do understand that another major rewrite is the last thing the authors want to do at this point - but I fully expect one to be required before non-RAI folks can easily adapt ICE for their purposes.)
(Sam Hartman) (was Discuss) No Objection
(Russ Housley) No Objection
Comment (2007-08-16 for -)
From the Gen-ART Review by Christian Vogt Section 2.6, 1st paragraph: > > ... However, it is possible that packet losses will cause a higher > priority check to take longer to complete. In that case, allowing > ICE to run a little longer might produce better results. > Saying "a packet loss" rather than "packet losses" could avoid confusion. A reader might otherwise wonder why running "a little longer might produce better results" if it would mean that a high-packet-loss path gets eventually chosen. In Security Considerations, Section 18.5.2, "STUN Amplification Attack", explains that ICE candidate probes could be used for amplified flooding: > > It is impossible to eliminate the amplification, but the volume can > be reduced through a variety of heuristics. [...] > A reader might at first glance wonder why the amplification could not be avoided by requiring the initiator to send a separate request per response. For example, this is done in Mobile IPv6 route optimization where a mobile host sends out two initialization messages that each prompt the peer to send a single response message. It might be valuable to note in section 18.5.2 that a "balancing" of the number of request and response messages is not possible in the case of ICE because the initiator does not know the number of responses at the time it sends the request. In ICE, the number of responses depends on both the initiator's and the responder's set of IP addresses. Section 2.1, 1st paragraph: > > ... In all cases, such a network interface appears to the agent as > a local interface from which ports (and thus a candidate) can be > allocated. > s/ports (and thus a candidate)/a port (and thus a candidate)/ ... or plural in both cases. Section 2.1, 2nd paragraph on page 11: It seems that "local interface Y" should be "local IP address Y" because only the IP address is relevant for connectivity, not the interface. And, an interface may have multiple IP addresses, of course.