[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-rosenberg-mmusic-ice-tcp) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 6544

MMUSIC                                                      J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: April 26, 2007                                 October 23, 2006


    TCP Candidates with Interactive Connectivity Establishment (ICE
                      draft-ietf-mmusic-ice-tcp-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Interactive Connectivity Establishment (ICE) defines a mechanism for
   NAT traversal for multimedia communication protocols based on the
   offer/answer model of session negotiation.  ICE works by providing a
   set of candidate transport addresses for each media stream, which are
   then validated with peer-to-peer connectivity checks based on Simple
   Traversal of UDP over NAT (STUN).  ICE provides a general framework
   for describing alternates, but only defines UDP-based transport
   protocols.  This specification extends ICE to TCP-based media,
   including the ability to offer a mix of TCP and UDP-based candidates



Rosenberg                Expires April 26, 2007                 [Page 1]


Internet-Draft                     ICE                      October 2006


   for a single stream.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Sending the Initial Offer  . . . . . . . . . . . . . . . . . .  5
     3.1.  Gathering Candidates . . . . . . . . . . . . . . . . . . .  5
     3.2.  Prioritization . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Choosing In-Use Candidates . . . . . . . . . . . . . . . .  8
     3.4.  Encoding the SDP . . . . . . . . . . . . . . . . . . . . .  8
   4.  Receiving the Initial Offer  . . . . . . . . . . . . . . . . .  8
     4.1.  Forming the Check Lists  . . . . . . . . . . . . . . . . .  8
   5.  Connectivity Checks  . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Client Procedures  . . . . . . . . . . . . . . . . . . . .  9
       5.1.1.  Sending the Request  . . . . . . . . . . . . . . . . .  9
     5.2.  Server Procedures  . . . . . . . . . . . . . . . . . . . . 10
   6.  Concluding ICE . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Subsequent Offer/Answer Exchanges  . . . . . . . . . . . . . . 10
     7.1.  Generating the Offer . . . . . . . . . . . . . . . . . . . 10
     7.2.  Receiving the Offer and Generating the Answer  . . . . . . 10
     7.3.  Updating the Check and Valid Lists . . . . . . . . . . . . 11
   8.  Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Sending Media  . . . . . . . . . . . . . . . . . . . . . . 11
     8.2.  Receiving Media  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Connection Management  . . . . . . . . . . . . . . . . . . . . 12
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     13.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15
















Rosenberg                Expires April 26, 2007                 [Page 2]


Internet-Draft                     ICE                      October 2006


1.  Introduction

   Interactive Connectivity Establishment (ICE) [6] defines a mechanism
   for NAT traversal for multimedia communication protocols based on the
   offer/answer model [2] of session negotiation.  ICE works by
   providing a set of candidate transport addresses for each media
   stream, which are then validated with peer-to-peer connectivity
   checks based on Simple Traversal of UDP over NAT (STUN) [1].  ICE
   provides a general framework for describing alternates, but only
   defines procedures for UDP-based transport protocols.

   There are many reasons why ICE support for TCP and TCP/TLS is
   important.  Firstly, there are media protocols that only run over TCP
   or TCP/TLS.  Examples of such protocols are web and application
   sharing and instant messaging [9].  For these protocols to work in
   the presence of NAT, unless they define their own NAT traversal
   mechanisms, ICE support for TCP and TCP/TLS is needed.  In addition,
   RTP itself can run over TCP [4] and TCP/TLS [5].  Typically, it is
   preferable to run RTP over UDP, and not TCP or TCP/TLS.  However, in
   a variety of network environments, overly restrictive NAT and
   firewall devices prevent UDP-based communications altogether, but
   general TCP-based communications are permitted.  In such
   environments, sending RTP over TCP or TCP/TLS, and thus establishing
   the media session, may be preferable to having it fail altogether.
   With ICE, agents can gather UDP, TCP and TCP/TLS candidates for an
   RTP-based stream, list the UDP ones with higher priority, and then
   only use the TCP-based ones if the UDP ones fail altogether.  This
   provides a fallback mechanism that allows multimedia communications
   to be highly reliable.

   The usage of RTP over TCP is particularly useful when combined with
   the STUN relay usage [7].  In that usage, one of the agents would
   connect to its STUN relay server using TCP, and obtain a TCP-based
   allocated address.  It would offer this to its peer agent as a
   candidate.  The answerer would initiate a TCP connection towards the
   STUN relay server.  When that connection is established, media can
   flow over the connections, through the relay.  The benefit of this
   usage is that it only requires the agents to make outbound TCP
   connections to a server on the public network.  This kind of
   operation is broadly interoperable through NAT and firewall devices.
   Since it is a goal of ICE and this extension to provide highly
   reliable communications that "just works" in as a broad a set of
   network deployments as possible, this usage is particularly
   important.

   The usage of RTP over TCP/TLS is useful when communicating between
   single-user agents (such as a softphone or hardphone) and a publicly
   connected device, like a PSTN gateway.  In this case, the PSTN



Rosenberg                Expires April 26, 2007                 [Page 3]


Internet-Draft                     ICE                      October 2006


   gateway would act as the TLS server, and have a certificate.  The
   client can then connect, validate the certificate, but offer none of
   its own (since its not likely to have one).  STUN itself would then
   provide authentication of the softphone to the gateway, leveraging
   the exchange of a short term credential in the SIP signaling.

   This specification extends ICE by defining its usage with TCP and
   TCP/TLS based candidates.  This specification does so by following
   the outline of ICE itself, and calling out the additions and changes
   necessary in each section of ICE to support TCP and TCP/TLS
   candidates.


2.  Overview of Operation

   The usage of ICE with TCP and TCP/TLS is relatively straightforward.
   The main area of specification is around how and when connections are
   opened, and how those connections relate to candidate pairs.

   When the agents perform address allocations to gather TCP-based
   candidates, three types of candidates can be obtained.  These are
   active candidates, passive candidates, and simultaneous-open
   candidates [3].  An active candidate is one for which the agent will
   attempt to open an outbound connection, but will not receive incoming
   connection requests.  A passive candidate is one for which the agent
   will receive incoming connection attempts, but not attempt a
   connection.  A simultaneous-open candidate is one for which the agent
   will attempt to open a connection simultaneously with its peer.
   These same three types are defined for TCP/TLS.

   When gathering candidates from a host interface, the agent typically
   obtains an active, passive and simultaneous-open candidates.
   Similarly, communications with a STUN server will provide server
   reflexive and relayed versions of all three types.

   When encoding these candidates into offers and answers, the type of
   the candidate is signaled.  In the case of active candidates, an IP
   address and port is present, but it is meaningless, as it is ignored
   by the peer.  As a consequence, active candidates do not need to be
   physically allocated at the time of address gathering.  Rather, the
   physical allocations, which occur as a consequence of a connection
   attempt, occur at the time of the connectivity checks.

   When the candidates are paired together, active candidates are always
   paired with passive, and simultaneous-open candidates with each
   other.  When a connectivity check is to be made for a transport
   address pair within a candidate pair, each agent determines whether
   it is to make a connection attempt for this pair.



Rosenberg                Expires April 26, 2007                 [Page 4]


Internet-Draft                     ICE                      October 2006


      Why have both active and actpass candidates for local and relayed
      transport addresses?  Why not just simultaneous-open?  The reason
      is that NAT treatment of simultaneous opens is currently not well
      defined, though specifications are being developed to address this
      [8].  Some NATs generate block the second TCP SYN packet or
      improperly process the subsequent SYNACK, which will cause the
      connection attempt to fail.  Therefore, if only simultaneous opens
      are used, connections may often fail.  However, only doing
      unidirectional opens (where one side is active and the other is
      passive) is more reliable, but will always require a relay if both
      sides are behind NAT.  Therefore, in the spirit of the ICE
      philosophy, both are tried.  Simultaneous-opens are preferred
      since, if it does work, it will not require a relay even when both
      sides are behind a different NAT.

   The actual processing of generating connectivity checks, managing the
   state of the check list, and updating the Valid list, work
   identically for TCP and TCP/TLS as they do for UDP.

   ICE requires an agent to demultiplex STUN and application layer
   traffic, since they appear on the same port.  This demultiplexing is
   described by ICE, and is done using the magic cookie and other fields
   of the message.  Stream-oriented transports introduce another
   wrinkle, since they require a way to frame the connection so that the
   application and STUN packets can be extracted in order to determine
   which is which.  For this reason, TCP or TCP/TLS media streams
   utilizing ICE use the basic framing provided in RFC 4571 [4], even if
   the application layer protocol is not RTP.

   When an updated offer is generated by the controlling endpoint, the
   SDP extensions for connection oriented media [3] are used to signal
   that an existing connection should be used, rather than opening a new
   one.


3.  Sending the Initial Offer

3.1.  Gathering Candidates

   For each TCP capable media stream the agent wishes to use (including
   ones, like RTP, which can either be UDP or TCP), the agent SHOULD
   obtain two host candidates for each component of the media stream on
   each interface that the host has - one for the simultaneous open, and
   one for the passive candidate.  If the agent is capable of acting as
   a server in TLS connections, it SHOULD do the same for each TCP/TLS
   capable media stream that the agent wishes to use (such as RTP).

   Providers of real-time communications services may decide that it is



Rosenberg                Expires April 26, 2007                 [Page 5]


Internet-Draft                     ICE                      October 2006


   preferable to have no media at all than it is to have media over TCP.
   To allow for choice, it is RECOMMENDED that agents be configurable
   with whether they obtain TCP candidates for real time media.

      Having it be configurable, and then configuring it to be off, is
      far better than not having the capability at all.  An important
      goal of this specification is to provide a single mechanism that
      can be used across all types of endpoints.  As such, it is
      preferable to account for provider and network variation through
      configuration, instead of hard-coded limitations in an
      implementation.  Furthermore, network characteristics and
      connectivity assumptions can, and will change over time.  Just
      because a agent is communicating with a server on the public
      network today, doesn't mean that it won't need to communicate with
      one behind a NAT tomorrow.  Just because a agent is behind a NAT
      with endpoint indpendent mapping today, doesn't mean that tomorrow
      they won't pick up their agent and take it to a public network
      access point where there is a NAT with address and port dependent
      mapping properties, or one that only allows outbound TCP.  The way
      to handle these cases and build a reliable system is for agents to
      implement a diverse set of techniques for allocating addresses, so
      that at least one of them is almost certainly going to work in any
      situation.  Implementors should consider very carefully any
      assumptions that they make about deployments before electing not
      to implement one of the mechanisms for address allocation.  In
      particular, implementors should consider whether the elements in
      the system may be mobile, and connect through different networks
      with different connectivity.  They should also consider whether
      endpoints which are under their control, in terms of location and
      network connectivity, would always be under their control.  In
      environments where mobility and user control are possible, a
      multiplicity of techniques is essential for reliability.

   Each agent SHOULD "obtain" an active host candidate for each
   component of each TCP and TCP/TLS capable media stream on each
   interface that the host has.  The agent does not have to actually
   allocate a port for these candidates.  These candidates serve as a
   placeholder for the creation of the check lists.

   Using each simultaneous-open and passive host TCP candidate as a
   base, the agent SHOULD obtain both a relayed and server reflexive
   candidate using the STUN relay usage.  The relay usage allows the
   agent to ask for a UDP or TCP-based relayed candidate when connecting
   to the server using TCP or TLS.  It is RECOMMENDED that a TCP-based
   host candidate be used to obtain a TCP-based relayed candidate.  An
   agent MAY use an additional host TCP candidate to request a UDP-based
   candidate from the server.  Usage of the UDP candidate from the relay
   follows the procedures defined in ICE for UDP candidates.



Rosenberg                Expires April 26, 2007                 [Page 6]


Internet-Draft                     ICE                      October 2006


   Using each simultaneous-open and passive host TCP/TLS candidate as a
   base, the agent SHOULD obtain a server reflexive TCP/TLS candidate
   using the STUN Binding Discovery usage.

   Each agent SHOULD "obtain" an active relayed candidate for each
   component of each TCP and TCP/TLS capable media stream on each
   interface that the host has.  The agent does not have to actually
   allocate a port for these candidates from the relay at this time.
   These candidates serve as a placeholder for the creation of the check
   lists.

   Like its UDP counterparts, TCP-based STUN transactions are paced out
   at one every Ta seconds.  This pacing refers to the establishment of
   a TCP connection to the STUN server and the subsequent STUN request.
   That is, every Ta seconds, the agent will open a new TCP connection
   and send a STUN request, ideally an Allocate request, since it will
   provide multiple candidates with one request.

3.2.  Prioritization

   The transport protocol itself is a criteria for choosing one
   candidate over another.  If a particular media stream can run over
   UDP or TCP, the UDP candidates might be preferred over the TCP
   candidates.  This allows ICE to use the lower latency UDP
   connectivity if it exists, but fallback to TCP if UDP doesn't work.

   To accomplish this, the local preference SHOULD be defined as:


   local-preference = (2^12)*(transport-pref) +
                      (2^9)*(direction-pref) +
                      (2^0)*(other-pref)

   When this formulation is used, the transport-pref MUST be between 0
   and 15, with 15 being the most preferred.  The direction-pref MUST be
   between 0 and 7, with 7 being the most preferred.  Other-pref MUST be
   between 0 and 511, with 511 being the most preferred.  For RTP-based
   media streams, it is RECOMMENDED that UDP have a transport-pref of
   15, TCP of 10, and TLS of 4.  It is RECOMMENDED that, for all
   connection-oriented media, simultaneous-open candidates have a
   direction-pref of 7, active of 5 and passive of 2.  If any two
   candidates have the same type-preference, transport-pref, and
   direction-pref, they MUST have a unique other-pref.  With this
   specification, the only way that can happen is with multi-homed
   hosts, in which case other-pref is a preference amongst interfaces.






Rosenberg                Expires April 26, 2007                 [Page 7]


Internet-Draft                     ICE                      October 2006


3.3.  Choosing In-Use Candidates

   The In-Use candidate is chosen primarily based on the likelihood of
   it working with a non-ICE peer.  When media streams supporting mixed
   modes (both TCP and UDP) are used with ICE, it is RECOMMENDED that,
   for real-time streams (such as RTP), the operating candidate be UDP-
   based.

3.4.  Encoding the SDP

   TCP-based candidates are encoded into a=candidate lines identically
   to the UDP encoding described in [6].  However, the transport
   protocol is set to "tcp-so" for TCP simultaneous-open candidates,
   "tcp-act" for TCP active candidates, "tcp-pass" for TCP passive
   candidates, "tls-so" for TCP/TLS simultaneous-open candidates, "tls-
   act" for TCP/TLS active candidates, and "tls-pass" for TCP/TLS
   passive candidates.  The addr and port encoded into the candidate
   attribute for active candidates MUST be set to IP address that will
   be used for the attempt, but the port MUST be set to 9 (i.e.,
   Discard).  For relayed candidates, the IP address that will be used
   for the attempt is the one from a passive or simultaneous-open
   candidate from the same STUN server.

   If the in-use candidate is TCP or TCP/TLS, the agent MUST include the
   parameters defined in RFC 4145 [3] and RFC 4572 [5] respectively, as
   they will be needed for a non-ICE peer.  If the in-use candidate is
   not TCP or TCP/TLS, but there are TCP or TCP/TLS candidates present
   for a media stream, those parameters MUST NOT be included.  The rules
   in this specification define an alternative set of procedures for
   connection management for TCP; for TCP/TLS, the subsequent offer/
   answer is used to verify the TLS certificate fingerprint, should that
   candidate be selected.  This is discussed in more detail below.


4.  Receiving the Initial Offer

4.1.  Forming the Check Lists

   When forming candidate pairs, the following types of candidates can
   be paired with each other:











Rosenberg                Expires April 26, 2007                 [Page 8]


Internet-Draft                     ICE                      October 2006


   Local             Remote
   Candidate         Candidate
   ----------------------------
   tcp-so           tcp-so
   tcp-act          tcp-pass
   tcp-pass         tcp-act
   tls-so           tls-so
   tls-act          tls-pass
   tls-pass         tls-act

   When the agent prunes the check list, it MUST also remove any pair
   for which the local candidate is either tcp-pass or tls-pass.

   The remainder of check list processing works like the UDP case.


5.  Connectivity Checks

5.1.  Client Procedures

5.1.1.  Sending the Request

   When an agent wants to send a TCP or TCP/TLS-based connectivity
   check, it first opens a TCP connection if none yet exists for the
   5-tuple on which the check is to be sent.  This connection is opened
   from the local candidate of the check to the remote candidate of the
   check.  If the local candidate is tls-act or tcp-act, the agent MUST
   open a connection from the interface associated with that local
   candidate.  This connection MUST be opened from an unallocated port.
   For host candidates, this is readily done by connecting from the
   specific interface.  For relayed candidates, the agent uses the
   procedures in [7] to initiate a new connection from the specified
   interface on the relay.  [[TODO: need to make sure this reconciles
   with latest TURN]].

   If the pair is TLS-based, and the local candidate is tls-so, the
   agent MUST offer a client certificate.  Note, however, that there
   will not have been an a=fingerprint attribute yet in the offer/answer
   exchange unless the candidate pair is a match for the in-use pair.
   Consequently, once the TLS exchange completes, certificate validation
   as described in RFC 4572 is not yet done.

   Once the TCP or TCP/TLS connection is established, connectivity
   checks are sent over the connection.  The agent MUST use the framing
   defined in RFC 4571 [4], even though the data will include both media
   (possibly RTP) and STUN packets.  This framing MUST be used for the
   lifetime of this connection.




Rosenberg                Expires April 26, 2007                 [Page 9]


Internet-Draft                     ICE                      October 2006


   If the TCP connection cannot be established, or the TLS handshakes
   fail, the check is considered to have failed, and a full-mode agent
   MUST update its state to Failed in the check list.

5.2.  Server Procedures

   An agent MUST be prepared to receive incoming TCP connection requests
   on any host or relayed TCP or TCP/TLS candidate that is simultaneous-
   open or passive.  When the connection request is received, the agent
   MUST accept it.  If the candidate on which the connection was
   received is a TCP/TLS candidate, the agent MUST proceed with TLS
   negotiation.  It MUST offer a certificate.  As discussed above,
   validation of the fingerprint does not yet happen.

   The agent MUST use the framing defined in RFC 4571 [4], even though
   the data will include both media (possibly RTP) and STUN packets.
   This framing MUST be used for the lifetime of this connection.

   Once the connection is established, server procedures are identical
   to those for UDP candidates.  Note that STUN requests received on a
   passive TCP or TCP/TLS candidate will typically produce a remote peer
   reflexive candidate.


6.  Concluding ICE

   If the candidate pairs selected for media by ICE are TCP/TLS, the
   controlling agent MUST send an updated offer if the previous offer
   did not include a fingerprint attribute, even if those candidates
   match the values in the m/c-line.


7.  Subsequent Offer/Answer Exchanges

7.1.  Generating the Offer

   If an agent places a selected TCP or TCP/TLS candidate in the m/c-
   line of a subsequent offer, if MUST include the a=holdconn attribute
   from RFC 4145, since an in-use connection is being used.  However,
   the a=active, a=passive and a=actpass attributes are not needed.  For
   TLS candidates, the offer MUST also include the fingerprint attribute
   defined in RFC 4572.

7.2.  Receiving the Offer and Generating the Answer

   The same rules for inclusion of the RFC 4145 and RFC 4572 attributes
   apply to the answerer as they do to the offerer.  Furthermore, for
   TLS candidates in the m/c-line, the agent MUST verify the fingerprint



Rosenberg                Expires April 26, 2007                [Page 10]


Internet-Draft                     ICE                      October 2006


   when the subsequent offer arrives.

7.3.  Updating the Check and Valid Lists

   If an ICE restart occurs for a media stream with TCP or TCP/TLS
   candidates, the agents MUST close each connection except for the ones
   in-use by ICE for sending media.  Those connections continue to be
   used for media while ICE checks re-run (establishing new connections
   in the process).


8.  Media Handling

8.1.  Sending Media

   When sending media, if the 5-tuple to which media is sent (the base
   of the local candidate and the remote candidate) match an existing
   TCP connection, that connection is used for sending media.

   The framing defined in RFC 4571 MUST be used when sending media.  For
   media streams that are not RTP-based and do not normally use RFC
   4571, the agent treats the media stream as a byte stream, and assumes
   that it has its own framing of some sort.  It then takes an arbitrary
   number of bytes from the bytestream, and places that as a payload in
   the RFC 4571 frames, including the length.  The recipient can extract
   the bytestream and apply the application-specific framing on it.

   If the candidate pair selected by ICE for usage with media is TCP/
   TLS, and an updated offer has not yet been received containing the
   fingerprint attribute, the agent MUST NOT send media on that
   connection.  Once the fingerprints have been validated, the agent MAY
   send media.

8.2.  Receiving Media

   The framing defined in RFC 4571 MUST be used when receiving media.
   For media streams that are not RTP-based and do not normally use RFC
   4571, the agent extracts the payload of each RFC 4571 frame, and
   determines if it is a STUN or an application layer data based on the
   procedures in [6].  If it is application layer data, the agent
   appends this to the ongoing bytestream collected from the frames.  It
   then parses the bytestream as if it had been directly received over
   the TCP or TCP/TLS connection.  This allows for ICE-tcp to work
   without regard to the framing mechanism used by the application layer
   protocol.

   If the candidate pairs selected by ICE include TCP/TLS candidates,
   and an updated offer/answer exchange has not yet occurred to exchange



Rosenberg                Expires April 26, 2007                [Page 11]


Internet-Draft                     ICE                      October 2006


   and validate the fingerprint, the agent MUST NOT accept media over
   that connection until the fingerprints have been validated.  [[TODO:
   Hmm, seems like a race here; we'll lose the first few packets the
   answerer sends until its answer is received]]


9.  Connection Management

   Once a TCP or TCP/TLS connection is opened by ICE, its lifecycle
   depends on how it is used.  If that candidate pair is selected by ICE
   for usage for media, the connection stays open until either the
   session terminates, the media stream is removed, or an ICE restart
   takes place, resulting in the selection of a different candidate
   pair.  If that candidate pair is not selected by ICE for usage with
   media, an agent SHOULD close the connection once ICE processing
   reaches the Completed state for that media stream.

   If a connection is in use for either media or checks, and the
   connection closes for some reason, and the local candidate is either
   active or simultaneous-open, the agent SHOULD reopen the connection.
   Unlike RFC 4145, additional signaling is not required to repair a
   closed connection.


10.  Security Considerations

   The main threat in ICE is hijacking of connections for the purposes
   of directing media streams to DoS targets or to malicious users.
   ICE-tcp prevents that by only using TCP connections that have been
   validated.  Validation requires a STUN transaction to take place over
   the connection.  This transaction cannot complete without both
   participants knowing a shared secret exchanged in the rendezvous
   protocol used with ICE, such as SIP.  This shared secret, in turn, is
   protected by that protocol exchange.  In the case of SIP, the usage
   of the sips mechanism is RECOMMENDED.  When this is done, an
   attacker, even if it knows or can guess the port on which an agent is
   listening for incoming TCP connections, will not be able to open a
   connection and send media to the agent.

   A more detailed analysis of this attack and the various ways ICE
   prevents it are described in [6].  Those considerations apply to this
   specification.


11.  IANA Considerations

   There are no IANA considerations associated with this specification.




Rosenberg                Expires April 26, 2007                [Page 12]


Internet-Draft                     ICE                      October 2006


12.  Acknowledgements

   The authors would like to thank Tim Moore, Francois Audet and Roni
   Even for the reviews and input on this document.


13.  References

13.1.  Normative References

   [1]  Rosenberg, J., "Simple Traversal Underneath Network Address
        Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-04 (work
        in progress), July 2006.

   [2]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

   [3]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
        Session Description Protocol (SDP)", RFC 4145, September 2005.

   [4]  Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP
        Control Protocol (RTCP) Packets over Connection-Oriented
        Transport", RFC 4571, July 2006.

   [5]  Lennox, J., "Connection-Oriented Media Transport over the
        Transport Layer Security (TLS) Protocol in the Session
        Description Protocol (SDP)", RFC 4572, July 2006.

   [6]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
        Methodology for Network  Address Translator (NAT) Traversal for
        Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in
        progress), October 2006.

   [7]  Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
        Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in
        progress), October 2006.

13.2.  Informative References

   [8]  Guha, S., "NAT Behavioral Requirements for TCP",
        draft-ietf-behave-tcp-01 (work in progress), June 2006.

   [9]  Campbell, B., "The Message Session Relay Protocol",
        draft-ietf-simple-message-sessions-15 (work in progress),
        July 2006.






Rosenberg                Expires April 26, 2007                [Page 13]


Internet-Draft                     ICE                      October 2006


Author's Address

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net








































Rosenberg                Expires April 26, 2007                [Page 14]


Internet-Draft                     ICE                      October 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosenberg                Expires April 26, 2007                [Page 15]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/