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).

   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=...           |             |             |

   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

   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.

   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.

   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

   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)       |             |             |

   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.

   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

   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.

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

   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

   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

   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.

   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.

   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

   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.

   [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.

   [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>.

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