RFC 5928

Traversal Using Relays around NAT (TURN) Resolution Mechanism

📅 published August 2010, from ietf

RFC 5928: Traversal Using Relays around NAT (TURN) Resolution Mechanism 💖

okay bestie, this is RFC 5928 🦋 It's a Standards Track doc from the IETF, dated August 2010, written by M. Petit-Huguenin (Unaffiliated) ✨ Its ISSN is 2070-1721 🎀 The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 🙈

Abstract ✨

so the big idea is this: the doc defines a resolution mechanism that builds a list of server transport addresses you can try when you want to create a Traversal Using Relays around NAT (TURN) allocation 💅 it's giving organized server shortlist energy 🌸

Status of This Memo 📜

this one's a Standards Track document, bestie 👑 It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 💜

for the current status, errata, and feedback, go to http://www.rfc-editor.org/info/rfc5928 🔥

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Yes, that's a whole legal flex, but it's important 🙈

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the date it was published. Please read these carefully, bestie, because they spell out what you're allowed to do and what you're not 💅 If you extract any Code Components from this doc, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🧚

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 ✨

okay so the TURN spec [RFC5766] has a way for a TURN client to find TURN servers using DNS SRV resource records 🦋 BUT, and this is the tea ☕, that process doesn't let TURN server admins set up which TURN transport protocol they prefer between client and server. And the client can't find out that preference either 😭 This doc fixes that by defining an S-NAPTR application [RFC3958] for exactly this purpose 💅 It defines "RELAY" as an application service tag, and "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags 🌸

here's another use for the resolution mechanism in this doc: Remote Hosting, as described in [RFC3958], Section 4.4 🧚 Picture a Voice over IP (VoIP) provider who doesn't want to deploy TURN servers, so they use servers run by another company. They still want to hand their customers config parameters without openly showing that relationship 🙈 The mechanism lets them do that indirection, and the company hosting the TURN servers can still manage them however it sees fit 💖 that's iconic, honestly 👑

[TURN-URI] is a handy way to carry the four components (see Section 3) that the resolution mechanism here needs 🎀 There's also a reference implementation, [REF-IMPL] 🔥

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] 💜 bestie, remember these are the real deal, not just vibes ✨

3. Resolution Mechanism ✨

Okay so the resolution mechanism is only used to create an allocation 🦋 Every other transaction just reuses the IP address, transport, and port that worked for the successful allocation creation. The resolution mechanism only picks the transport between the TURN client and the TURN server. The transport the allocation itself uses gets selected by the REQUESTED-TRANSPORT attribute, as described in Section 6.1 of [RFC5766] 💅

The resolution algorithm takes in a boolean flag called <secure>, an IP address or domain name called <host>, a port number that can be empty called <port>, and a transport name that can be "udp", "tcp", or empty called <transport> 🎀 These four are part of the TURN client's user configuration. It also takes a list, ordered by preference, of the TURN transports the app supports (UDP, TCP, Transport Layer Security (TLS)). The app provides that list, and it reflects what the application code can do and prefers, which is different from the preferences of the person using the app 🧚 The output 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 treated as a failure, as specified by [RFC3958], Section 2.2.4 😭 Resolution stops once 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 later allocation. Servers that get 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 a later resolution returns them 🙈

First, the algorithm checks that the parameters can be resolved with the list of TURN transports the application supports:

  • 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.
  • 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.
  • If <secure> is true and <transport> is defined as "udp", then the resolution MUST stop with an error.
  • 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.
  • 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.
  • If <transport> is defined but unknown, then the resolution MUST stop with an error.

Once the parameters check out, the algorithm filters the app's list of TURN transports by removing the UDP and TCP TURN transports if <secure> is true. If the list is empty after this filtering, the resolution MUST stop with an error 🍓

