Mobility with Traversal Using Relays around NAT (TURN)
Extracted elements (25)
Mobility is achieved entirely by the client and TURN server; the remote peer does not need to support mobility or be aware of address changes. This design hides the IP address change from upper-layer protocols and peer endpoints, avoiding the costly ICE re-negotiation required under the existing TURN specification.
The mobility ticket is opaque to the client and its internal structure is not subject to interoperability requirements — implementations may diverge from the Appendix A example. This design allows the TURN server to store arbitrary system-internal state (encrypted and integrity-protected) without constraining the server implementation.
The old 5-tuple is retained after a successful mobility Refresh (rather than immediately deleted) to support both Break-Before-Make and Make-Before-Break handover scenarios and to handle potential loss of the Refresh response — the client can continue sending data on the old path until the new path is confirmed.
The TURN server supporting mobility MUST assume that the path MTU is unknown and size the ticket accordingly per STUN UDP fragmentation guidance (RFC 5389 Section 7.1). This is because a roaming client may move between networks with different MTUs and between address families (e.g., IPv6 to IPv4).
If the server does not understand the MOBILITY-TICKET attribute (per RFC 5389 comprehension-optional rules), it ignores the attribute and processes the Allocate request normally without providing a ticket, allowing backward compatibility with non-mobility-aware TURN servers.
When (D)TLS is used as the STUN transport and the client's IP address changes, the client uses TLS Session Resumption without Server-Side State (RFC 5077) to resume secure communication with the TURN server from the new IP address, allowing the mobility mechanism to work seamlessly with (D)TLS.
A client MUST NOT include a MOBILITY-TICKET attribute in a Refresh request if its IP address and source port have not changed, as the server will reject such a request and the client would need to retransmit without the attribute.
A server MUST retain the old MOBILITY-TICKET for at least 30 seconds after issuing a new one, so it can recognize retransmissions of the Refresh request from the client using the old ticket.
After a successful mobility Refresh, the TURN server MUST continue receiving and processing data on the old 5-tuple and MUST continue transmitting data on the old 5-tuple until it receives a Send Indication, ChannelData message on the new 5-tuple, or a message closing the old connection.
After receiving a 405 (Mobility Forbidden) response to an Allocate request containing MOBILITY-TICKET, the client SHOULD NOT retry sending an Allocate request containing MOBILITY-TICKET to that server until it believes the problem has been fixed.
If (D)TLS is not used or the (D)TLS handshake fails, and authentication also fails, the TURN client and server MUST fail and not proceed with TURN mobility.
If MOBILITY-TICKET is included in an Allocate request with a non-zero length, the server MUST generate a 400 (Bad Request) error response, as a non-zero length is only valid in Refresh requests.
If the MOBILITY-TICKET presented in a Refresh request is invalid (fails decryption or integrity check), the server MUST reject the request with a 400 (Bad Request) error.
It is RECOMMENDED that the client avoid transmitting a Send indication or ChannelData message until it has received an acknowledgement for the Refresh request containing MOBILITY-TICKET, since the server MAY discard or queue such messages before the Refresh succeeds.
The new MOBILITY-TICKET sent in a Refresh success response MUST be different from the old ticket. The old ticket may only be used for retransmission purposes.
The TURN server MUST always ensure the mobility ticket is authenticated and encrypted using strong cryptographic algorithms, and the ticket MUST be constructed to have strong entropy so nothing can be gleaned by examining it alone.
When a server receives a Refresh request with MOBILITY-TICKET and the decrypted ticket's 5-tuple does not identify an existing allocation, the server MUST reject the request with a 437 (Allocation Mismatch) error.
When validating a Refresh with MOBILITY-TICKET, if the source IP address and port differ from the stored 5-tuple, the server performs MESSAGE-INTEGRITY validation; if it fails, the server MUST reject with a 441 (Wrong Credentials) error.
A new STUN error response code 405 (Mobility Forbidden) is defined. It is returned when a mobility request (MOBILITY-TICKET in Allocate or Refresh) is valid but cannot be performed due to administrative or similar restrictions on the server.
The MOBILITY-TICKET is a new STUN attribute used to retain a TURN allocation across client IP address changes. Its value is encrypted, of variable length, and opaque to the client. It is carried in Allocate requests (length=0 to request a ticket), Allocate success responses (server-issued ticket), and Refresh requests/responses (ticket presentation and renewal).
IANA has added MOBILITY-TICKET (value 0x8030, in the comprehension-optional range) to the 'STUN Attributes' registry, and has added error code 405 'Mobility Forbidden' to the 'STUN Error Codes' registry.
An attacker monitoring traffic between the TURN client and server can impersonate the client and refresh the allocation using an intercepted ticket with the attacker's IP address. To prevent this, TURN client and server MUST use STUN long-term credential mechanism, STUN Third-Party Authorization (RFC 7635), or a (D)TLS connection.
The ticket used for mobility MUST be authenticated and encrypted with strong cryptographic algorithms and MUST have strong entropy. This prevents modification or eavesdropping by an attacker and ensures that allocation ownership cannot be determined from the ticket contents alone.
On receiving a valid mobility Refresh, the server transitions the allocation's active 5-tuple from old to new: it adds the new client IP/port to state while retaining the old 5-tuple; upon receiving a Send Indication or ChannelData on the new 5-tuple (or a connection-close signal on the old), the server discards the old 5-tuple and old ticket, fully completing the transition.
The example ticket structure (Appendix A) consists of: key_name (16 octets), iv (16 octets), encrypted_state (variable, up to 2^16-1 octets), and mac (16 octets). Encryption uses AES_128_CBC; integrity uses HMAC-SHA-256-128 over key_name, IV, and encrypted_state length and contents.