From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7065.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc7065.txt (limited to 'doc/rfc/rfc7065.txt') diff --git a/doc/rfc/rfc7065.txt b/doc/rfc/rfc7065.txt new file mode 100644 index 0000000..d9c4a56 --- /dev/null +++ b/doc/rfc/rfc7065.txt @@ -0,0 +1,507 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Petit-Huguenin +Request for Comments: 7065 Impedance Mismatch +Category: Standards Track S. Nandakumar +ISSN: 2070-1721 G. Salgueiro + P. Jones + Cisco Systems + November 2013 + + + Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers + +Abstract + + This document specifies the syntax of Uniform Resource Identifier + (URI) schemes for the Traversal Using Relays around NAT (TURN) + protocol. It defines two URI schemes to provision the TURN + Resolution Mechanism (RFC 5928). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7065. + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Petit-Huguenin, et al. Standards Track [Page 1] + +RFC 7065 TURN URIs November 2013 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Definitions of the "turn" and "turns" URI . . . . . . . . . . 4 + 3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 4 + 3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . 4 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 5.1. "turn" URI Registration . . . . . . . . . . . . . . . . . 5 + 5.2. "turns" URI Registration . . . . . . . . . . . . . . . . 6 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 + 7.2. Informative References . . . . . . . . . . . . . . . . . 7 + Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 + Appendix B. Design Notes . . . . . . . . . . . . . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Petit-Huguenin, et al. Standards Track [Page 2] + +RFC 7065 TURN URIs November 2013 + + +1. Introduction + + This document specifies the syntax and semantics of the Uniform + Resource Identifier (URI) scheme for the Traversal Using Relays + around NAT (TURN) protocol. + + The TURN protocol is a specification allowing hosts behind NAT to + control the operation of a relay server. The relay server allows + hosts to exchange packets with its peers. The peers themselves may + also be behind NATs. RFC 5766 [RFC5766] defines the specifics of the + TURN protocol. + + The "turn" and "turns" URI schemes are used to designate a TURN + server (also known as a relay) on Internet hosts accessible using the + TURN protocol. With the advent of standards such as WebRTC [WEBRTC], + we anticipate a plethora of endpoints and web applications to be able + to identify and communicate with such a TURN server to carry out the + TURN protocol. This implies that endpoints and/or applications must + be provisioned with the appropriate configuration to identify the + TURN server. Having an inconsistent syntax adds ambiguity and can + result in non-interoperable solutions and implementation limitations. + The "turn" and "turns" URI schemes help alleviate most of these + issues by providing a consistent way to describe, configure, and + exchange the information identifying a TURN server. + + [RFC5928] defines a resolution mechanism to convert a secure flag, a + host name or IP address, a potentially empty port, and a potentially + empty transport to a list of IP address, port, and TURN transport + tuples. + + To simplify the provisioning of TURN clients, this document defines + the "turn" and "turns" URI schemes that can carry the four components + needed for the resolution mechanism. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" + in this document are to be interpreted as described in [RFC2119] when + they appear in ALL CAPS. When these words are not in ALL CAPS (such + as "should" or "Should"), they have their usual English meanings, and + are not to be interpreted as RFC 2119 key words. + + + + + + + + + + +Petit-Huguenin, et al. Standards Track [Page 3] + +RFC 7065 TURN URIs November 2013 + + +3. Definitions of the "turn" and "turns" URI + +3.1. URI Scheme Syntax + + The "turn" and "turns" URIs have the following formal ABNF syntax + [RFC5234]: + + turnURI = scheme ":" host [ ":" port ] + [ "?transport=" transport ] + scheme = "turn" / "turns" + transport = "udp" / "tcp" / transport-ext + transport-ext = 1*unreserved + + and are specified in [RFC3986]. While these two ABNF + productions are defined in [RFC3986] as components of the generic + hierarchical URI, this does not imply that the "turn" and "turns" + schemes are hierarchical URIs. Developers MUST NOT use a generic + hierarchical URI parser to parse a "turn" or "turns" URI. + + The , , and components are passed without + modification to the [RFC5928] algorithm. is set to false if + is equal to "turn", and set to true if is equal to + "turns" and passed to the [RFC5928] algorithm with the other + components. + +3.2. URI Scheme Semantics + + The "turn" and "turns" URI schemes are used to designate a TURN + server (also known as a relay) on Internet hosts accessible using the + TURN protocol. The TURN protocol supports sending messages over UDP, + TCP, or TLS-over-TCP. The "turns" URI scheme MUST be used when TURN + is run over TLS-over-TCP (or, in the future, DTLS-over-UDP), and the + "turn" scheme MUST be used otherwise. + + The required part of the "turn" URI denotes the TURN server + host. + + As specified in [RFC5766] and [RFC5928], the part, if present, + denotes the port on which the TURN server is awaiting connection + requests. If it is absent, the default port is 3478 for both UDP and + TCP. The default port for TURN over TLS is 5349. + + + + + + + + + + +Petit-Huguenin, et al. Standards Track [Page 4] + +RFC 7065 TURN URIs November 2013 + + +4. Security Considerations + + Security considerations for the resolution mechanism are discussed in + Section 5 of [RFC5928]. Note that this section contains normative + text defining authentication procedures to be followed by turn + clients when TLS is used. + + The "turn" and "turns" URI schemes do not introduce any specific + security issues beyond the security considerations discussed in + [RFC3986]. + + Although a "turn" or "turns" URI does not itself include the username + or password that will be used to authenticate the TURN client, in + certain environments, such as WebRTC, the username and password will + almost certainly be provisioned remotely by an external agent at the + same time as a "turns" URI is sent to that client. Thus, in such + situations, if the username and password were received in the clear, + there would be little or no benefit to using a "turns" URI. For this + reason, a TURN client MUST ensure that the username, password, + "turns" URI, and any other security-relevant parameters are received + with equivalent security before using the "turns" URI. Receiving + those parameters over another TLS session can provide the appropriate + level of security, if both TLS sessions are similarly parameterised, + e.g., with commensurate strength ciphersuites. + +5. IANA Considerations + + This section contains the registration information for the "turn" and + "turns" URI Schemes (in accordance with [RFC4395]). + +5.1. "turn" URI Registration + + URI scheme name: turn + + Status: permanent + + URI scheme syntax: See Section 3.1. + + URI scheme semantics: See Section 3.2. + + Encoding considerations: There are no encoding considerations beyond + those in [RFC3986]. + + Applications/protocols that use this URI scheme name: + + The "turn" URI scheme is intended to be used by applications with + a need to identify a TURN server to be used for NAT traversal. + + + + +Petit-Huguenin, et al. Standards Track [Page 5] + +RFC 7065 TURN URIs November 2013 + + + Interoperability considerations: N/A + + Security considerations: See Section 4. + + Contact: Marc Petit-Huguenin + + Author/Change controller: The IESG + + References: RFC 7065 + +5.2. "turns" URI Registration + + URI scheme name: turns + + Status: permanent + + URI scheme syntax: See Section 3.1. + + URI scheme semantics: See Section 3.2. + + Encoding considerations: There are no encoding considerations beyond + those in [RFC3986]. + + Applications/protocols that use this URI scheme name: + + The "turns" URI scheme is intended to be used by applications with + a need to identify a TURN server to be used for NAT traversal over + a secure connection. + + Interoperability considerations: N/A + + Security considerations: See Section 4. + + Contact: Marc Petit-Huguenin + + Author/Change controller: The IESG + + References: RFC 7065 + +6. Acknowledgements + + Thanks to Margaret Wasserman, Magnus Westerlund, Juergen + Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. + Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes, and Jim Kleck for + the comments, suggestions, and questions that helped improve + "Traversal Using Relays around NAT (TURN) Uniform Resource + Identifiers" by M. Petit-Huguenin (October 2011). + + + + +Petit-Huguenin, et al. Standards Track [Page 6] + +RFC 7065 TURN URIs November 2013 + + + Many thanks to Cullen Jennings for his detailed review and thoughtful + comments on "URI Scheme for Traversal Using Relays around NAT (TURN) + Protocol" by S. Nandakumar, et al. (October 2011). + + Thanks to Bjoern Hoehrmann, Dan Wing, Russ Housley, S. Moonesamy, + Graham Klyne, Harald Alvestrand, Hadriel Kaplan, Tina Tsou, Spencer + Dawkins, Ted Lemon, Barry Leiba, Pete Resnick, and Stephen Farrell + for the comments, suggestions, and questions that helped improve this + document. + + The authors would also like to express their gratitude to Dan Wing + for his assistance in shepherding this document. We also want to + thank Gonzalo Camarillo, the Real-time Applications and + Infrastructure Area Director, for sponsoring this document as well as + his careful reviews. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using + Relays around NAT (TURN): Relay Extensions to Session + Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. + + [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT + (TURN) Resolution Mechanism", RFC 5928, August 2010. + +7.2. Informative References + + [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and + Registration Procedures for New URI Schemes", BCP 35, RFC + 4395, February 2006. + + [WEBRTC] Bergkvist, A., Burnett, D., Jennings, C., and A. + Narayanan, "WebRTC 1.0: Real-time Communication Between + Browsers", World Wide Web Consortium WD + WD-webrtc-20120821, August 2012, + . + + + +Petit-Huguenin, et al. Standards Track [Page 7] + +RFC 7065 TURN URIs November 2013 + + +Appendix A. Examples + + Table 1 shows how the , , and components + are populated from various URIs. For all these examples, the + component is populated with "example.org". + + +---------------------------------+----------+--------+-------------+ + | URI | | | | + +---------------------------------+----------+--------+-------------+ + | turn:example.org | false | | | + | turns:example.org | true | | | + | turn:example.org:8000 | false | 8000 | | + | turn:example.org?transport=udp | false | | UDP | + | turn:example.org?transport=tcp | false | | TCP | + | turns:example.org?transport=tcp | true | | TLS | + +---------------------------------+----------+--------+-------------+ + + Table 1 + +Appendix B. Design Notes + + o One recurring comment was to stop using the suffix "s" on the URI + scheme, and to move the secure option to a parameter (e.g. + ";proto=tls"). We decided against this idea because the STUN URI + does not have a ";proto=" parameter and we would have lost the + symmetry between the TURN and STUN URIs. + + o Following the advice of Section 2.2 of RFC 4395, and because the + TURN URI does not describe a hierarchical structure, the TURN URIs + are opaque URIs. + + o is not used in the URIs because it is deprecated + [RFC3986]. and are not used in the URIs because + they do not guide the resolution mechanism. + + o As discussed at IETF 72 in Dublin, there are no generic parameters + in the URI to prevent compatibility issues. + + + + + + + + + + + + + + +Petit-Huguenin, et al. Standards Track [Page 8] + +RFC 7065 TURN URIs November 2013 + + +Authors' Addresses + + Marc Petit-Huguenin + Impedance Mismatch + + EMail: petithug@acm.org + + + Suhas Nandakumar + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + US + + EMail: snandaku@cisco.com + + + Gonzalo Salgueiro + Cisco Systems + 7200-12 Kit Creek Road + Research Triangle Park, NC 27709 + US + + EMail: gsalguei@cisco.com + + + Paul E. Jones + Cisco Systems + 7025 Kit Creek Road + Research Triangle Park, NC 27709 + US + + EMail: paulej@packetizer.com + + + + + + + + + + + + + + + + + + +Petit-Huguenin, et al. Standards Track [Page 9] + -- cgit v1.2.3