Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5766

Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)

Pages: 67
Obsoleted by:  8656
Updated by:  81558553
Part 4 of 4 – Pages 48 to 67
First   Prev   None

Top   ToC   RFC5766 - Page 48   prevText

16. Detailed Example

This section gives an example of the use of TURN, showing in detail the contents of the messages exchanged. The example uses the network diagram shown in the Overview (Figure 1).
Top   ToC   RFC5766 - Page 49
   For each message, the attributes included in the message and their
   values are shown.  For convenience, values are shown in a human-
   readable format rather than showing the actual octets; for example,
   "XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED-
   ADDRESS attribute is included with an address of 192.0.2.15 and a
   port of 9000, here the address and port are shown before the xor-ing
   is done.  For attributes with string-like values (e.g.,
   SOFTWARE="Example client, version 1.03" and
   NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"), the value of the attribute
   is shown in quotes for readability, but these quotes do not appear in
   the actual value.

  TURN                                 TURN           Peer          Peer
  client                               server          A             B
    |                                    |             |             |
    |--- Allocate request -------------->|             |             |
    |    Transaction-Id=0xA56250D3F17ABE679422DE85     |             |
    |    SOFTWARE="Example client, version 1.03"       |             |
    |    LIFETIME=3600 (1 hour)          |             |             |
    |    REQUESTED-TRANSPORT=17 (UDP)    |             |             |
    |    DONT-FRAGMENT                   |             |             |
    |                                    |             |             |
    |<-- Allocate error response --------|             |             |
    |    Transaction-Id=0xA56250D3F17ABE679422DE85     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    ERROR-CODE=401 (Unauthorized)   |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"      |             |
    |                                    |             |             |
    |--- Allocate request -------------->|             |             |
    |    Transaction-Id=0xC271E932AD7446A32C234492     |             |
    |    SOFTWARE="Example client 1.03"  |             |             |
    |    LIFETIME=3600 (1 hour)          |             |             |
    |    REQUESTED-TRANSPORT=17 (UDP)    |             |             |
    |    DONT-FRAGMENT                   |             |             |
    |    USERNAME="George"               |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"      |             |
    |    MESSAGE-INTEGRITY=...           |             |             |
    |                                    |             |             |
    |<-- Allocate success response ------|             |             |
    |    Transaction-Id=0xC271E932AD7446A32C234492     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    LIFETIME=1200 (20 minutes)      |             |             |
    |    XOR-RELAYED-ADDRESS=192.0.2.15:50000          |             |
    |    XOR-MAPPED-ADDRESS=192.0.2.1:7000             |             |
    |    MESSAGE-INTEGRITY=...           |             |             |
Top   ToC   RFC5766 - Page 50
   The client begins by selecting a host transport address to use for
   the TURN session; in this example, the client has selected 10.1.1.2:
   49721 as shown in Figure 1.  The client then sends an Allocate
   request to the server at the server transport address.  The client
   randomly selects a 96-bit transaction id of
   0xA56250D3F17ABE679422DE85 for this transaction; this is encoded in
   the transaction id field in the fixed header.  The client includes a
   SOFTWARE attribute that gives information about the client's
   software; here the value is "Example client, version 1.03" to
   indicate that this is version 1.03 of something called the Example
   client.  The client includes the LIFETIME attribute because it wishes
   the allocation to have a longer lifetime than the default of 10
   minutes; the value of this attribute is 3600 seconds, which
   corresponds to 1 hour.  The client must always include a REQUESTED-
   TRANSPORT attribute in an Allocate request and the only value allowed
   by this specification is 17, which indicates UDP transport between
   the server and the peers.  The client also includes the DONT-FRAGMENT
   attribute because it wishes to use the DONT-FRAGMENT attribute later
   in Send indications; this attribute consists of only an attribute
   header, there is no value part.  We assume the client has not
   recently interacted with the server, thus the client does not include
   USERNAME, REALM, NONCE, or MESSAGE-INTEGRITY attribute.  Finally,
   note that the order of attributes in a message is arbitrary (except
   for the MESSAGE-INTEGRITY and FINGERPRINT attributes) and the client
   could have used a different order.

   Servers require any request to be authenticated.  Thus, when the
   server receives the initial Allocate request, it rejects the request
   because the request does not contain the authentication attributes.
   Following the procedures of the long-term credential mechanism of
   STUN [RFC5389], the server includes an ERROR-CODE attribute with a
   value of 401 (Unauthorized), a REALM attribute that specifies the
   authentication realm used by the server (in this case, the server's
   domain "example.com"), and a nonce value in a NONCE attribute.  The
   server also includes a SOFTWARE attribute that gives information
   about the server's software.

   The client, upon receipt of the 401 error, re-attempts the Allocate
   request, this time including the authentication attributes.  The
   client selects a new transaction id, and then populates the new
   Allocate request with the same attributes as before.  The client
   includes a USERNAME attribute and uses the realm value received from
   the server to help it determine which value to use; here the client
   is configured to use the username "George" for the realm
   "example.com".  The client also includes the REALM and NONCE
   attributes, which are just copied from the 401 error response.
   Finally, the client includes a MESSAGE-INTEGRITY attribute as the
   last attribute in the message, whose value is a Hashed Message
Top   ToC   RFC5766 - Page 51
   Authentication Code - Secure Hash Algorithm 1 (HMAC-SHA1) hash over
   the contents of the message (shown as just "..." above); this HMAC-
   SHA1 computation includes a password value.  Thus, an attacker cannot
   compute the message integrity value without somehow knowing the
   secret password.

   The server, upon receipt of the authenticated Allocate request,
   checks that everything is OK, then creates an allocation.  The server
   replies with an Allocate success response.  The server includes a
   LIFETIME attribute giving the lifetime of the allocation; here, the
   server has reduced the client's requested 1-hour lifetime to just 20
   minutes, because this particular server doesn't allow lifetimes
   longer than 20 minutes.  The server includes an XOR-RELAYED-ADDRESS
   attribute whose value is the relayed transport address of the
   allocation.  The server includes an XOR-MAPPED-ADDRESS attribute
   whose value is the server-reflexive address of the client; this value
   is not used otherwise in TURN but is returned as a convenience to the
   client.  The server includes a MESSAGE-INTEGRITY attribute to
   authenticate the response and to ensure its integrity; note that the
   response does not contain the USERNAME, REALM, and NONCE attributes.
   The server also includes a SOFTWARE attribute.

  TURN                                 TURN           Peer          Peer
  client                               server          A             B
    |--- CreatePermission request ------>|             |             |
    |    Transaction-Id=0xE5913A8F460956CA277D3319     |             |
    |    XOR-PEER-ADDRESS=192.0.2.150:0  |             |             |
    |    USERNAME="George"               |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"      |             |
    |    MESSAGE-INTEGRITY=...           |             |             |
    |                                    |             |             |
    |<-- CreatePermission success resp.--|             |             |
    |    Transaction-Id=0xE5913A8F460956CA277D3319     |             |
    |    MESSAGE-INTEGRITY=...           |             |             |

   The client then creates a permission towards Peer A in preparation
   for sending it some application data.  This is done through a
   CreatePermission request.  The XOR-PEER-ADDRESS attribute contains
   the IP address for which a permission is established (the IP address
   of peer A); note that the port number in the attribute is ignored
   when used in a CreatePermission request, and here it has been set to
   0; also, note how the client uses Peer A's server-reflexive IP
   address and not its (private) host address.  The client uses the same
   username, realm, and nonce values as in the previous request on the
   allocation.  Though it is allowed to do so, the client has chosen not
   to include a SOFTWARE attribute in this request.
Top   ToC   RFC5766 - Page 52
   The server receives the CreatePermission request, creates the
   corresponding permission, and then replies with a CreatePermission
   success response.  Like the client, the server chooses not to include
   the SOFTWARE attribute in its reply.  Again, note how success
   responses contain a MESSAGE-INTEGRITY attribute (assuming the server
   uses the long-term credential mechanism), but no USERNAME, REALM, and
   NONCE attributes.

  TURN                                 TURN           Peer          Peer
  client                               server          A             B
    |--- Send indication --------------->|             |             |
    |    Transaction-Id=0x1278E9ACA2711637EF7D3328     |             |
    |    XOR-PEER-ADDRESS=192.0.2.150:32102            |             |
    |    DONT-FRAGMENT                   |             |             |
    |    DATA=...                        |             |             |
    |                                    |-- UDP dgm ->|             |
    |                                    |  data=...   |             |
    |                                    |             |             |
    |                                    |<- UDP dgm --|             |
    |                                    |  data=...   |             |
    |<-- Data indication ----------------|             |             |
    |    Transaction-Id=0x8231AE8F9242DA9FF287FEFF     |             |
    |    XOR-PEER-ADDRESS=192.0.2.150:32102            |             |
    |    DATA=...                        |             |             |

   The client now sends application data to Peer A using a Send
   indication.  Peer A's server-reflexive transport address is specified
   in the XOR-PEER-ADDRESS attribute, and the application data (shown
   here as just "...") is specified in the DATA attribute.  The client
   is doing a form of path MTU discovery at the application layer and
   thus specifies (by including the DONT-FRAGMENT attribute) that the
   server should set the DF bit in the UDP datagram to send to the peer.
   Indications cannot be authenticated using the long-term credential
   mechanism of STUN, so no MESSAGE-INTEGRITY attribute is included in
   the message.  An application wishing to ensure that its data is not
   altered or forged must integrity-protect its data at the application
   level.

   Upon receipt of the Send indication, the server extracts the
   application data and sends it in a UDP datagram to Peer A, with the
   relayed transport address as the source transport address of the
   datagram, and with the DF bit set as requested.  Note that, had the
   client not previously established a permission for Peer A's server-
   reflexive IP address, then the server would have silently discarded
   the Send indication instead.
Top   ToC   RFC5766 - Page 53
   Peer A then replies with its own UDP datagram containing application
   data.  The datagram is sent to the relayed transport address on the
   server.  When this arrives, the server creates a Data indication
   containing the source of the UDP datagram in the XOR-PEER-ADDRESS
   attribute, and the data from the UDP datagram in the DATA attribute.
   The resulting Data indication is then sent to the client.

  TURN                                 TURN           Peer          Peer
  client                               server          A             B
    |--- ChannelBind request ----------->|             |             |
    |    Transaction-Id=0x6490D3BC175AFF3D84513212     |             |
    |    CHANNEL-NUMBER=0x4000           |             |             |
    |    XOR-PEER-ADDRESS=192.0.2.210:49191            |             |
    |    USERNAME="George"               |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"      |             |
    |    MESSAGE-INTEGRITY=...           |             |             |
    |                                    |             |             |
    |<-- ChannelBind success response ---|             |             |
    |    Transaction-Id=0x6490D3BC175AFF3D84513212     |             |
    |    MESSAGE-INTEGRITY=...           |             |             |

   The client now binds a channel to Peer B, specifying a free channel
   number (0x4000) in the CHANNEL-NUMBER attribute, and Peer B's
   transport address in the XOR-PEER-ADDRESS attribute.  As before, the
   client re-uses the username, realm, and nonce from its last request
   in the message.

   Upon receipt of the request, the server binds the channel number to
   the peer, installs a permission for Peer B's IP address, and then
   replies with ChannelBind success response.

  TURN                                 TURN           Peer          Peer
  client                               server          A             B
    |--- ChannelData ------------------->|             |             |
    |    Channel-number=0x4000           |--- UDP datagram --------->|
    |    Data=...                        |    Data=...               |
    |                                    |             |             |
    |                                    |<-- UDP datagram ----------|
    |                                    |    Data=... |             |
    |<-- ChannelData --------------------|             |             |
    |    Channel-number=0x4000           |             |             |
    |    Data=...                        |             |             |

   The client now sends a ChannelData message to the server with data
   destined for Peer B.  The ChannelData message is not a STUN message,
   and thus has no transaction id.  Instead, it has only three fields: a
   channel number, data, and data length; here the channel number field
Top   ToC   RFC5766 - Page 54
   is 0x4000 (the channel the client just bound to Peer B).  When the
   server receives the ChannelData message, it checks that the channel
   is currently bound (which it is) and then sends the data onward to
   Peer B in a UDP datagram, using the relayed transport address as the
   source transport address and 192.0.2.210:49191 (the value of the XOR-
   PEER-ADDRESS attribute in the ChannelBind request) as the destination
   transport address.

   Later, Peer B sends a UDP datagram back to the relayed transport
   address.  This causes the server to send a ChannelData message to the
   client containing the data from the UDP datagram.  The server knows
   to which client to send the ChannelData message because of the
   relayed transport address at which the UDP datagram arrived, and
   knows to use channel 0x4000 because this is the channel bound to
   192.0.2.210:49191.  Note that if there had not been any channel
   number bound to that address, the server would have used a Data
   indication instead.

  TURN                                 TURN           Peer          Peer
  client                               server          A             B
    |--- Refresh request --------------->|             |             |
    |    Transaction-Id=0x0864B3C27ADE9354B4312414     |             |
    |    SOFTWARE="Example client 1.03"  |             |             |
    |    USERNAME="George"               |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"      |             |
    |    MESSAGE-INTEGRITY=...           |             |             |
    |                                    |             |             |
    |<-- Refresh error response ---------|             |             |
    |    Transaction-Id=0x0864B3C27ADE9354B4312414     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    ERROR-CODE=438 (Stale Nonce)    |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j"       |             |
    |                                    |             |             |
    |--- Refresh request --------------->|             |             |
    |    Transaction-Id=0x427BD3E625A85FC731DC4191     |             |
    |    SOFTWARE="Example client 1.03"  |             |             |
    |    USERNAME="George"               |             |             |
    |    REALM="example.com"             |             |             |
    |    NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j"       |             |
    |    MESSAGE-INTEGRITY=...           |             |             |
    |                                    |             |             |
    |<-- Refresh success response -------|             |             |
    |    Transaction-Id=0x427BD3E625A85FC731DC4191     |             |
    |    SOFTWARE="Example server, version 1.17"       |             |
    |    LIFETIME=600 (10 minutes)       |             |             |
Top   ToC   RFC5766 - Page 55
   Sometime before the 20 minute lifetime is up, the client refreshes
   the allocation.  This is done using a Refresh request.  As before,
   the client includes the latest username, realm, and nonce values in
   the request.  The client also includes the SOFTWARE attribute,
   following the recommended practice of always including this attribute
   in Allocate and Refresh messages.  When the server receives the
   Refresh request, it notices that the nonce value has expired, and so
   replies with 438 (Stale Nonce) error given a new nonce value.  The
   client then reattempts the request, this time with the new nonce
   value.  This second attempt is accepted, and the server replies with
   a success response.  Note that the client did not include a LIFETIME
   attribute in the request, so the server refreshes the allocation for
   the default lifetime of 10 minutes (as can be seen by the LIFETIME
   attribute in the success response).

17. Security Considerations

This section considers attacks that are possible in a TURN deployment, and discusses how they are mitigated by mechanisms in the protocol or recommended practices in the implementation. Most of the attacks on TURN are mitigated by the server requiring requests be authenticated. Thus, this specification requires the use of authentication. The mandatory-to-implement mechanism is the long- term credential mechanism of STUN. Other authentication mechanisms of equal or stronger security properties may be used. However, it is important to ensure that they can be invoked in an inter-operable way.

17.1. Outsider Attacks

Outsider attacks are ones where the attacker has no credentials in the system, and is attempting to disrupt the service seen by the client or the server.

17.1.1. Obtaining Unauthorized Allocations

An attacker might wish to obtain allocations on a TURN server for any number of nefarious purposes. A TURN server provides a mechanism for sending and receiving packets while cloaking the actual IP address of the client. This makes TURN servers an attractive target for attackers who wish to use it to mask their true identity. An attacker might also wish to simply utilize the services of a TURN server without paying for them. Since TURN services require resources from the provider, it is anticipated that their usage will come with a cost.
Top   ToC   RFC5766 - Page 56
   These attacks are prevented using the long-term credential mechanism,
   which allows the TURN server to determine the identity of the
   requestor and whether the requestor is allowed to obtain the
   allocation.

17.1.2. Offline Dictionary Attacks

The long-term credential mechanism used by TURN is subject to offline dictionary attacks. An attacker that is capable of eavesdropping on a message exchange between a client and server can determine the password by trying a number of candidate passwords and seeing if one of them is correct. This attack works when the passwords are low entropy, such as a word from the dictionary. This attack can be mitigated by using strong passwords with large entropy. In situations where even stronger mitigation is required, TLS transport between the client and the server can be used.

17.1.3. Faked Refreshes and Permissions

An attacker might wish to attack an active allocation by sending it a Refresh request with an immediate expiration, in order to delete it and disrupt service to the client. This is prevented by authentication of refreshes. Similarly, an attacker wishing to send CreatePermission requests to create permissions to undesirable destinations is prevented from doing so through authentication. The motivations for such an attack are described in Section 17.2.

17.1.4. Fake Data

An attacker might wish to send data to the client or the peer, as if they came from the peer or client, respectively. To do that, the attacker can send the client a faked Data Indication or ChannelData message, or send the TURN server a faked Send Indication or ChannelData message. Since indications and ChannelData messages are not authenticated, this attack is not prevented by TURN. However, this attack is generally present in IP-based communications and is not substantially worsened by TURN. Consider a normal, non-TURN IP session between hosts A and B. An attacker can send packets to B as if they came from A by sending packets towards A with a spoofed IP address of B. This attack requires the attacker to know the IP addresses of A and B. With TURN, an attacker wishing to send packets towards a client using a Data indication needs to know its IP address (and port), the IP address and port of the TURN server, and the IP address and port of the peer (for inclusion in the XOR-PEER-ADDRESS attribute). To send a fake ChannelData message to a client, an attacker needs to know the IP address and port of the client, the IP address and port
Top   ToC   RFC5766 - Page 57
   of the TURN server, and the channel number.  This particular
   combination is mildly more guessable than in the non-TURN case.

   These attacks are more properly mitigated by application-layer
   authentication techniques.  In the case of real-time traffic, usage
   of SRTP [RFC3711] prevents these attacks.

   In some situations, the TURN server may be situated in the network
   such that it is able to send to hosts to which the client cannot
   directly send.  This can happen, for example, if the server is
   located behind a firewall that allows packets from outside the
   firewall to be delivered to the server, but not to other hosts behind
   the firewall.  In these situations, an attacker could send the server
   a Send indication with an XOR-PEER-ADDRESS attribute containing the
   transport address of one of the other hosts behind the firewall.  If
   the server was to allow relaying of traffic to arbitrary peers, then
   this would provide a way for the attacker to attack arbitrary hosts
   behind the firewall.

   To mitigate this attack, TURN requires that the client establish a
   permission to a host before sending it data.  Thus, an attacker can
   only attack hosts with which the client is already communicating,
   unless the attacker is able to create authenticated requests.
   Furthermore, the server administrator may configure the server to
   restrict the range of IP addresses and ports to which it will relay
   data.  To provide even greater security, the server administrator can
   require that the client use TLS for all communication between the
   client and the server.

17.1.5. Impersonating a Server

When a client learns a relayed address from a TURN server, it uses that relayed address in application protocols to receive traffic. Therefore, an attacker wishing to intercept or redirect that traffic might try to impersonate a TURN server and provide the client with a faked relayed address. This attack is prevented through the long-term credential mechanism, which provides message integrity for responses in addition to verifying that they came from the server. Furthermore, an attacker cannot replay old server responses as the transaction id in the STUN header prevents this. Replay attacks are further thwarted through frequent changes to the nonce value.
Top   ToC   RFC5766 - Page 58

17.1.6. Eavesdropping Traffic

TURN concerns itself primarily with authentication and message integrity. Confidentiality is only a secondary concern, as TURN control messages do not include information that is particularly sensitive. The primary protocol content of the messages is the IP address of the peer. If it is important to prevent an eavesdropper on a TURN connection from learning this, TURN can be run over TLS. Confidentiality for the application data relayed by TURN is best provided by the application protocol itself, since running TURN over TLS does not protect application data between the server and the peer. If confidentiality of application data is important, then the application should encrypt or otherwise protect its data. For example, for real-time media, confidentiality can be provided by using SRTP.

17.1.7. TURN Loop Attack

An attacker might attempt to cause data packets to loop indefinitely between two TURN servers. The attack goes as follows. First, the attacker sends an Allocate request to server A, using the source address of server B. Server A will send its response to server B, and for the attack to succeed, the attacker must have the ability to either view or guess the contents of this response, so that the attacker can learn the allocated relayed transport address. The attacker then sends an Allocate request to server B, using the source address of server A. Again, the attacker must be able to view or guess the contents of the response, so it can send learn the allocated relayed transport address. Using the same spoofed source address technique, the attacker then binds a channel number on server A to the relayed transport address on server B, and similarly binds the same channel number on server B to the relayed transport address on server A. Finally, the attacker sends a ChannelData message to server A. The result is a data packet that loops from the relayed transport address on server A to the relayed transport address on server B, then from server B's transport address to server A's transport address, and then around the loop again. This attack is mitigated as follows. By requiring all requests to be authenticated and/or by randomizing the port number allocated for the relayed transport address, the server forces the attacker to either intercept or view responses sent to a third party (in this case, the other server) so that the attacker can authenticate the requests and learn the relayed transport address. Without one of these two measures, an attacker can guess the contents of the responses without
Top   ToC   RFC5766 - Page 59
   needing to see them, which makes the attack much easier to perform.
   Furthermore, by requiring authenticated requests, the server forces
   the attacker to have credentials acceptable to the server, which
   turns this from an outsider attack into an insider attack and allows
   the attack to be traced back to the client initiating it.

   The attack can be further mitigated by imposing a per-username limit
   on the bandwidth used to relay data by allocations owned by that
   username, to limit the impact of this attack on other allocations.
   More mitigation can be achieved by decrementing the TTL when relaying
   data packets (if the underlying OS allows this).

17.2. Firewall Considerations

A key security consideration of TURN is that TURN should not weaken the protections afforded by firewalls deployed between a client and a TURN server. It is anticipated that TURN servers will often be present on the public Internet, and clients may often be inside enterprise networks with corporate firewalls. If TURN servers provide a 'backdoor' for reaching into the enterprise, TURN will be blocked by these firewalls. TURN servers therefore emulate the behavior of NAT devices that implement address-dependent filtering [RFC4787], a property common in many firewalls as well. When a NAT or firewall implements this behavior, packets from an outside IP address are only allowed to be sent to an internal IP address and port if the internal IP address and port had recently sent a packet to that outside IP address. TURN servers introduce the concept of permissions, which provide exactly this same behavior on the TURN server. An attacker cannot send a packet to a TURN server and expect it to be relayed towards the client, unless the client has tried to contact the attacker first. It is important to note that some firewalls have policies that are even more restrictive than address-dependent filtering. Firewalls can also be configured with address- and port-dependent filtering, or can be configured to disallow inbound traffic entirely. In these cases, if a client is allowed to connect the TURN server, communications to the client will be less restrictive than what the firewall would normally allow.

17.2.1. Faked Permissions

In firewalls and NAT devices, permissions are granted implicitly through the traversal of a packet from the inside of the network towards the outside peer. Thus, a permission cannot, by definition, be created by any entity except one inside the firewall or NAT. With TURN, this restriction no longer holds. Since the TURN server sits
Top   ToC   RFC5766 - Page 60
   outside the firewall, at attacker outside the firewall can now send a
   message to the TURN server and try to create a permission for itself.

   This attack is prevented because all messages that create permissions
   (i.e., ChannelBind and CreatePermission) are authenticated.

17.2.2. Blacklisted IP Addresses

Many firewalls can be configured with blacklists that prevent a client behind the firewall from sending packets to, or receiving packets from, ranges of blacklisted IP addresses. This is accomplished by inspecting the source and destination addresses of packets entering and exiting the firewall, respectively. This feature is also present in TURN, since TURN servers are allowed to arbitrarily restrict the range of addresses of peers that they will relay to.

17.2.3. Running Servers on Well-Known Ports

A malicious client behind a firewall might try to connect to a TURN server and obtain an allocation which it then uses to run a server. For example, a client might try to run a DNS server or FTP server. This is not possible in TURN. A TURN server will never accept traffic from a peer for which the client has not installed a permission. Thus, peers cannot just connect to the allocated port in order to obtain the service.

17.3. Insider Attacks

In insider attacks, a client has legitimate credentials but defies the trust relationship that goes with those credentials. These attacks cannot be prevented by cryptographic means but need to be considered in the design of the protocol.

17.3.1. DoS against TURN Server

A client wishing to disrupt service to other clients might obtain an allocation and then flood it with traffic, in an attempt to swamp the server and prevent it from servicing other legitimate clients. This is mitigated by the recommendation that the server limit the amount of bandwidth it will relay for a given username. This won't prevent a client from sending a large amount of traffic, but it allows the server to immediately discard traffic in excess. Since each allocation uses a port number on the IP address of the TURN server, the number of allocations on a server is finite. An
Top   ToC   RFC5766 - Page 61
   attacker might attempt to consume all of them by requesting a large
   number of allocations.  This is prevented by the recommendation that
   the server impose a limit of the number of allocations active at a
   time for a given username.

17.3.2. Anonymous Relaying of Malicious Traffic

TURN servers provide a degree of anonymization. A client can send data to peers without revealing its own IP address. TURN servers may therefore become attractive vehicles for attackers to launch attacks against targets without fear of detection. Indeed, it is possible for a client to chain together multiple TURN servers, such that any number of relays can be used before a target receives a packet. Administrators who are worried about this attack can maintain logs that capture the actual source IP and port of the client, and perhaps even every permission that client installs. This will allow for forensic tracing to determine the original source, should it be discovered that an attack is being relayed through a TURN server.

17.3.3. Manipulating Other Allocations

An attacker might attempt to disrupt service to other users of the TURN server by sending Refresh requests or CreatePermission requests that (through source address spoofing) appear to be coming from another user of the TURN server. TURN prevents this by requiring that the credentials used in CreatePermission, Refresh, and ChannelBind messages match those used to create the initial allocation. Thus, the fake requests from the attacker will be rejected.

17.4. Other Considerations

Any relay addresses learned through an Allocate request will not operate properly with IPsec Authentication Header (AH) [RFC4302] in transport or tunnel mode. However, tunnel-mode IPsec Encapsulating Security Payload (ESP) [RFC4303] should still operate.

18. IANA Considerations

Since TURN is an extension to STUN [RFC5389], the methods, attributes, and error codes defined in this specification are new methods, attributes, and error codes for STUN. IANA has added these new protocol elements to the IANA registry of STUN protocol elements. The codepoints for the new STUN methods defined in this specification are listed in Section 13.
Top   ToC   RFC5766 - Page 62
   The codepoints for the new STUN attributes defined in this
   specification are listed in Section 14.

   The codepoints for the new STUN error codes defined in this
   specification are listed in Section 15.

   IANA has allocated the SRV service name of "turn" for TURN over UDP
   or TCP, and the service name of "turns" for TURN over TLS.

   IANA has created a registry for TURN channel numbers, initially
   populated as follows:

      0x0000 through 0x3FFF: Reserved and not available for use, since
      they conflict with the STUN header.

      0x4000 through 0x7FFF: A TURN implementation is free to use
      channel numbers in this range.

      0x8000 through 0xFFFF: Unassigned.

   Any change to this registry must be made through an IETF Standards
   Action.

19. IAB Considerations

The IAB has studied the problem of "Unilateral Self Address Fixing" (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol-reflection mechanism [RFC3424]. The TURN extension is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. These considerations and the responses for TURN are documented in this section. Consideration 1: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short-term fix should not be generalized to solve other problems. Such generalizations lead to the prolonged dependence on and usage of the supposed short-term fix -- meaning that it is no longer accurate to call it "short-term". Response: TURN is a protocol for communication between a relay (= TURN server) and its client. The protocol allows a client that is behind a NAT to obtain and use a public IP address on the relay. As a convenience to the client, TURN also allows the client to determine its server-reflexive transport address.
Top   ToC   RFC5766 - Page 63
   Consideration 2: Description of an exit strategy/transition plan.
   The better short-term fixes are the ones that will naturally see less
   and less use as the appropriate technology is deployed.

   Response: TURN will no longer be needed once there are no longer any
   NATs.  Unfortunately, as of the date of publication of this document,
   it no longer seems very likely that NATs will go away any time soon.
   However, the need for TURN will also decrease as the number of NATs
   with the mapping property of Endpoint-Independent Mapping [RFC4787]
   increases.

   Consideration 3: Discussion of specific issues that may render
   systems more "brittle".  For example, approaches that involve using
   data at multiple network layers create more dependencies, increase
   debugging challenges, and make it harder to transition.

   Response: TURN is "brittle" in that it requires the NAT bindings
   between the client and the server to be maintained unchanged for the
   lifetime of the allocation.  This is typically done using keep-
   alives.  If this is not done, then the client will lose its
   allocation and can no longer exchange data with its peers.

   Consideration 4: Identify requirements for longer-term, sound
   technical solutions; contribute to the process of finding the right
   longer-term solution.

   Response: The need for TURN will be reduced once NATs implement the
   recommendations for NAT UDP behavior documented in [RFC4787].
   Applications are also strongly urged to use ICE [RFC5245] to
   communicate with peers; though ICE uses TURN, it does so only as a
   last resort, and uses it in a controlled manner.

   Consideration 5: Discussion of the impact of the noted practical
   issues with existing deployed NATs and experience reports.

   Response: Some NATs deployed today exhibit a mapping behavior other
   than Endpoint-Independent mapping.  These NATs are difficult to work
   with, as they make it difficult or impossible for protocols like ICE
   to use server-reflexive transport addresses on those NATs.  A client
   behind such a NAT is often forced to use a relay protocol like TURN
   because "UDP hole punching" techniques [RFC5128] do not work.

20. Acknowledgements

The authors would like to thank the various participants in the BEHAVE working group for their many comments on this document. Marc Petit-Huguenin, Remi Denis-Courmont, Jason Fischl, Derek MacDonald, Scott Godin, Cullen Jennings, Lars Eggert, Magnus Westerlund, Benny
Top   ToC   RFC5766 - Page 64
   Prijono, and Eric Rescorla have been particularly helpful, with Eric
   suggesting the channel allocation mechanism, Cullen suggesting an
   earlier version of the EVEN-PORT mechanism, and Marc spending many
   hours implementing the preliminary versions to look for problems.
   Christian Huitema was an early contributor to this document and was a
   co-author on the first few versions.  Finally, the authors would like
   to thank Dan Wing for both his contributions to the text and his huge
   help in restarting progress on this document after work had stalled.

21. References

21.1. Normative References

[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

21.2. Informative References

[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
Top   ToC   RFC5766 - Page 65
   [RFC3424]            Daigle, L. and IAB, "IAB Considerations for
                        UNilateral Self-Address Fixing (UNSAF) Across
                        Network Address Translation", RFC 3424,
                        November 2002.

   [RFC4787]            Audet, F. and C. Jennings, "Network Address
                        Translation (NAT) Behavioral Requirements for
                        Unicast UDP", BCP 127, RFC 4787, January 2007.

   [RFC5245]            Rosenberg, J., "Interactive Connectivity
                        Establishment (ICE): A Protocol for Network
                        Address Translator (NAT) Traversal for
                        Offer/Answer Protocols", RFC 5245, April 2010.

   [TURN-TCP]           Perreault, S. and J. Rosenberg, "Traversal Using
                        Relays around NAT (TURN) Extensions for TCP
                        Allocations", Work in Progress, March 2010.

   [TURN-IPv6]          Perreault, S., Camarillo, G., and O. Novo,
                        "Traversal Using Relays around NAT (TURN)
                        Extension for IPv6", Work in Progress, March
                        2010.

   [TSVWG-PORT]         Larsen, M. and F. Gont, "Port Randomization",
                        Work in Progress, April 2010.

   [RFC5128]            Srisuresh, P., Ford, B., and D. Kegel, "State of
                        Peer-to-Peer (P2P) Communication across Network
                        Address Translators (NATs)", RFC 5128,
                        March 2008.

   [RFC1928]            Leech, M., Ganis, M., Lee, Y., Kuris, R.,
                        Koblas, D., and L. Jones, "SOCKS Protocol
                        Version 5", RFC 1928, March 1996.

   [RFC3550]            Schulzrinne, H., Casner, S., Frederick, R., and
                        V. Jacobson, "RTP: A Transport Protocol for
                        Real-Time Applications", STD 64, RFC 3550,
                        July 2003.

   [RFC3711]            Baugher, M., McGrew, D., Naslund, M., Carrara,
                        E., and K. Norrman, "The Secure Real-time
                        Transport Protocol (SRTP)", RFC 3711,
                        March 2004.

   [RFC4302]            Kent, S., "IP Authentication Header", RFC 4302,
                        December 2005.
Top   ToC   RFC5766 - Page 66
   [RFC4303]            Kent, S., "IP Encapsulating Security Payload
                        (ESP)", RFC 4303, December 2005.

   [RFC4821]            Mathis, M. and J. Heffner, "Packetization Layer
                        Path MTU Discovery", RFC 4821, March 2007.

   [RFC3261]            Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                        Johnston, A., Peterson, J., Sparks, R., Handley,
                        M., and E. Schooler, "SIP: Session Initiation
                        Protocol", RFC 3261, June 2002.

   [MMUSIC-ICE-NONSIP]  Rosenberg, J., "Guidelines for Usage of
                        Interactive Connectivity Establishment (ICE) by
                        non Session Initiation Protocol (SIP)
                        Protocols", Work in Progress, July 2008.

   [RFC4086]            Eastlake, D., Schiller, J., and S. Crocker,
                        "Randomness Requirements for Security", BCP 106,
                        RFC 4086, June 2005.

   [Frag-Harmful]       Kent and Mogul, "Fragmentation Considered
                        Harmful".  Proc. SIGCOMM '87, vol. 17, No. 5,
                        October 1987

   [Port-Numbers]       "IANA Port Numbers Registry",
                        <http://www.iana.org>.

   [Protocol-Numbers]   "IANA Protocol Numbers Registry", 2005,
                        <http://www.iana.org>.
Top   ToC   RFC5766 - Page 67

Authors' Addresses

Rohan Mahy Unaffiliated EMail: rohan@ekabal.com Philip Matthews Alcatel-Lucent 600 March Road Ottawa, Ontario Canada EMail: philip_matthews@magma.ca Jonathan Rosenberg jdrosen.net Monmouth, NJ USA EMail: jdrosen@jdrosen.net URI: http://www.jdrosen.net