After filtering, the algorithm runs through the steps below. Heads up, in some steps <secure> and <transport> have to be converted into a TURN transport. If <secure> is false and <transport> is "udp", the TURN UDP transport is used. If <secure> is false and <transport> is "tcp", the TURN TCP transport is used. If <secure> is true and <transport> is "tcp", the TURN TLS transport is used. Table 1 sums it all up 👑

                +----------+-------------+----------------+
                | <secure> | <transport> | TURN Transport |
                +----------+-------------+----------------+
                | false    | "udp"       | UDP            |
                | false    | "tcp"       | TCP            |
                | true     | "tcp"       | TLS            |
                +----------+-------------+----------------+

                                  Table 1
  1. If <host> is an IP address, then it points at the specific IP address to use. If <port> is not defined, then the default port declared in [RFC5766] for the "turn" SRV service name is used if <secure> is false, or the "turns" SRV service name is used if <secure> is true. That port MUST be used for contacting the TURN server. If <transport> is defined, then <secure> and <transport> get 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. If the TURN client cannot contact a TURN server with this IP address and port on any of the transports the application supports, then the resolution MUST stop with an error.
  2. If <host> is a domain name and <port> is defined, then <host> gets resolved to a list of IP addresses via DNS A and AAAA queries. If <transport> is defined, then <secure> and <transport> get 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 pick the order for contacting 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 the Name. The Service is "turn" if <secure> is false, or "turns" if <secure> is true. <transport> is used as the Protocol (Proto) in the SRV algorithm. <secure> and <transport> get converted to a TURN transport as specified in Table 1, and that 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 that 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. This specification also modifies the SRV algorithm by recommending an A and AAAA query in this case. If the TURN client cannot contact a TURN server at any of the IP address and port tuples returned by the SRV algorithm using the transport converted from <secure> and <transport>, then the resolution MUST stop with an error.
  4. If <host> is a domain name and both <port> and <transport> are not defined, then <host> gets converted to an ordered list of IP address, port, and transport tuples via the Straightforward Naming Authority Pointer (S-NAPTR) algorithm defined in [RFC3958]. It uses <host> as the initial target domain name and "RELAY" as the application service tag. The filtered list of TURN transports supported by the application gets turned into application protocol tags: "turn.udp" if the TURN transport is UDP, "turn.tcp" if it's TCP, and "turn.tls" if it's TLS. The order to try the application protocol tags comes from the ranking of the first set of NAPTR records. If multiple application protocol tags have the same ranking, the order the application prefers is used. If the first NAPTR query fails, 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 runs once for each transport in the filtered list of TURN transports supported by the application, using that transport as the Protocol (Proto), <host> as the Name, and "turn" as the Service if <secure> is false, or "turns" if <secure> is true. The same transport that generated a list of tuples gets used with each of those 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 that 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. This specification also modifies the SRV algorithm by recommending an A and AAAA query in this case. If the TURN client cannot contact a TURN server at any of the IP address and port tuples returned by the SRV algorithm using the transports from the filtered list, then the resolution MUST stop with an error.

4. Examples 🌈

4.1. Multiple Protocols

Let's do an example 🦋 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) into the list of IP address, port, and protocol tuples in Table 2 ✨

   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

Now for the remote hosting drama 💜 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, except with the <host> parameter set to "example.com", into 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

4.3. Compatibility with TURN ✨

okay so, real talk: sometimes you can't promise that every TURN client out there knows about this resolution mechanism 🥺. So the DNS setup should be done in a way that works with both this mechanism AND the one from [RFC5766] 🫶. The DNS RRs in Figure 3 can be used alongside the ones in Figures 1 and 2 to make that happen 💖.

_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 🔒

bestie, this part is SERIOUS 😭. Security considerations for TURN are covered in [RFC5766] 🦋.

The application service tag and application protocol tags defined in this document don't add any special new security problems on top of the ones already talked about in [RFC3958] 💅. [RFC3958] asks that an S-NAPTR application define some kind of end-to-end authentication so you know you've reached the right destination 👀. That's handled by the Long-Term Credential Mechanism in [RFC5389], which is mandatory for [RFC5766] 🔥.

Also, TLS [RFC5246] can help with that same requirement 🌸. In that case, the client MUST verify the identity of the server by following the identification procedure in Section 7.2.2 of [RFC5389], and it has to use the value of the <host> parameter as the identity of the server it's checking 🫶.

Here's the tea ☕: the server's certificate might need to change when SRV or NAPTR records get added 😭. For example, a client that only uses A/AAAA records and is configured with "turnserver.example.net" expects to find the name "turnserver.example.net" in the certificate 🧚. But a second client that uses SRV records and is configured with the <host> parameter "example.com" expects to find "example.com" in the certificate, even if the SRV record at _turns._tcp.example.com points to turnserver.example.net 💀.

6. IANA Considerations 📝

This section has the registration info for one S-NAPTR application service tag and three S-NAPTR application protocol tags (following [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.

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 🫶

Huge 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 made this doc better 👑.

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.

[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
📦 where this page comes from