RFC 8155

Traversal Using Relays around NAT (TURN) Server Auto Discovery

📅 published April 2017, from ietf

1. Introduction ✨

Okay so, bestie, the title block first 🎀 This doc is RFC 8155, called Traversal Using Relays around NAT (TURN) Server Auto Discovery, written by P. Patil, T. Reddy (Cisco) and D. Wing in April 2017. It's a Standards Track doc 🫶 and it updates RFC 5766, which is the original TURN spec. It doesn't obsolete anything.

The big idea: right now TURN servers have to be set up by hand, or the app or TURN service provider picks them for you. Enterprises and ISPs who want to run their own TURN servers need a way for clients to find them automatically, with little or no setup. This doc describes three discovery mechanisms to make that happen 💅

Here's the full section map so you know where we're headed 🗺️

1.  Introduction
2.  Terminology
3.  Discovery Procedure
4.  Discovery Using Service Resolution
  4.1.  Retrieving Domain Name
    4.1.1.  DHCP
    4.1.2.  From Own Identity
  4.2.  Resolution
5.  DNS Service Discovery
  5.1.  mDNS
6.  Discovery Using Anycast
7.  Deployment Considerations
  7.1.  Mobility and Changing IP Addresses
  7.2.  Recursively Encapsulated TURN
8.  IANA Considerations
  8.1.  IPv4 Anycast
  8.2.  IPv6 Anycast
9.  Security Considerations
  9.1.  Service Resolution
  9.2.  DNS Service Discovery
  9.3.  Anycast
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Authors' Addresses

Now the intro itself 💖 TURN is a protocol people use a lot to make Peer-to-Peer (P2P) apps connect better (see Section 2.7 of [RFC5128] for what P2P means). It lets a connection get set up even when one side or both sides can't connect directly 🦋 It's a huge building block for real-time stuff like audio, video, and collab. Literally everywhere 😭

TURN servers are used a ton today, but there's no way to automatically find them. Clients are usually told about one well-known TURN server ahead of time. So if we want TURN apps to work smoothly across all kinds of networks, and want people to use TURN without fiddling with settings, we need an auto-discovery mechanism for TURN services 🌈 Web Real-Time Communication (WebRTC) [WebRTC-Overview] usages and extensions are mostly web apps, so they especially need TURN server discovery 🍓

The three discovery mechanisms are:

  • A resolution mechanism based on Straightforward-Naming Authority Pointer (S-NAPTR) resource records in the Domain Name System (DNS). [RFC5928] explains how to pull a list of server transport addresses from DNS that you can use to make a TURN allocation 🧚
  • DNS Service Discovery.
  • A mechanism based on an anycast address for TURN.

The point is to cover as many cases as possible, depending on which network the TURN client is sitting on 🎀

Last one for this part 🙈 If a client wants to talk over one of its interfaces using a specific IP address family, it SHOULD query the TURN server(s) discovered for that exact interface and address family. How to pick the interface and address family is out of scope for this doc 💜

2. Terminology 🌸

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

These are the BCP 14 key words, and they keep their exact meaning from [RFC2119] 💅

3. Discovery Procedure ✨

Okay so, by default, TURN clients find TURN servers through local or manual config, meaning TURN servers set at the system level 🫶 Config that comes from an app counts as local config too. Like a JavaScript-specified TURN server for WebRTC [WebRTC-Overview] usages and extensions 💖 An implementation may let the user pick a TURN server for each address family, using stuff like config file options or menu items 🎀

A client can use auto-discovery when there's no local config, when local config doesn't work, or in addition to local config 🦋 This doc does not recommend anything about server selection, so that's not on us 🙈

A TURN client that does auto-discovery to find TURN servers on the attached network uses these mechanisms:

  • Service Resolution: The TURN client tries TURN service resolution using the host's DNS domain.
  • DNS SD: DNS Service Discovery.
  • Anycast: Send a TURN Allocation request to the assigned TURN anycast address for each combination of interface and address family.

