diff options
Diffstat (limited to 'doc/rfc/rfc5928.txt')
| -rw-r--r-- | doc/rfc/rfc5928.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc5928.txt b/doc/rfc/rfc5928.txt new file mode 100644 index 0000000..bc055c5 --- /dev/null +++ b/doc/rfc/rfc5928.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Petit-Huguenin +Request for Comments: 5928 Unaffiliated +Category: Standards Track August 2010 +ISSN: 2070-1721 + + + Traversal Using Relays around NAT (TURN) Resolution Mechanism + +Abstract + + This document defines a resolution mechanism to generate a list of + server transport addresses that can be tried to create a Traversal + Using Relays around NAT (TURN) allocation. + +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/rfc5928. + +Copyright Notice + + Copyright (c) 2010 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 Standards Track [Page 1] + +RFC 5928 TURN Resolution August 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Resolution Mechanism . . . . . . . . . . . . . . . . . . . . . 3 + 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Multiple Protocols . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Remote Hosting . . . . . . . . . . . . . . . . . . . . . . 7 + 4.3. Compatibility with TURN . . . . . . . . . . . . . . . . . 8 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6.1. RELAY Application Service Tag Registration . . . . . . . . 9 + 6.2. turn.udp Application Protocol Tag Registration . . . . . . 9 + 6.3. turn.tcp Application Protocol Tag Registration . . . . . . 9 + 6.4. turn.tls Application Protocol Tag Registration . . . . . . 10 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 + +1. Introduction + + The Traversal Using Relays around NAT (TURN) specification [RFC5766] + 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 server + administrators provision the preferred TURN transport protocol + between the client and the server and does not allow the TURN client + to discover this preference. This document defines an S-NAPTR + application [RFC3958] for this purpose. This application defines + "RELAY" as an application service tag and "turn.udp", "turn.tcp", and + "turn.tls" as application protocol tags. + + Another usage of the resolution mechanism described in this document + would be Remote Hosting as described in [RFC3958], Section 4.4. For + example, a Voice over IP (VoIP) provider who does not want to deploy + TURN servers could use the servers deployed by another company but + could still want to provide configuration parameters to its customers + without explicitly showing this relationship. The mechanism permits + one to implement this indirection, without preventing the company + hosting the TURN servers from managing them as it sees fit. + + [TURN-URI] can be used as a convenient way of carrying the four + components (see Section 3) needed by the resolution mechanism + described in this document. A reference implementation is available + [REF-IMPL]. + + + + + + +Petit-Huguenin Standards Track [Page 2] + +RFC 5928 TURN Resolution August 2010 + + +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. Resolution Mechanism + + The resolution mechanism is used only to create an allocation. All + other transactions use the IP address, transport, and port used for a + successful allocation creation. The resolution mechanism only + selects the transport used between the TURN client and the TURN + server. The transport used by the allocation itself is selected by + the REQUESTED-TRANSPORT attribute as described in Section 6.1 of + [RFC5766]. + + The resolution algorithm uses a boolean flag, <secure>; an IP address + or domain name, <host>; a port number that can be empty, <port>; and + a transport name that can be "udp", "tcp", or empty, <transport> as + input. These four parameters are part of the user configuration of + the TURN client. The resolution mechanism also uses as input a list, + ordered by preference of supported TURN transports (UDP, TCP, + Transport Layer Security (TLS)), that is provided by the application + using the TURN client. This list reflects the capabilities and + preferences of the application code that is using the S-NAPTR + resolver and TURN client, as opposed to the configuration parameters + that reflect the preferences of the user of the application. The + output of the algorithm is a list of {IP address, transport, port} + tuples that a TURN client can try in order to create an allocation on + a TURN server. + + An Allocate error response as specified in Section 6.4 of [RFC5766] + is processed as a failure, as specified by [RFC3958], Section 2.2.4. + The resolution stops when a TURN client gets a successful Allocate + response from a TURN server. After an allocation succeeds or all the + allocations fail, the resolution context MUST be discarded, and the + resolution algorithm MUST be restarted from the beginning for any + subsequent allocation. Servers temporarily blacklisted as described + in Section 6.4 of [RFC5766], specifically because of a 437, 486, or + 508 error code, MUST NOT be used for the specified duration, even if + returned by a subsequent resolution. + + First, the resolution algorithm checks that the parameters can be + resolved with the list of TURN transports supported by the + application: + + + + + + +Petit-Huguenin Standards Track [Page 3] + +RFC 5928 TURN Resolution August 2010 + + + o If <secure> is false and <transport> is defined as "udp" but the + list of TURN transports supported by the application does not + contain UDP, then the resolution MUST stop with an error. + + o If <secure> is false and <transport> is defined as "tcp" but the + list of TURN transports supported by the application does not + contain TCP, then the resolution MUST stop with an error. + + o If <secure> is true and <transport> is defined as "udp", then the + resolution MUST stop with an error. + + o If <secure> is true and <transport> is defined as "tcp" but the + list of TURN transports supported by the application does not + contain TLS, then the resolution MUST stop with an error. + + o If <secure> is true and <transport> is not defined but the list of + TURN transports supported by the application does not contain TLS, + then the resolution MUST stop with an error. + + o If <transport> is defined but unknown, then the resolution MUST + stop with an error. + + After verifying the validity of the parameters, the algorithm filters + the list of TURN transports supported by the application by removing + the UDP and TCP TURN transport if <secure> is true. If the list of + TURN transports is empty after this filtering, the resolution MUST + stop with an error. + + After filtering the list of TURN transports supported by the + application, the algorithm applies the steps described below. Note + that in some steps, <secure> and <transport> have to be converted to + a TURN transport. If <secure> is false and <transport> is defined as + "udp", then the TURN UDP transport is used. If <secure> is false and + <transport> is defined as "tcp", then the TURN TCP transport is used. + If <secure> is true and <transport> is defined as "tcp", then the + TURN TLS transport is used. This is summarized in Table 1. + + +----------+-------------+----------------+ + | <secure> | <transport> | TURN Transport | + +----------+-------------+----------------+ + | false | "udp" | UDP | + | false | "tcp" | TCP | + | true | "tcp" | TLS | + +----------+-------------+----------------+ + + Table 1 + + + + + +Petit-Huguenin Standards Track [Page 4] + +RFC 5928 TURN Resolution August 2010 + + + 1. If <host> is an IP address, then it indicates the specific IP + address to be used. If <port> is not defined, then either the + default port declared in [RFC5766] for the "turn" SRV service + name if <secure> is false, or the "turns" SRV service name if + <secure> is true, MUST be used for contacting the TURN server. + If <transport> is defined, then <secure> and <transport> are + converted to a TURN transport as specified in Table 1. If + <transport> is not defined, the filtered 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 supported by the application, + 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 <secure> and <transport> are + converted to a TURN transport as specified in Table 1. If + <transport> is not defined, the filtered TURN transports + supported by the application are tried in preference order. The + TURN client can choose the order to contact the resolved IP + addresses in any implementation-specific way. If the TURN client + cannot contact a TURN server with this port, the transport or + list of transports, and the 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 the SRV algorithm defined in + [RFC2782] is used to generate a list of IP address and port + tuples. <host> is used as Name, a value of false for <secure> as + "turn" for Service, a value of true for <secure> as "turns" for + Service, and <transport> as Protocol (Proto) in the SRV + algorithm. <secure> and <transport> are converted to a TURN + transport as specified in Table 1, and this transport is used + with each tuple for contacting the TURN server. The SRV + algorithm recommends doing an A query if the SRV query returns an + error or no SRV RR; in this case, the default port declared in + [RFC5766] for the "turn" SRV service name if <secure> is false, + or the "turns" SRV service name if <secure> is true, MUST be used + for contacting the TURN server. Also in this case, this + specification modifies the SRV algorithm by recommending an A and + AAAA query. If the TURN client cannot contact a TURN server at + any of the IP address and port tuples returned by the SRV + algorithm with the transport converted from <secure> and + <transport>, then the resolution MUST stop with an error. + + + + + + + +Petit-Huguenin Standards Track [Page 5] + +RFC 5928 TURN Resolution August 2010 + + + 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 Straightforward + Naming Authority Pointer (S-NAPTR) algorithm defined in [RFC3958] + by using <host> as the initial target domain name and "RELAY" as + the application service tag. The filtered list of 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 + application protocol tags is provided by the ranking of the first + set of NAPTR records. If multiple application protocol tags have + the same ranking, the preferred order set by the application is + used. If the first NAPTR query fails, the processing continues + in step 5. 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. + + 5. If the first NAPTR query in the previous step does not return any + result, then the SRV algorithm defined in [RFC2782] is used to + generate a list of IP address and port tuples. The SRV algorithm + is applied by using each transport in the filtered list of TURN + transports supported by the application for the Protocol (Proto), + <host> for the Name, "turn" for the Service if <secure> is false, + or "turns" for the Service if <secure> is true. The same + transport that was used to generate a list of tuples is used with + each of these tuples for contacting the TURN server. The SRV + algorithm recommends doing an A query if the SRV query returns an + error or no SRV RR; in this case, the default port declared in + [RFC5766] for the "turn" SRV service name if <secure> is false, + or the "turns" SRV service name if <secure> is true, MUST be used + for contacting the TURN server. Also in this case, this + specification modifies the SRV algorithm by recommending an A and + AAAA query. If the TURN client cannot contact a TURN server at + any of the IP address and port tuples returned by the SRV + algorithm with the transports from the filtered list, then the + resolution MUST stop with an error. + +4. Examples + +4.1. Multiple Protocols + + With the DNS RRs in Figure 1 and an ordered TURN transport list of + {TLS, TCP, UDP}, the resolution algorithm will convert the parameters + (<secure>=false, <host>="example.net", <port>=empty, + <transport>=empty) to the list of IP address, port, and protocol + tuples in Table 2. + + + + +Petit-Huguenin Standards Track [Page 6] + +RFC 5928 TURN Resolution August 2010 + + + example.net. + IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net. + IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net. + + datagram.example.net. + IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. + + stream.example.net. + IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. + IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net. + + _turn._udp.example.net. + IN SRV 0 0 3478 a.example.net. + + _turn._tcp.example.net. + IN SRV 0 0 5000 a.example.net. + + a.example.net. + IN A 192.0.2.1 + + Figure 1 + + + +-------+----------+------------+------+ + | Order | Protocol | IP address | Port | + +-------+----------+------------+------+ + | 1 | UDP | 192.0.2.1 | 3478 | + | 2 | TLS | 192.0.2.1 | 5349 | + | 3 | TCP | 192.0.2.1 | 5000 | + +-------+----------+------------+------+ + + Table 2 + +4.2. Remote Hosting + + In the example in Figure 2, a VoIP provider (example.com) is using + the TURN servers managed by the administrators of the example.net + domain (defined in Figure 1). The resolution algorithm using the + ordered TURN transport list of {TLS, TCP, UDP} would convert the same + parameters as in the previous example but with the <host> parameter + equal to "example.com" to the list of IP address, port, and protocol + tuples in Table 2. + + example.com. + IN NAPTR 100 10 "" RELAY:turn.udp:turn.tcp:turn.tls "" example.net. + + Figure 2 + + + + +Petit-Huguenin Standards Track [Page 7] + +RFC 5928 TURN Resolution August 2010 + + +4.3. Compatibility with TURN + + In deployments where it is not possible to guarantee that all TURN + clients will support the resolution mechanism described in this + document, the DNS configuration should be done in a way that works + with both this resolution mechanism and the mechanism described in + [RFC5766]. The DNS RRs in Figure 3 can be used in conjunction with + the DNS RRs in Figures 1 and 2 for this purpose. + + _turn._udp.example.com. + IN SRV 0 0 3478 a.example.net. + + _turn._tcp.example.com. + IN SRV 0 0 5000 a.example.net. + + _turns._tcp.example.com. + IN SRV 0 0 5349 a.example.net. + + Figure 3 + +5. Security Considerations + + Security considerations for TURN are discussed in [RFC5766]. + + The application service tag and application protocol tags defined in + this document do not introduce any specific security issues beyond + the security considerations discussed in [RFC3958]. [RFC3958] + requests that an S-NAPTR application define some form of end-to-end + authentication to ensure that the correct destination has been + reached. This is achieved by the Long-Term Credential Mechanism + defined in [RFC5389], which is mandatory for [RFC5766]. + + Additionally, the usage of TLS [RFC5246] has the capability to + address the requirement. In this case, the client MUST verify the + identity of the server by following the identification procedure in + Section 7.2.2 of [RFC5389] and by using the value of the <host> + parameter as the identity of the server to be verified. + + An implication of this is that the server's certificate could need to + be changed when SRV or NAPTR records are added. For example, a + client using just A/AAAA records, and configured with + "turnserver.example.net", expects to find the name + "turnserver.example.net" in the certificate. If a second client uses + SRV records and is configured with <host> parameter "example.com", it + expects to find "example.com" in the certificate, even if the SRV + record at _turns._tcp.example.com points to turnserver.example.net. + + + + + +Petit-Huguenin Standards Track [Page 8] + +RFC 5928 TURN Resolution August 2010 + + +6. IANA Considerations + + This section contains the registration information for one S-NAPTR + application service tag and three S-NAPTR application protocol tags + (in accordance with [RFC3958]). + +6.1. RELAY Application Service Tag Registration + + Application Protocol Tag: RELAY + + Intended usage: See Section 3. + + Interoperability considerations: N/A + + Security considerations: See Section 5. + + Relevant publications: RFC 5928 + + Contact information: Marc Petit-Huguenin <petithug@acm.org> + + Author/Change controller: The IESG + +6.2. turn.udp Application Protocol Tag Registration + + Application Protocol Tag: turn.udp + + Intended usage: See Section 3. + + Interoperability considerations: N/A + + Security considerations: See Section 5. + + Relevant publications: RFC 5928 + + Contact information: Marc Petit-Huguenin <petithug@acm.org> + + Author/Change controller: The IESG + +6.3. turn.tcp Application Protocol Tag Registration + + Application Protocol Tag: turn.tcp + + Intended usage: See Section 3. + + Interoperability considerations: N/A + + Security considerations: See Section 5. + + + + +Petit-Huguenin Standards Track [Page 9] + +RFC 5928 TURN Resolution August 2010 + + + Relevant publications: RFC 5928 + + Contact information: Marc Petit-Huguenin <petithug@acm.org> + + Author/Change controller: The IESG + +6.4. turn.tls Application Protocol Tag Registration + + Application Protocol Tag: turn.tls + + Intended usage: See Section 3. + + Interoperability considerations: N/A + + Security considerations: See Section 5. + + Relevant publications: RFC 5928 + + Contact information: Marc Petit-Huguenin <petithug@acm.org> + + Author/Change controller: The IESG + +7. Acknowledgements + + Thanks to Cullen Jennings, Alexey Melnikov, Scott Bradner, Spencer + Dawkins, Pasi Eronen, 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 + their comments, suggestions, and questions that helped to improve + this document. + +8. References + +8.1. 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. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + + +Petit-Huguenin Standards Track [Page 10] + +RFC 5928 TURN Resolution August 2010 + + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + October 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. + +8.2. Informative References + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [TURN-URI] Petit-Huguenin, M., "Traversal Using Relays around NAT + (TURN) Uniform Resource Identifiers", Work in Progress, + January 2010. + + [REF-IMPL] Petit-Huguenin, M., "Reference Implementation of TURN + resolver and TURN URI parser", January 2010, <http:// + debian.implementers.org/stable/source/turnuri.tar.gz>. + +Author's Address + + Marc Petit-Huguenin + Unaffiliated + + EMail: petithug@acm.org + + + + + + + + + + + + + + + + + + + + + + + +Petit-Huguenin Standards Track [Page 11] + |