A Proposal to Define Interactive Connectivity Establishment for the Transport Control Protocol (ICE-TCP) as an Extensible Framework

The ICE-TCP document currently relies on a closed set of technologies for gathering candidates. While there is no prohibition on the use of alternate technologies, ICE-TCP limits its discussion to those technologies discussed in the base ICE specification . Specifically, this approach discusses the use of host candidates, server reflexive candidates, and relayed candidates (with a focus on TURN). Unfortunately, this focus has led to the impression that ICE-TCP must either use relayed candidates or rely on the "simultaneous open" approach that is known to have a low chance of success. In fact, both ICE and ICE-TCP can be extended to leverage any of a myriad of NAT traversal technologies. The most appealing feature of these technologies is that many of them are already widely deployed. For example: Teredo establishes a UDP tunnel for other transport protocols that is visible to applications on a host as an IPv6 address. It is included in all current distributions of Windows and available for Mac OS X, Linux, and most BSD platforms as a freely installable package. deployed on the majority of residential-grade NAT/Firewall devices and allows hosts behind the NAT to request a publicly accessible TCP port. Widely available as a relaying protocol, it has also been extended to act as a NAT traversal solution in many NATs.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The authors propose that the ICE-TCP document be modified and expanded to clarify the way that candidates are gathered and prioritized.

The current version of ICE-TCP discusses the use of STUN and TURN for gathering Server Reflexive and Relayed candidates, respectively. We propose this be written in a way that clarifies that such candidates can be gathered via myriad mechanisms, and gives advice on which types of candidates to gather. To that end, we propose to replace the following text in section 3.1: Next, the agent SHOULD take all host TCP candidates for a component that have the same foundation (there will typically be two - a passive and a simultaneous-open), and amongst them, pick two arbitrarily. These two host candidates will be used to obtain relayed and server reflexive candidates. To do that, the agent initiates a TCP connection from each candidate to the TURN server (resulting in two TCP connections). On each connection, it issues an Allocate request. One of the resulting relayed candidate is used as a passive relayed candidate, and the other, as a simultaneous-open relayed candidate. In addition, the Allocate responses will provide the agent with a server reflexive candidate for their corresponding host candidate. For all of the remaining host candidates, if any, the agent only needs to obtain server reflexive candidates. To do that, it initiates a TCP connection from each host candidate to a STUN server, and uses a Binding request over that connection to learn the server reflexive candidate corresponding to that host candidate. Once the Allocate or Binding request has completed, the agent MUST keep the TCP connection open until ICE processing has completed. See Section 1 for important implementation guidelines. With: Next, the agent SHOULD take all host TCP candidates for a component that have the same foundation (there will typically be two - a passive and a simultaneous-open), and amongst them, pick two arbitrarily. These two host candidates will be used to obtain two Relayed Candidates (see ). The agent should then obtain one or more non-relayed NAT candidates (see ). The mechanisms for establishing such candidates and the number of candidates to collect vary from technique to technique. These considerations are discussed in the relevant sections, below. Once the relayed candidates and non-relayed NAT candidates have been prepared, the agent MUST keep the TCP connection open until ICE processing has completed. See Section 1 for important implementation guidelines. (Note that, in the preceding text, references to and refer to sections in this document, not to sections in draft-ietf-mmusic-ice-tcp.)

The current prioritization scheme defined in ICE-TCP favors simultaneous-open candidates over active and passive candidates. This prioritization is presumably based on the prospect that non-relayed connections are the exclusive domain of STUN-discovered Server Reflexive Candidates. Such candidates necessarily rely on "fooling" the NAT into allowing TCP connections through; and one might assume that simultaneous open has a higher chance of succeeding in doing so. Empirical evidence on the simultaneous open technique described in ICE-TCP has shown that, while it has a relatively high chance of establishing the proper state in a NAT, it suffers from a high failure rate on the actual endpoints. Several NAT traversal techniques, both deployed and proposed, provide means for discovering NAT-allocated address/port combinations in such a way that the NAT is actively participating in the TCP establishment effort instead of impeding it. Others leverage the behavior of UDP binding in NATs to carry TCP traffic over UDP. In such cases, normal active and passive candidates actually have a higher chance of success than simultaneous-open candidates. To reflect this reality, we propose that the prioritization scheme for ICE-TCP be revised. Specifically, we propose to replace the following text in section 3.2: 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. With: It is RECOMMENDED that, for all connection-oriented media, candidates have a direction-pref assigned as follows: NAT-Assisted Active Candidate NAT-Assisted Passive Candidate UDP-Tunneled Active Candidate UDP-Tunneled Passive Candidate Simultaneous Open Candidate Non-NAT-Assisted Active Candidate Non-NAT-Assisted Passive Candidate It is RECOMMENDED that the type preference for NAT-Assisted candidates be set higher than that for server-reflexive candidates and that the type preference for UDP-Tunneled candidates be set lower than that for server-reflexive candidates. The RECOMMENDED values are 105 for NAT-Assisted candidates and 75 for UDP-Tunneled candidates. TODO: The same information probably doesn't need to be encoded in both the type-pref and direction-pref. More work is needed to iron out how to represent appropriate priorities.

(The authors propose that the entirety of this and its subsections, with the exception of this parenthetical paragraph, be included in ICE-TCP.) The following sections discuss a number of techniques that can be used to obtain candidates for use with ICE-TCP. It is critical to note that this list is not intended to be exhaustive, nor is implementation of any specific technique considered mandatory. Implementors are encouraged to implement as many of the following techniques from the following list as is practical, as well as to explore additional NAT-traversal techniques beyond those discussed in this document.

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 (each on a different port) 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 an agent is not capable of acting in one of these modes it would omit those candidates. For maximum interoperability with the techniques described below, implementors should take particular care to include both IPv4 and IPv6 candidates as part of the process of gathering candidates. If the local network or host does not support IPv6 addressing, then clients SHOULD make use of Teredo () or SOCKS IPv4-IPv6 Gatewaying ().