Not every TURN server can be found through NAPTR records or DNS SD 🧚 And not every TURN server supports anycast either 😭 For the best results, a client SHOULD implement all of the discovery mechanisms above 💜

The doc does not set a strict order a client MUST follow for discovery 🌈 Wait, it's a SHOULD-free zone here, so no requirement on order. An implementation can run all the steps in parallel, OR pick any order it likes and stop once a mechanism works 🔥

On hosts with more than one interface or address family (IPv4/v6), the TURN server discovery procedure has to be performed for each combination of interface and address family 🍓 A client MAY choose to run discovery only for a desired interface and address combination, if it doesn't want to find a TURN server for every combination 👑

4. Discovery Using Service Resolution 💅

This mechanism happens in two steps 🎀

  1. A DNS domain name is retrieved for each combination of interface and address family.
  2. The retrieved DNS domain names are then used for S-NAPTR lookups as per [RFC5928]. More DNS lookups may be needed to figure out the TURN server IP address(es) 🦋

4.1. Retrieving Domain Name 🌸

A client has to figure out what domain it's in 💖 The next sections give two possible ways to learn the domain name, but other ways exist too (they're outside this doc's scope), like local config 🧚

Implementations may let the user set a default name that gets used if no specific name has been configured 🫶

4.1.1. DHCP ✨

DHCP can be used to figure out the domain name for an interface's point of network attachment 🎀 Network operators may give the domain name to use for service discovery within an access network using DHCP 🦋 Sections 3.2 and 3.3 of [RFC5986] define the DHCP IPv4 and IPv6 access network domain name options, OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN respectively, to identify a domain name suitable for service discovery within the access network 💜

For IPv4, the discovery procedure MUST request the access network domain name option in a Parameter Request List option, as described in [RFC2131]. [RFC2132] defines the DHCP IPv4 domain name option. It's less suitable, but a client MAY request it if the access network domain name from [RFC5986] isn't available 🌈

For IPv6, the discovery procedure MUST request the access network domain name option in an Options Request Option (ORO) within an Information-request message, as described in [RFC3315] 🔥

If neither option can be retrieved, the procedure fails for this interface 😭 If a result does come back, it gets used as input for S-NAPTR resolution 🍓

4.1.2. From Own Identity 🧚

Okay, for a TURN client that understands how calling apps work, it may want to pull the domain name out of its own identity, meaning the canonical identifier used to reach the user 💖

Example:

SIP      : 'sip:alice@example.com'
Bare JID : 'alice@example.com'
email    : 'alice@example.com'

'example.com' is what gets pulled from the examples above ✨

A client may support multiple users, possibly with different domains, or one user using different domains for different services 🌈 How to choose and extract the domain name may vary based on the identifier type, the service being used, and so on. That's all outside this doc's scope 💅

Part 1 ends here, bestie 🫶 Three more parts are coming with the rest of the spec, including section 4.2 onwards 🦋

4.2. Resolution ✨

Okay so once the TURN discovery procedure has pulled out the domain names, we use the resolution mechanism from [RFC5928] 💅. We do an S-NAPTR lookup with the RELAY application service and the protocol tag we want, and that gives us what we need to connect to the authoritative TURN server for that domain 🎀.

If there are no TURN-specific S-NAPTR records to be found, the discovery procedure fails for that domain name (and the matching interface and IP protocol version) 💀. If we know about more domain names, we may run their S-NAPTR lookups right away 🦋. But before retrying a lookup that failed, a client must wait a time period that fits the error it hit (NXDOMAIN, timeout, etc.) 🫶.

5. DNS Service Discovery 🧚

DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS (mDNS) [RFC6762] are the generic solutions for finding services on a local network 🌸. DNS-SD and mDNS define naming rules for certain DNS record types, and they use those rules for advertising and discovering services 💜.

Section 4.1 of [RFC6763] says a service instance name in DNS-SD looks like this:

<Instance> . <Service> . <Domain>

