Traversal Using Relays around NAT (TURN) Server Auto Discovery
updates
- rfc-5766 — Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
Extracted elements (30)
The anycast server always redirects clients to a unicast address rather than serving requests directly because two packets sent to an anycast address may reach two different anycast servers, which would break TURN's stateful allocation model. The client must also ensure the initial request fits in a single packet.
Three discovery mechanisms are defined rather than one to maximize discovery opportunity: S-NAPTR covers managed enterprise/ISP networks, DNS-SD/mDNS covers local network advertisement, and anycast requires no pre-configuration whatsoever—only the two endpoints that use TURN need to be deployed.
RFC 8155 updates RFC 5766 by relaxing the MUST requirement for mutual STUN authentication: network-provided TURN servers MAY accept Allocation requests without STUN authentication, and TURN clients MAY accept success responses without STUN authentication from network-provided servers.
A TURN anycast server that passes checks 1–7 of RFC 5766 Section 6.2 MUST respond with a 300 (Try Alternate) error redirecting the client to the server's unicast address in the ALTERNATE-SERVER attribute.
A TURN client lacking STUN long-term credentials (RFC 5389) or Third-Party Authorization (RFC 7635) MUST use (D)TLS unless it trusts the network infrastructure to defend against attacks described in RFC 5766.
A TURN client MUST NOT fall back to encryption-only (D)TLS (when full authentication is unavailable) or to clear text without an explicit administrator choice.
A TURN server that does not require STUN long-term authentication or Third-Party Authorization MUST support (D)TLS, and MAY allow fallback to clear text only if the network infrastructure can defend against RFC 5766 attacks.
For best results, a TURN client SHOULD implement all three discovery mechanisms (Service Resolution, DNS-SD, and Anycast) described in the document.
For IPv4, the TURN discovery procedure MUST request the access network domain name option (OPTION_V4_ACCESS_DOMAIN) in a DHCP Parameter Request List option as described in RFC 5986/RFC 2131.
For IPv6, the TURN discovery procedure MUST request the access network domain name option (OPTION_V6_ACCESS_DOMAIN) in an Options Request Option (ORO) within a DHCPv6 Information-request message.
If a client wishes to communicate via a specific interface and address family, it SHOULD query TURN servers discovered for that specific interface and address family. Discovery must be performed per combination of interface and address family on multi-homed hosts.
The DNS-SD service instance name's <Service> portion for TURN MUST be '_turn._udp', '_turn._tcp', '_turns._udp', or '_turns._tcp' as introduced in RFC 5766.
WebRTC endpoints SHOULD treat any TURN server discovered through the mechanisms in this specification as an enterprise/gateway or access network server in accordance with the Recursively Encapsulated TURN (RETURN) framework.
When using certificate-based (D)TLS to validate a TURN server, a client MUST apply the rules and guidelines in RFC 6125 Section 6, using the domain name that was used for discovery as the validation identifier.
Sensitive clients that do not wish to reveal their presence can set an IP TTL on TURN anycast requests that limits how far they can propagate into the public Internet, reducing the risk of information leakage.
A TURN client can discover TURN servers via mDNS by multicasting PTR queries to '_turn._udp.local.', '_turn._tcp.local', '_turns._udp.local.', or '_turns._tcp.local'. TURN servers may also send gratuitous mDNS answers on startup, wake, or network change.
Domain names can also be derived from the TURN client's own identity (e.g., SIP URI 'sip:alice@example.com', bare JID, or email address) by extracting the domain portion. This supplements DHCP-based domain name retrieval.
For anycast discovery, a TURN client sends an Allocation request to the assigned TURN anycast address. The anycast TURN server MUST respond with a 300 (Try Alternate) error containing the TURN unicast address in the ALTERNATE-SERVER attribute; the client then uses that unicast address for all subsequent communication.
If a client's IP address changes (e.g., due to host mobility), the TURN discovery procedure must be re-run. New requests should use newly discovered TURN servers; however, if a previously learned TURN server is still accessible, RFC 8016 mobility procedures may be used for ongoing streams.
Once a domain name is retrieved, S-NAPTR resolution per RFC 5928 is performed using the 'RELAY' application service tag to locate the authoritative TURN server. If no TURN-specific S-NAPTR records exist, discovery fails for that domain.
RFC 8155 defines three TURN server auto-discovery mechanisms: (1) Service Resolution via S-NAPTR DNS lookups using the host's DNS domain, (2) DNS Service Discovery (DNS-SD/mDNS), and (3) Anycast using an IANA-assigned anycast address. Clients may use any or all mechanisms in any order.
RFC 8155 assigns IPv4 anycast address 192.0.0.10/32 ('Traversal Using Relays around NAT Anycast') in the IANA IPv4 Special-Purpose Address Registry (RFC 6890). The address is globally routable, forwardable, and has no termination date.
RFC 8155 assigns IPv6 anycast address 2001:1::2/128 ('Traversal Using Relays around NAT Anycast') in the IANA IPv6 Special-Purpose Address Registry (RFC 6890). The address is globally routable, forwardable, and has no termination date.
An auto-discovered TURN server is considered only as trusted as the path between client and server. For sessions with strict privacy requirements, clients must define acceptable trust criteria (trusted servers, networks, or domains); any TURN server outside those criteria MUST NOT be used for privacy-sensitive communication.
Fallback to clear text is NOT RECOMMENDED because it exposes the TURN client to man-in-the-middle attacks and on-path packet injection. A client may fall back only with explicit administrator choice.
For DNS-SD, DNSSEC should be used where information authenticity matters, and secure DNS updates (RFC 2136/RFC 3007) should be used to control which clients may update DNS records. For mDNS, a rogue system can advertise itself as a TURN server; authentication and authorization of discovered servers are required to mitigate this threat.
In networks without a TURN anycast-aware server, outgoing TURN requests sent to the anycast address could leak onto the public Internet, potentially revealing client presence. Border gateways SHOULD block such packets; sensitive clients can set a low IP TTL to limit how far requests travel.
Making STUN authentication optional is a downgrade from RFC 5766 to allow network-provided TURN servers to accept guest/new users. As a consequence, operational protections such as access control lists, firewalls, subscriber quotas, and ingress filtering MUST be applied to protect the TURN server.
The primary attack against Service Resolution is impersonation of a TURN server through compromise of S-NAPTR resolution or control of the input domain name. Attackers who control the domain name can control the discovered TURN server; every method used to determine the domain name introduces its own attack surface.
When DHCP is used for domain name discovery, clients are encouraged to use unicast DHCP INFORM queries instead of broadcast queries to reduce spoofing risk. DHCP authentication (RFC 3188) can provide additional protection against modification.