The following techniques can be used to gather candidates that represent NAT traversal, while not going through any additional relays. This includes Server Reflexive Candidates (non-NAT-assisted), candidates established in cooperation with the NAT (NAT-assisted), and candidates tunnel TCP over UDP to leverage widespread NAT UDP binding behavior (UDP-tunneling). Generally, when several options are available, clients should favor NAT-assisted techniques over UDP-tunneling techniques, and UDP-tunneling techniques over non-NAT-assisted techniques.

To traverse NATs, the best approach is to work with the NATs themselves, rather than trying to "game" their behavior with tricks and relays. To that end, clients behind NATs should favor approaches that work with NATs whenever possible. Because these techniques interact with the NAT directly to acquire a publicly accessible transport address, once obtained these candidates are encoded as normally TCP candidates (typically tcp-pass) as specified in Section 3.4 of ICE-TCP.

The UPnP forum's Internet Gateway Device (IGD) protocol is designed to facilitate client configuration of NAT port forwarding behavior. IGD is deployed on a majority of residential-grade NAT/Firewall devices, and is available for Linux- and FreeBSD-based firewalls. Clients wishing to use IGD-obtained addresses as candidates do so by retrieving the ExternalIPAddress state variable; then, they use the AddPortMapping command to establish a new TCP binding at the NAT. The client is responsible for establishing the binding so that it corresponds to a Host Candidate, and for periodically refreshing the port mapping to keep the lease from expiring. When the IGD-acquired candidate is no longer necessary, the client SHOULD remove the binding with a DeletePortMapping command.

The MIDCOM MIB defines an SNMP-based mechanism for controlling NATs, Firewalls, and other middleboxes. TODO: add application notes about how to obtain candidates

Although originally designed as a relaying protocol, SOCKS has been incorporated in a number of NATs as a NAT-assisted traversal technique. The approach for using SOCKS for NAT-assisted traversal is identical to that for using it as a relay protocol (see ). If the ICE agent is aware that SOCKS is being used as a NAT-assisted protocol instead of a relay protocol, it SHOULD set the local-preference accordingly.

The Realm Specific IP (RSIP) protocol is an experimental protocol designed to allow clients within a realm to communicate with gateways on the edge of that realm so as to lease globally-visible resources on those gateways. TODO: add application notes about how to obtain candidates TODO: examine RSIP as a v4/v6 bridging technology

The SIMCO protocol an experimental mechanism for controlling NATs, Firewalls, and other middleboxes. TODO: add application notes about how to obtain candidates

The NAT Port Mapping Protocol (PMP) is designed to allow clients to determine the external IP address of a NAT, learn about any changes in that IP address, and create and refresh UDP and TCP bindings on the NAT. NAT-PMP is currently supported in a number of field-deployed products, such as the Apple Airport Express, Apple Airport Extreme, and Apple Time Capsule, as well as a large number of primarily peer-to-peer software applications. Clients wishing to use PMP-obtained addresses as candidates do so by retrieving the external IP address, using the PMP opcode 0; then, they use the PMP opcode 2 to establish a new TCP binding at the NAT. The client is responsible for establishing the binding so that it corresponds to a Host Candidate, and for periodically refreshing the port mapping to keep the lease from expiring. When the PMP-obtained candidate is no longer necessary, the client SHOULD remove the binding with a PMP opcode 2 with the port mapping lifetime set to 0.

The Teredo protocol defines a system allow nodes behind one or more NATs to obtain IPv6 addresses by tunneling IPv6 over UDP. Teredo it included in all modern Windows operating systems by default, and is available for most other major operating systems, such as Linux, OS X, and *BSD. Teredo essentially provides a UDP tunnel for other transport protocols that is visible to the host application as an IPv6 address. Therefore, Teredo candidates are encoded as IPv6 addresses in the SDP. The Teredo framework includes provisions for routing between Teredo IPv6 addresses and native IPv6 addresses; therefore, the efficacy of Teredo tunneling will be significantly improved for each ICE-TCP implementation that advertises at least one globally-routable IPv6 address candidate (whether Teredo, SOCKS tunneled, 6-to-4 relayed, IPv6 tunneled, or native). TODO: add application notes about how to obtain candidates

TODO: Describe TCP/UDP/IP, as defined in . TODO: add application notes about how to obtain candidates; need to include discussion of SDP extensions necessary to specify encoding for TCP over UDP.

TODO: Describe STUN, as defined in . To obtain STUN server reflexive candidates, the agent initiates a TCP connection from two host candidates to a STUN server, and uses a Binding request over that connection to learn the server reflexive candidate corresponding to that host candidate.

TODO: Describe SOCKS, as defined in TODO: add application notes about how to obtain candidates

TODO: Describe IPv4/IPv6 bridging technique described in TODO: add application notes about how to obtain candidates

TODO: Describe SSH Tunneling technique described in TODO: add application notes about how to obtain candidates

TODO: Describe TURN TCP protocol described in To acquire TURN TCP candidates, the agent initiates a TCP connection from two host candidates to the TURN server (resulting in two TCP connections). On each connection, it issues an Allocate request. One of the resulting relayed candidate is used as a passive relayed candidate, and the other, as a simultaneous-open relayed candidate. In addition, the Allocate responses will provide the agent with a server reflexive candidate for their corresponding host candidate.