The <Domain> part says which DNS sub-domain the service instance is registered in 🌈. It may be local., which means the mDNS local domain, or it may be a regular domain name like example.com. ✨. The <Service> part of a TURN service instance name MUST be _turn._udp or _turn._tcp or _turns._udp or _turns._tcp, as introduced in [RFC5766] 👑.

5.1. mDNS 🍓

A TURN client can go looking for TURN servers proactively by multicasting a PTR query to one or all of these:

  • _turn._udp.local.
  • _turn._tcp.local
  • _turns._udp.local.
  • _turns._tcp.local

A TURN server can send out gratuitous multicast DNS answer packets whenever it starts up, wakes from sleep, or notices a change in network configuration 😭. TURN clients catch these gratuitous packets and cache the info inside them 💖.

6. Discovery Using Anycast 🌈

IP anycast can be used for TURN service discovery too 🦋. A packet sent to an anycast address gets delivered to the "topologically nearest" network interface that has that anycast address 🧭. With the TURN anycast address, the only two things that need to be deployed in the network for discovery are the two things that actually use TURN, which is honestly so efficient 🙈.

When a client needs TURN services, it sends a TURN Allocation request to the assigned anycast address 💅. A TURN anycast server performs checks 1 through 7 from Section 6.2 of [RFC5766] ✨. If every check passes, the TURN anycast server MUST respond with a 300 (Try Alternate) error, as described in Section 2.9 of [RFC5766] 🔥. That response carries the TURN unicast address in the ALTERNATE-SERVER attribute 🎀. For any later communication with the TURN server, the client uses the responding server's unicast address, because two packets sent to an anycast address might reach two different anycast servers 😭. So the client also needs to make sure the initial request fits in a single packet 📦. An implementation may choose to send every new TURN Allocation request to the anycast address, to find the closest and most optimal unicast address for the TURN server 🧚.

7. Deployment Considerations 🌸

7.1. Mobility and Changing IP Addresses 🚗

A change of IP address on an interface can invalidate the result of the TURN server discovery procedure 💀. For example, if the IP address of a mobile host changes because of host mobility, it may be required to re-run the TURN server discovery procedure without relying on info we got earlier 🙈. New requests should be made to the newly learned TURN servers that were learned after the TURN discovery was re-run 🦋. However, if an earlier learned TURN server is still accessible using the new IP address, the mobility procedures for TURN defined in [RFC8016] can be used for ongoing streams 💜.

7.2. Recursively Encapsulated TURN 🪆

WebRTC endpoints SHOULD treat any TURN server discovered through the mechanisms in this specification as an enterprise/gateway or access network server, following Recursively Encapsulated TURN [RETURN] 👑🫶.

8. IANA Considerations 📋

8.1. IPv4 Anycast 🌐

IANA has assigned a single IPv4 address from the 192.0.0.0/24 prefix and registered it in the "IANA IPv4 Special-Purpose Address Registry" [RFC6890] 🎀.

    +----------------------+-------------------------------------------+
    | Attribute            | Value                                     |
    +----------------------+-------------------------------------------+
    | Address Block        | 192.0.0.10/32                             |
    | Name                 | Traversal Using Relays around NAT Anycast |
    | RFC                  | RFC 8155                                  |
    | Allocation Date      | 2017-02                                   |
    | Termination Date     | N/A                                       |
    | Source               | True                                      |
    | Destination          | True                                      |
    | Forwardable          | True                                      |
    | Global               | True                                      |
    | Reserved-by-Protocol | False                                     |
    +----------------------+-------------------------------------------+

8.2. IPv6 Anycast 🌸

