Network Working Group M. Petit-Huguenin Internet-Draft 8x8, Inc. Intended status: Standards Track May 7, 2008 Expires: November 8, 2008 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers draft-petithuguenin-behave-turn-uri-01 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 November 8, 2008. Abstract This document defines two URIs and the resolution mechanism to convert these URIs to a list of server transport addresses that can be used between a TURN client and server. Petit-Huguenin Expires November 8, 2008 [Page 1]
Internet-Draft TURN URIs May 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Syntax of a TURN or TURNS URI . . . . . . . . . . . . . . . . 3 4. TURN or TURNS URI Resolution . . . . . . . . . . . . . . . . . 3 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 7 A.1. Modifications between -01 and -00 . . . . . . . . . . . . 7 A.2. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 8 A.3. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Petit-Huguenin Expires November 8, 2008 [Page 2]
Internet-Draft TURN URIs May 2008 1. Introduction The TURN [I-D.ietf-behave-turn] specification defines a process for a TURN client to find TURN servers by using DNS SRV resource records, but this process does not let the TURN servers administrator provision the preferred TURN transport protocol between the client and the servers and for the TURN client to discover this preference. This document defines a S-NAPTR application [RFC3958] for this purpose. This application defines RELAY as application service tag and turn.udp, turn.tcp and turn.tls as application protocol tags. To simplify the provisioning of TURN clients, this document also defines a TURN and a TURNS URI and a resolution mechanism to convert this URIs into a list of IP addresses, ports and TURN transport protocols. 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 [RFC2119]. 3. Syntax of a TURN or TURNS URI A TURN/TURNS URI has the following ABNF syntax [RFC5234]: turnURI = scheme ":" host [ ":" port ] [ ";transport=" transport ] scheme = "turn" / "turns" transport = "udp" / "tcp" / transport-ext transport-ext = 1*unreserved <host>, <port> and <unreserved> are specified in [RFC3986]. 4. TURN or TURNS URI Resolution The URI resolution algorithm uses <scheme>, <host>, <port> and <transport> as input. It also uses a list ordered by preference of TURN transports (UDP, TCP, TLS) supported by the application using the TURN client. The output of the algorithm is a list of IP address, port and transport tuples that a TURN client can try to contact a TURN server. First the resolution algorithm checks that the URI can be resolved with the list of TURN transports supported: Petit-Huguenin Expires November 8, 2008 [Page 3]
Internet-Draft TURN URIs May 2008 o If <scheme> is defined as "turn" and <transport> is defined as "udp" but the list of TURN transports does not contain UDP then the resolution MUST stop with an error. o If <scheme> is defined as "turn" and <transport> is defined as "tcp" but the list of TURN transports does not contain TCP or TLS then the resolution MUST stop with an error. o If <scheme> is defined as "turns" and <transport> is defined as "udp" then the algorithm MUST stop with an error. o If <scheme> is defined as "turns" and <transport> is defined as "tcp" but the list of TURN transports does not contain TLS then the resolution MUST stop with an error. o If <scheme> is defined as "turns" and <transport> is not defined but the list of TURN transports does not contain TLS then the resolution MUST stop with an error. Then the algorithm applies the following steps. The resolution stops when a TURN client successfully contacts a TURN server. In some steps <transport> and <scheme> have to be converted to a TURN transport. If <scheme> is defined as "turn" and <transport> is defined as "udp" then the TURN UDP transport is used. If <scheme> is defined as "turn" and <transport> is defined as "tcp" then the TURN TCP transport is used. If <scheme> is defined as "turns" and <transport> is defined as "tcp" then the TURN TLS transport is used. 1. If <host> is an IP address then it indicates the specific IP address to be used. If <port> is not defined, the default port declared in [I-D.ietf-behave-turn] for the SRV service name defined in <scheme> is used. If <transport> is defined then <scheme> and <transport> are converted to a TURN transport as specified above. If <transport> is not defined, the TURN transports supported by the application are tried by preference order. If the TURN client cannot contact a TURN server with this IP address and port on any of the transports then the resolution MUST stop with an error. 2. If <host> is a domain name and <port> is defined, then <host> is resolved to a list of IP addresses via DNS A and AAAA queries. If <transport> is defined then <scheme> and <transport> are converted to a TURN transport as specified above. If <transport> is not defined, the TURN transports supported by the application are tried by preference order. If the TURN client cannot contact a TURN server with this port and any combination of transports and resolved IP addresses then the resolution MUST stop with an error. 3. If <host> is a domain name and <port> is not defined but <transport> is defined then <host> is converted to a list of IP address and port tuples via a DNS SRV query as defined in [I-D.ietf-behave-turn] section 6.1. <scheme> is used for the Petit-Huguenin Expires November 8, 2008 [Page 4]
Internet-Draft TURN URIs May 2008 service name and <transport> is used for the protocol name in the SRV algorithm [RFC2782]. If the TURN client cannot contact a TURN server on any of the IP address, port and transport tuples returned by the SRV algorithm then the resolution MUST stop with an error. The SRV algorithm recommends to do a A query if the SRV query returns an error or no SRV RR. In this case the default port declared in [I-D.ietf-behave-turn] for the SRV service name defined in <scheme> must be used for contacting the TURN server. This specification also modifies this algorithm by recommending to do a A or AAAA query in this case. 4. If <host> is a domain name and <port> and <transport> are not defined, then <host> is converted to an ordered list of IP address, port and transport tuples via the S-NAPTR algorithm defined in [RFC3958] with a "RELAY" Application Service Tag. The TURN transports supported by the application are converted in Application Protocol Tags by using "turn.udp" if the TURN transport is UDP, "turn.tcp" if the TURN transport is TCP and "turn.tls" if the TURN transport is TLS. The order to try the protocol tags is provided by the ranking of the first set of NAPTR records. If multiple protocol tags have the same ranking, the preferred order set by the application is used. If the TURN client cannot contact a TURN server with any of the IP address, port and transport tuples returned by the S-NAPTR algorithm then the resolution MUST stop with an error. If the first NAPTR SRV query does not return any result then <host> is converted to a list of IP address and port tuples by using the algorithm specified in step 3 for each of the TURN transports supported by the application by order of preference. 5. Example With the DNS RRs in Figure 1 and a preferred protocol list of [TLS, TCP, UDP], the resolution algorithm will try to contact the TURN servers in the order described in Table 1. Petit-Huguenin Expires November 8, 2008 [Page 5]
Internet-Draft TURN URIs May 2008 example.com. IN NAPTR 100 10 "" "RELAY:turn.udp" "" datagram.example.com. IN NAPTR 200 10 "" "RELAY:turn.tcp:turn.tls" "" stream.example.com. datagram.example.com. IN NAPTR 100 10 "S" "RELAY:turn.udp" "" _udp._turn.example.com. stream.example.com. IN NAPTR 100 10 "A" "RELAY:turn.tls" "" a.example.com. IN NAPTR 200 10 "S" "RELAY:turn.tcp" "" _tcp._turn.example.com. _udp._turn.example.com. IN SRV 0 0 5000 a.example.com. _tcp._turn.example.com. IN SRV 0 0 5000 a.example.com. a.example.com. IN A 192.0.2.1 Figure 1 +-------+----------+------------+------+ | Order | Protocol | IP address | Port | +-------+----------+------------+------+ | 1 | UDP | 192.0.2.1 | 5000 | | 2 | TLS | 192.0.2.1 | 3478 | | 3 | TCP | 192.0.2.1 | 5000 | +-------+----------+------------+------+ Table 1 6. Security Considerations TBD 7. IANA Considerations TBD 8. Acknowledgements Thanks to Eilon Yardeni, Dan Wing and Alfred Hoenes for their comments, suggestions and questions that were used to improve this Petit-Huguenin Expires November 8, 2008 [Page 6]
Internet-Draft TURN URIs May 2008 document. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-07 (work in progress), February 2008. Appendix A. Release notes This section must be removed before publication as an RFC. A.1. Modifications between -01 and -00 o Added <transport-ext> in the ABNF. o Use the <rulename> and "literal" usages for free-form text defined by [RFC5234]. o Fixed various typos. o Put the rule to convert <scheme> and <transport> to a TURN transport in a separate paragraph. o Modified the SRV usage to be in line with RFC 2782. o Clarified that the NAPTR protocol ranking must be used before the application ranking. Petit-Huguenin Expires November 8, 2008 [Page 7]
Internet-Draft TURN URIs May 2008 o Added an example. o Added release notes. A.2. Design Notes o The Application Service Tag is RELAY so other relaying mechanisms (e.g. TWIST) than TURN can be registered as Application Protocol Tags. o S-NAPTR was preferred to U-NAPTR because there is no use case for U-NAPTR. o <password> is not used in the URIs because it is deprecated. <username> is not used in the URIs because it is not used to guide the resolution mechanism. o Opaque URIs were chosen because the resolution mechanism is different from the hierarchical URI resolution mechanism. A.3. TODO List o Dan Wing: Add generic parameters on TURN URI. [Parameters can be optional or mandatory. Add text explaining that parameters to be defined in the future must be only for the purpose of guiding the resolution mechanism.] o Eilon Yardeni: In paragraph 3 of section 4: "....If the DNS SRV query does not return any result, then the URI host component is converted to a list of IP addresses by using the default port declared in [I-D.ietf-behave-turn] for the SRV service name defined in the URI scheme component and step 2 of the resolution algorithm." In rfc3489bis-15 section 9 it says that: "For usages that require TLS, lack of SRV records is equivalent to a failure of the transaction, since the request or indication MUST NOT be sent unless SRV records provided a transport address specifically for TLS." So I think something should be mentioned about lack of SRV records if TLS is required. [Waiting for an answer from the WG] o Add IANA registration for the URI and Application Tags. o Add security section. Petit-Huguenin Expires November 8, 2008 [Page 8]
Internet-Draft TURN URIs May 2008 Author's Address Marc Petit-Huguenin 8x8, Inc. 3151 Jay Street Santa Clara, CA 95054 US Phone: +1 408 654 0875 Email: marc@8x8.com Petit-Huguenin Expires November 8, 2008 [Page 9]
Internet-Draft TURN URIs May 2008 Full 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. 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. Intellectual Property 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. Petit-Huguenin Expires November 8, 2008 [Page 10]