Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
obsoleted by
- rfc-8656 — Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
updated by
Extracted elements (31)
Channels were introduced to reduce the 36-byte overhead of Send/Data indications, which can substantially increase bandwidth for applications such as VoIP. The ChannelData message uses only a 4-byte header, trading flexibility for efficiency on high-volume real-time media paths.
The permission system was designed to mimic the address-restricted filtering of RFC 4787-compliant NATs, easing enterprise concerns that TURN could bypass firewall policy. Permissions expire after 5 minutes to match typical NAT UDP binding lifetimes.
TLS-over-TCP is supported (but not required) because it provides server authentication and control-message confidentiality that STUN's digest mechanism does not. It is optional because TLS overhead causes application data to be doubly encrypted when the peer connection is also secured.
TURN is designed to run as an unprivileged user-space application to simplify deployment and enable embedding in peer-to-peer applications. The trade-off is that Diffserv, TTL, and ECN fields may not be preserved and ICMP messages are not relayed.
This version of TURN only supports UDP between the server and peers and only supports IPv4. Extensions for TCP relay (TURN-TCP) and IPv6/IPv4-IPv6 relaying (TURN-IPv6) are planned in separate specifications.
A TURN server MUST support UDP transport between the client and the server and SHOULD support TCP and TLS-over-TCP transport. This specification only supports UDP between the server and peers.
All requests after the initial Allocate MUST use the same username as that used to create the allocation. If the 5-tuple identifies an existing allocation but the username differs, the request MUST be rejected with a 441 (Wrong Credentials) error.
Both the relayed transport address and the 5-tuple MUST be unique across all allocations so that either can independently identify the allocation.
For all TURN messages except an Allocate request, if the 5-tuple does not identify an existing allocation, the message MUST be rejected with a 437 (Allocation Mismatch) error if it is a request, or silently ignored if it is an indication or ChannelData message.
If an Allocate success response is received, the client MUST check that the mapped address and relayed transport address are in an address family it understands. If not, it MUST delete the allocation and MUST NOT attempt to create another allocation on that server until the mismatch is resolved.
It is RECOMMENDED that the server impose limits on both the number of allocations active at one time per username and on bandwidth usage, rejecting excess allocations with a 486 (Allocation Quota Reached) error.
The client MUST include a REQUESTED-TRANSPORT attribute in every Allocate request specifying the transport protocol between server and peers. In this specification the value MUST be UDP (protocol number 17).
The Permission Lifetime MUST be 300 seconds (5 minutes). A permission is reset to this value when installed or refreshed; the server silently discards UDP datagrams from peers without a matching IP-address permission.
The server SHOULD generate a fresh random nonce for each new allocation attempt and SHOULD expire the nonce at least once every hour during the lifetime of the allocation, following the randomness recommendations in RFC 4086.
The server SHOULD only allocate relayed transport address ports from the range 49152–65535 (Dynamic/Private Port range) and SHOULD NOT allocate ports in the range 0–1023 (Well-Known Port range).
TURN servers and clients MUST implement the STUN long-term credential mechanism. The server MUST demand that all requests be authenticated using this mechanism, or an equally strong or stronger mechanism for client authentication.
A channel binds a 16-bit channel number (valid range 0x4000–0x7FFF) to a specific peer transport address, allowing the client and server to exchange data using the compact 4-byte ChannelData format instead of full STUN indications. Channel bindings expire after 10 minutes.
A permission consists of a peer IP address (not port) and a time-to-expiry. When a UDP datagram arrives at the relayed transport address, the server compares the source IP address against the permission list; if no match is found the datagram is silently discarded.
An allocation is the central data structure on the TURN server. It contains: a relayed transport address, a 5-tuple (client IP/port, server IP/port, transport protocol), authentication information, a time-to-expiry timer (default 600 seconds), a list of permissions, and a list of channel-to-peer bindings.
Nine new STUN attributes are registered: CHANNEL-NUMBER (0x000C), LIFETIME (0x000D), XOR-PEER-ADDRESS (0x0012), DATA (0x0013), XOR-RELAYED-ADDRESS (0x0016), EVEN-PORT (0x0018), REQUESTED-TRANSPORT (0x0019), DONT-FRAGMENT (0x001A), and RESERVATION-TOKEN (0x0022).
Six new STUN error codes are registered: 403 (Forbidden), 437 (Allocation Mismatch), 441 (Wrong Credentials), 442 (Unsupported Transport Protocol), 486 (Allocation Quota Reached), and 508 (Insufficient Capacity).
Six new STUN methods are registered: Allocate (0x003), Refresh (0x004), Send (0x006), Data (0x007), CreatePermission (0x008), and ChannelBind (0x009).
A TURN loop attack is possible if a client installs a permission and binds a channel using the server's own relayed transport address, causing the server to forward traffic to itself in a loop. Servers SHOULD check for and reject such configurations.
An authenticated client can use a TURN server to anonymously relay malicious traffic. The permission/channel system and authentication requirements provide partial mitigation, but operators should consider blacklisting known-bad IP address ranges from receiving relayed traffic.
Because Send indications cannot be authenticated (STUN's long-term credential mechanism does not cover indications), an attacker can inject bogus Send indications to cause the server to relay traffic to a peer. The permission system partially mitigates this: a permission must be installed before the server relays data.
Without TLS, a passive attacker can eavesdrop TURN control messages and relayed application data. TLS-over-TCP provides confidentiality and server authentication not offered by STUN's digest mechanism alone.
CHANNEL-NUMBER attribute (type 0x000C): 16-bit unsigned channel number followed by 16 bits of RFFU, totaling 4 bytes. Valid channel numbers are 0x4000–0x7FFF.
LIFETIME attribute (type 0x000D): 32-bit unsigned integer representing the number of seconds remaining until the allocation or reservation expires.
REQUESTED-TRANSPORT attribute (type 0x0019): 8-bit IANA protocol number (17 for UDP) followed by 24 bits of RFFU (reserved for future use), for a total of 32 bits.
RESERVATION-TOKEN attribute (type 0x0022): 64-bit opaque token identifying a port reserved by a prior Allocate request with EVEN-PORT R=1, to be consumed in a subsequent Allocate request.
The ChannelData message does not use the STUN header. Its format is: 16-bit channel number, 16-bit data length (in bytes), followed by the data payload. This 4-byte header replaces the 36-byte overhead of Send/Data indications.