IANA has assigned a single IPv6 address from the 2001:0000::/23 prefix and registered it in the "IANA IPv6 Special-Purpose Address Registry" [RFC6890] 💖.

    +----------------------+-------------------------------------------+
    | Attribute            | Value                                     |
    +----------------------+-------------------------------------------+
    | Address Block        | 2001:1::2/128                             |
    | Name                 | Traversal Using Relays around NAT Anycast |
    | RFC                  | RFC 8155                                  |
    | Allocation Date      | 2017-02                                   |
    | Termination Date     | N/A                                       |
    | Source               | True                                      |
    | Destination          | True                                      |
    | Forwardable          | True                                      |
    | Global               | True                                      |
    | Reserved-by-Protocol | False                                     |
    +----------------------+-------------------------------------------+

9. Security Considerations 🔐💀

okay bestie, this is the serious part 😭 Use of Session Traversal Utilities for NAT (STUN) [RFC5389] authentication is OPTIONAL for TURN servers provided by the local network or by the access network 🫶. A network-provided TURN server MAY be configured to accept Allocation requests without STUN authentication, and a TURN client MAY be configured to accept Allocation success responses without STUN authentication from a network-provided TURN server.

Making STUN authentication optional is a downgrade of a MUST level requirement defined in [RFC5766] 🙈. The downgrade lets TURN servers from the local or access network accept Allocation requests from new and/or guest users who don't necessarily have long term credentials for STUN authentication. The whole vibe is to give TURN services to everyone on the local or access network 🌈. However, this opens up a TURN server to a whole bunch of attacks described in Section 17 of [RFC5766] 😬. A TURN server in these cases must be configured to only process STUN requests from the trusted local network or from subscribers of the access network. Operational measures must be taken to protect the TURN server, and some of them include, but are not limited to, access control by means of access lists, firewalls, subscriber quota limits, ingress filtering, etc. 🧱

A TURN client without the STUN long-term credential mechanism [RFC5389] or the STUN Extension for Third-Party Authorization [RFC7635] MUST use (D)TLS 🔒, unless it trusts the network infrastructure to defend against the attacks discussed in [RFC5766]. It is RECOMMENDED that the TURN client use one of the following techniques with (D)TLS to validate the TURN server:

  • For certificate-based authentication, a pre-populated trust anchor store [RFC6024] lets a TURN client do path validation for the server certificate it gets during the (D)TLS handshake. If the client used a domain name to discover the TURN server, that domain name also gives a way to validate the TURN server. The client MUST use the rules and guidelines given in Section 6 of [RFC6125] to validate the TURN server identity 🪪.
  • Certification authorities that issue TURN server certificates SHOULD support the CN-ID, DNS-ID, SRV-ID, and URI-ID identifier types. TURN service providers SHOULD prefer DNS-ID, SRV-ID, and URI-ID over CN-ID identifier types in certificate requests (as described in Section 2.3 from [RFC6125]), and the wildcard character * SHOULD NOT be included in the presented identifier 🍓.
  • For TURN servers that don't have a certificate trust chain (e.g., because they are on a home network or a corporate network), a configured list of TURN servers can contain the Subject Public Key Info (SPKI) fingerprint of the TURN servers. The public key is used for the same reasons HTTP pinning [RFC7469] uses the public key 🔑.
  • Raw public key-based authentication, as defined in [RFC7250], could also be used to authenticate a TURN server ✨.

An auto-discovered TURN server is only considered as trusted as the path between the client and the TURN server 👀. To safely use auto-discovered TURN servers for sessions with 'strict privacy' requirements, the user needs to be able to define privacy criteria (e.g., a trusted list of servers, networks, or domains) that are considered acceptable for that traffic 💜. Any discovered TURN server outside those criteria is considered untrusted, and therefore MUST NOT be used for privacy-sensitive communication 🚫.

In some auto-discovery scenarios, it might not be possible for the TURN client to use (D)TLS authentication to validate the TURN server. However, falling back to clear text in those cases could leave the TURN client open to on-path injection of spoofed TURN messages 😭. A TURN client could fall back to encryption-only (D)TLS when (D)TLS authentication is not available, but MUST NOT fall back without explicit administrator choice. Another reason to fall back to encryption-only is privacy, which is analogous to SMTP opportunistic encryption [RFC7435], where you don't require privacy but you want it when it's possible 🦋.

