Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
draft-ietf-mmusic-ice-19

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 4.1.1.1., 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.)

  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.