MMUSIC WG A. B. Roach Internet-Draft Tekelec Expires: April 26, 2009 B. B. Lowekamp SIPeerior Technologies October 23, 2008 A Proposal to Define Interactive Connectivity Establishment for the Transport Control Protocol (ICE-TCP) as an Extensible Framework draft-lowekamp-mmusic-ice-tcp-framework-00 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, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The ICE-TCP mechanism is currently regarded as of limited usefulness due to the low success rate of TCP simultaneous open for NAT traversal. This document presents a vision of the ICE-TCP document as an extensible framework for negotiating a variety of approaches for establishing a TCP connection between NATed hosts. This document further proposes significantly extending the current set of Roach & Lowekamp Expires April 26, 2009 [Page 1] Internet-Draft ICE-TCP as a Framework October 2008 collection mechanisms to encompass a wide variety of technologies that are currently available, including UPnP, SOCKS, and Teredo. Because several of these technologies are already widely deployed, the direct connection rate should be significantly higher than using straight TCP alone. We envision that as future TCP connection establishment techniques are developed, they too will specify an ICE encoding that will allow their negotiation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Gathering Candidates . . . . . . . . . . . . . . . . . . . 4 3.2. Prioritization . . . . . . . . . . . . . . . . . . . . . . 5 4. Initial Set of Candidate Collection Technologies . . . . . . . 6 4.1. Host Candidates . . . . . . . . . . . . . . . . . . . . . 6 4.2. Non-Relayed NAT Candidates . . . . . . . . . . . . . . . . 7 4.2.1. NAT-Assisted . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. UDP Tunneled . . . . . . . . . . . . . . . . . . . . . 9 4.2.3. Non-NAT-Assisted . . . . . . . . . . . . . . . . . . . 9 4.3. Relayed Candidates . . . . . . . . . . . . . . . . . . . . 10 4.3.1. SOCKS . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. SOCKS IPv4-IPv6 Gateway . . . . . . . . . . . . . . . 10 4.3.3. SSH Tunnels . . . . . . . . . . . . . . . . . . . . . 10 4.3.4. TURN TCP . . . . . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Roach & Lowekamp Expires April 26, 2009 [Page 2] Internet-Draft ICE-TCP as a Framework October 2008 1. Introduction The ICE-TCP document [15] 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 [14]. 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: 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. UPnP: deployed on the majority of residential-grade NAT/Firewall devices and allows hosts behind the NAT to request a publicly accessible TCP port. SOCKS: Widely available as a relaying protocol, it has also been extended to act as a NAT traversal solution in many NATs. 2. Terminology 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 [2]. 3. Proposal The authors propose that the ICE-TCP document be modified and expanded to clarify the way that candidates are gathered and prioritized. Roach & Lowekamp Expires April 26, 2009 [Page 3] Internet-Draft ICE-TCP as a Framework October 2008 3.1. Gathering Candidates 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 Section 4.3). The agent should then obtain one or more non-relayed NAT candidates (see Section 4.2). 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. Roach & Lowekamp Expires April 26, 2009 [Page 4] Internet-Draft ICE-TCP as a Framework October 2008 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 Section 4.3 and Section 4.2 refer to sections in this document, not to sections in draft-ietf-mmusic-ice-tcp.) 3.2. Prioritization 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: Roach & Lowekamp Expires April 26, 2009 [Page 5] Internet-Draft ICE-TCP as a Framework October 2008 7 NAT-Assisted Active Candidate 6 NAT-Assisted Passive Candidate 5 UDP-Tunneled Active Candidate 4 UDP-Tunneled Passive Candidate 3 Simultaneous Open Candidate 2 Non-NAT-Assisted Active Candidate 1 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. 4. Initial Set of Candidate Collection Technologies (The authors propose that the entirety of this Section 4 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. 4.1. Host 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 (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 Roach & Lowekamp Expires April 26, 2009 [Page 6] Internet-Draft ICE-TCP as a Framework October 2008 clients SHOULD make use of Teredo (Section 4.2.2.1) or SOCKS IPv4- IPv6 Gatewaying (Section 4.3.2). 4.2. Non-Relayed NAT Candidates 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. 4.2.1. NAT-Assisted 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. 4.2.1.1. UPnP IGD The UPnP forum's Internet Gateway Device (IGD) protocol [19] 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. 4.2.1.2. MIDCOM SNMP The MIDCOM MIB [12] defines an SNMP-based mechanism for controlling Roach & Lowekamp Expires April 26, 2009 [Page 7] Internet-Draft ICE-TCP as a Framework October 2008 NATs, Firewalls, and other middleboxes. TODO: add application notes about how to obtain candidates 4.2.1.3. SOCKS Although originally designed as a relaying protocol, SOCKS [1] 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 Section 4.3.1). 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. 4.2.1.4. RSIP The Realm Specific IP (RSIP) protocol [4] 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 4.2.1.5. SIMCO The SIMCO protocol [11] an experimental mechanism for controlling NATs, Firewalls, and other middleboxes. TODO: add application notes about how to obtain candidates 4.2.1.6. NAT-PMP The NAT Port Mapping Protocol (PMP) [18] 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 Roach & Lowekamp Expires April 26, 2009 [Page 8] Internet-Draft ICE-TCP as a Framework October 2008 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. 4.2.2. UDP Tunneled 4.2.2.1. Teredo The Teredo protocol [10] 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 4.2.2.2. TCP over UDP TODO: Describe TCP/UDP/IP, as defined in [17]. TODO: add application notes about how to obtain candidates; need to include discussion of SDP extensions necessary to specify encoding for TCP over UDP. 4.2.3. Non-NAT-Assisted 4.2.3.1. STUN TODO: Describe STUN, as defined in [13]. 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. Roach & Lowekamp Expires April 26, 2009 [Page 9] Internet-Draft ICE-TCP as a Framework October 2008 4.3. Relayed Candidates 4.3.1. SOCKS TODO: Describe SOCKS, as defined in [1] TODO: add application notes about how to obtain candidates 4.3.2. SOCKS IPv4-IPv6 Gateway TODO: Describe IPv4/IPv6 bridging technique described in [3] TODO: add application notes about how to obtain candidates 4.3.3. SSH Tunnels TODO: Describe SSH Tunneling technique described in [5] [6] [7] [8] [9] TODO: add application notes about how to obtain candidates 4.3.4. TURN TCP TODO: Describe TURN TCP protocol described in [16] 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. 5. References [1] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001. [4] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001. [5] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Roach & Lowekamp Expires April 26, 2009 [Page 10] Internet-Draft ICE-TCP as a Framework October 2008 Assigned Numbers", RFC 4250, January 2006. [6] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [7] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [8] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [9] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [10] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [11] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0", RFC 4540, May 2006. [12] Quittek, J., Stiemerling, M., and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", RFC 5190, March 2008. [13] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for (NAT) (STUN)", draft-ietf-behave-rfc3489bis-16 (work in progress), July 2008. [14] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [15] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-tcp-07 (work in progress), July 2008. [16] Rosenberg, J. and R. Mahy, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", draft-ietf-behave-turn-tcp-00 (work in progress), November 2007. [17] Denis-Courmont, R., "UDP-Encapsulated Transport Protocols", draft-denis-udp-transport-00 (work in progress), July 2008. [18] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp-03 (work in progress), April 2008. Roach & Lowekamp Expires April 26, 2009 [Page 11] Internet-Draft ICE-TCP as a Framework October 2008 [19] Warrier, U., Iyer, P., Pennerath, F., Marynissen, G., Schmitz, M., Siddiqi, W., and M. Blaszczak, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001. Roach & Lowekamp Expires April 26, 2009 [Page 12] Internet-Draft ICE-TCP as a Framework October 2008 Authors' Addresses Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US Email: adam@nostrum.com Bruce B. Lowekamp SIPeerior Technologies 5251-18 John Tyler Highway #330 Williamsburg, VA 23185 USA Phone: +1 757 565 0101 Email: bbl@lowekamp.net Roach & Lowekamp Expires April 26, 2009 [Page 13] Internet-Draft ICE-TCP as a Framework October 2008 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, THE IETF TRUST 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 IETF Trust (2008). 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. Roach & Lowekamp Expires April 26, 2009 [Page 14]