So that the TURN client can fall back to (D)TLS as described above, a TURN server that doesn't require either STUN long-term authentication [RFC5389] or the STUN Extension for Third Party Authorization [RFC7635] MUST support (D)TLS. If the network infrastructure is capable of defending against the attacks discussed in [RFC5766], then the TURN server MAY allow fallback to clear text 🧚.

A TURN client could fall back to clear text if it doesn't support unauthenticated (D)TLS, but MUST NOT fall back without explicit administrator choice. Fallback to clear text is NOT RECOMMENDED, because it makes the client more susceptible to man-in-the-middle attacks and on-path packet injection 🚨.

9.1. Service Resolution

The primary attack against the methods described in this document is one that would lead to impersonation of a TURN server 👑. An attacker could try to compromise the S-NAPTR resolution. Security considerations described in [RFC5928] apply here as well.

Beyond the considerations related to S-NAPTR, it's important to recognize that the output is entirely dependent on its input 🧠. An attacker who can control the domain name can also control the final result. Because more than one method can be used to determine the domain name, a host implementation needs to consider attacks against each of the methods that are used.

If DHCP is used, the integrity of DHCP options is limited by the security of the channel they're provided over 🛡️. Physical security and separating DHCP messages from other packets are common methods that can reduce the possibility of attack within an access network. Alternatively, DHCP authentication [RFC3188] can provide a degree of protection against modification. When using DHCP discovery, clients are encouraged to use unicast DHCP INFORM queries instead of broadcast queries, which are more easily spoofed in insecure networks 📡.

9.2. DNS Service Discovery

DNS-SD is just a specification for how to name and use records in the existing DNS system, so it has no specific additional security requirements beyond the ones that already apply to DNS queries and DNS updates 🤓. For DNS queries, DNS Security Extensions (DNSSEC) [RFC4033] should be used where the authenticity of information is important. For DNS updates, secure updates [RFC2136] [RFC3007] should generally be used to control which clients have permission to update DNS records.

For mDNS, on top of everything described above, a principal security threat is one inherent to IP multicast routing and to any application that runs on it 😱. A rogue system can advertise that it is a TURN server. Discovering such a rogue system as a TURN server is not, in itself, a security threat, as long as there is a means for the TURN client to authenticate and authorize the discovered TURN servers 🫠.

9.3. Anycast

In a network without any TURN server that is aware of the TURN anycast address, outgoing TURN requests could leak out onto the external Internet, possibly revealing information 👀.

Using an IANA-assigned well-known TURN anycast address lets border gateways block such outgoing packets 🚧. In the default-free zone, routers should be configured to drop such packets. That configuration can happen naturally through BGP messages advertising that no route exists to said address.

Sensitive clients that don't want to leak information about their presence can set an IP TTL on their TURN requests that limits how far they can travel into the public Internet 🫥.

10. References 📚

10.1. Normative References

okay so these are the docs this spec has to lean on, no cap. if you skip any of them, the whole thing stops making sense 💅

10.2. Informative References

these ones are the extra reading 🦋 not strictly required, but SO worth a peek if you want the full picture ✨

Acknowledgements

big thank-yous 🫶 to Simon Perrault, Paul Kyzivat, Troy Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba, Karl Stahl, Brian Weis, Ralph Dromes, Ben Campbell, Suresh Krishnan, and Brandon Williams for reviewing this and leaving such valuable comments 💜 Also a special shout-out to Adam Roach 👑 for his super detailed review and for suggesting DNS Service Discovery as an extra discovery mechanism ✨

Authors' Addresses

the people who wrote it, with the contact details exactly as they appear in the document 🎀

Prashanth Patil
Cisco Systems, Inc.

Email: praspati@cisco.com


Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka  560103
India

Email: tireddy@cisco.com


Dan Wing
United States America

Email: dwing-ietf@fuggles.com
📦 where this page comes from