1.3 Overview

The Traversal Using Relay NAT (TURN) protocol, as described in [IETFDRAFT-TURN-08], enables a TURN client located on a private network behind one or more network address translation (NAT) to allocate a transport address from a TURN server that is sitting on the Internet. This allocated transport address can be used for receiving data from a peer. The peer itself could be on a private network behind a NAT or it could have a public address.

A typical deployment, supported by the TURN protocol and this extension, where a protocol client is behind a NAT and is communicating with a peer on the Internet, is shown in the following figure.

Figure 1: A TURN client communicating with a public peer

When a protocol client needs a public address to send data to or receive data from a peer, it sends an Allocate request message to the TURN server. This request is authenticated by the TURN server through a digest challenge mechanism. Once the TURN server has authenticated the Allocate request, it returns an allocated address to the protocol client in an Allocate response message.

At this point the allocated address has been reserved by the protocol client. It cannot be used to receive data from a peer until the protocol client attempts to send data to the peer by encapsulating the data in a Send request message. The Send request message serves two functions:

• The TURN server relays the data contained in the message to the peer identified by the Destination attribute.

• Permissions are set on the allocated address in a way that data arriving on the allocated address from the peer is relayed to the protocol client in a Data Indication message.

If the protocol client needs to communicate with more than one peer, it can send an additional Send request message to each peer.

Once the permissions have been set for a peer, any data received on the allocated address from that peer is relayed back to the protocol client encapsulated in a Data Indication message. This message includes the Remote Address attribute that identifies the peer that originated the data.

If the protocol client decides to communicate with a preferred peer, it can send a Set Active Destination request message to the TURN server. The TURN server acknowledges the protocol client's request by responding with a Set Active Destination response message. This allows the protocol client and TURN server to stop using Send request and Data Indication messages to encapsulate data flowing end-to-end for this peer, thus making the data communication channel more efficient. The results are that all data that the TURN server receives from the protocol client that is not a TURN control message is relayed directly to the active peer. All data that the TURN server receives on the allocated address from the active peer is relayed directly to the protocol client. If the TURN server receives data from a peer other than the active peer but for which it has permissions, as set by the protocol client through an earlier Send request message, the TURN server relays the data encapsulating it in a Data Indication message.

The basic flow of TURN messages between a protocol client and a TURN server is shown in the following figure.

Figure 2: Basic flow of TURN messages

This protocol specifies proprietary extensions to the TURN protocol. These extensions include:

Authentication: This protocol does not use the Shared Secret request and Shared Secret response messages, as described in [IETFDRAFT-TURN-08] section 7.1, for authentication of the protocol client. Instead, this protocol uses long-term credentials and has extended the Allocate request and Allocate error response message processing, as described in [IETFDRAFT-TURN-08] section 7.2, to incorporate a digest challenge mechanism. This is specified in section 3.1.12. This extension is from the TURN draft version described in [TURN-05].

TCP Framing Header: A header has been added to this protocol for stream-based transports, so that TURN control messages are uniquely identifiable from end-to-end data. This is specified in section 2.1.4. This extension is from the TURN draft version described in [TURN-01].

Pseudo-TLS Session Establishment: This protocol includes a pseudo Transport Layer Security (TLS) Client Hello and Server Hello message exchange at the beginning of a Transmission Control Protocol (TCP) session to allow session establishment over TCP port 443, where a proxy or firewall might inspect the initial traffic for TLS packets. This is specified in section 2.1.1.

Client Versioning: An attribute has been added to this protocol to request messages to allow a protocol client to identify the protocol version it is using. This is specified in section 2.2.2.17.

Request Message Sequencing: An attribute that contains a sequence number has been added to the request messages in this protocol. This attribute helps prevent replay attacks and is specified in section 2.2.2.21.

No Support for Send Response or Send Error Response Messages: Support has been dropped for any response to the Send request message, as described in [IETFDRAFT-TURN-08] section 7.3, to streamline the Send request phase of a TURN session. This extension is from the TURN draft version described in [TURN-01].

XOR Mapped Address: This protocol uses the XOR-MAPPED-ADDRESS attribute from [IETFDRAFT-STUN-02] section 10.2.12 to inform the protocol client of the protocol client's reflexive transport address. This keeps intrusive NATs from rewriting the binary encoded IP address and port. This is specified in section 2.2.2.16.

Alternate Server Attribute: This protocol extends the use of the Alternate Server attribute and includes it in the Allocate error response message, error response code of 401 Unauthorized, to convey the IP address of the TURN server to the protocol client. In some deployments, for example, a pool of TURN servers behind a load balancer that presents a virtual IP address, the protocol client needs to know the direct address of the TURN server with which it established a TURN session. This is specified in section 2.2.2.7.

Service Quality: An attribute has been added to this protocol to convey information about the data stream that the protocol client is intending to transfer over an allocated port.  This is specified in section 2.2.2.22.

Request a specific IP Address Family: This protocol provides support for the Requested Address Family attribute from [RFC6156] section 4.1.1.  This attribute is used in an Allocate request message to identify the IP address family to be allocated by the TURN server.  This is specified in section 2.2.2.15.

Request both an IPv4 and IPv6 allocated addresses:  This protocol provides support for allocating both IPv4 and IPv6 addresses from a TURN server configured to use both IPv4 and IPv6 networks.

HMAC SHA-256 support: This protocol provides support for using HMAC SHA-256 with the Message Integrity attribute specified in section 2.2.2.3. The use of HMAC SHA-256 provides enhanced security for TURN messages.