`Internet—Draft
`Expires: August 22, 2005
`
`J. Rosenberg
`Cisco Systems
`R. Mahy
`Airspace
`C. Huitema
`Microsoft
`February 21, 2005
`
`Traversal Using Relay NAT (TURN)
`draft—rosenberg—midcom—turn—07
`
`Status of this Memo
`
`This document is an Internet—Draft and is subject to all provisions
`of section 3 of RFC 3667.
`By submitting this Internet—Draft, each
`author represents that any applicable patent or other IPR claims of
`which he or she is aware have been or will be disclosed, and any of
`which he or she become aware will be disclosed,
`in accordance with
`RFC 3668.
`
`Internet—Drafts are working documents of the Internet Engineering
`Task Force (IETF), its areas, and its working groups. Note that
`other groups may also distribute working documents as
`Internet—Drafts.
`
`Internet—Drafts are draft documents valid for a maximum of six months
`and may be updated,
`replaced, or Obsoleted by other documents at any
`time.
`It is inappropriate to use Internet—Drafts as reference
`material or to cite them other than as "work in progress."
`
`The list of current Internet—Drafts can be accessed at
`http://www.ietf.org/ietf/lid-abstracts.txt.
`
`The list of Internet—Draft Shadow Directories can be accessed at
`http://www.ietf.org/shadow.html.
`
`This Internet—Draft will expire on August 22, 2005.
`
`Copyright Notice
`
`Copyright
`
`(C) The Internet Society (2005).
`
`Abstract
`
`is a protocol that allows for an
`Traversal Using Relay NAT (TURN)
`element behind a NAT or firewall to receive incoming data over TCP or
`UDP connections.
`It is most useful for elements behind symmetric
`NATs or firewalls that wish to be on the receiving end of a
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 1]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`TURN does not allow for users to run
`connection to a single peer.
`servers on well known ports if they are behind a nat; it supports the
`connection of a user behind a nat to only a single peer.
`In that
`regard,
`its role is to provide the same security functions provided
`by symmetric NATs and firewalls, but to "turn" them into
`port—restricted NATs.
`
`Table of Contents
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`4
`4
`4
`5
`5
`7
`7
`.
`8
`.
`. 10
`. 10
`. 10
`. 13
`. 14
`. 15
`. 17
`. 17
`. 17
`. 18
`. 19
`. 20
`. 21
`. 21
`. 22
`. 22
`. 23
`. 23
`. 23
`. 23
`. 24
`. 24
`. 24
`. 24
`. 24
`. 25
`. 25
`. 25
`. 25
`. 27
`. 27
`
`
`
`Introduction
`1.
`2. Terminology
`.
`3. Definitions
`4. Applicability Statement
`5. Overview of Operation
`6. Message Overview
`.
`.
`.
`.
`.
`.
`.
`.
`7.
`Server Behavior
`.
`.
`.
`.
`7.1
`Shared Secret Request
`.
`.
`.
`.
`.
`7.2 Allocate Request
`.
`.
`.
`.
`.
`.
`.
`7.2.1
`Overview .
`.
`.
`.
`.
`.
`.
`.
`7.2.2
`Initial Requests .
`.
`.
`.
`.
`7.2.3
`Subsequent Requests
`.
`7.3
`Send Request
`.
`.
`.
`.
`7.4
`Receiving Packets and Connections
`7.5
`Lifetime Expiration
`.
`.
`.
`.
`.
`.
`8. Client Behavior
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`8.1
`Discovery
`.
`.
`.
`.
`.
`.
`.
`.
`8.2
`Obtaining a One Time Password
`.
`8.3 Allocating a Binding .
`.
`.
`.
`.
`8.4
`Processing Allocate Responses
`.
`8.5
`Refreshing a Binding .
`.
`.
`.
`.
`8.6
`Sending Data .
`.
`.
`.
`.
`.
`.
`.
`.
`8.7
`Tearing Down a Binding .
`.
`.
`.
`8.8
`Receiving and Sending Data .
`.
`Protocol Details .
`.
`.
`.
`.
`.
`.
`.
`.
`9.1 Message Types
`.
`.
`.
`.
`.
`.
`.
`.
`9.2 Message Attributes .
`.
`.
`.
`.
`.
`9.2.1
`LIFETIME .
`.
`.
`.
`.
`.
`.
`.
`9.2.2
`ALTERNATE— SERVER .
`.
`.
`.
`.
`9.2.3
`MAGIC— COOKIE .
`.
`.
`.
`.
`.
`.
`9.2.4
`BANDWIDTH
`.
`.
`.
`.
`.
`9.2.5
`DESTINATION- ADDRESS .
`.
`.
`9.2.6
`SOURCE—ADDRESS .
`.
`.
`.
`.
`.
`9.2.7
`DATA .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`9.2.8
`NONCE
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`9.2.9
`Response Codes
`.
`.
`.
`.
`.
`.
`Security Considerations
`.
`.
`.
`.
`IAB Considerations .
`.
`.
`.
`.
`.
`Problem Definition .
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`9.
`
`10.
`11.
`11.1
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 2]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`ences
`erences
`S
`.
`.
`.
`
`erty and Copyright Statements
`
`27
`28
`29
`29
`29
`29
`29
`30
`3O
`32
`
`Exit Strategy
`Brittleness I
`
`U'lrbUJN
`
`ll.
`ll.
`11.
`ll.
`12.
`13.
`13.
`13.
`
`l 2
`
`ntroduced by TURN
`Requirements for a Long Term Solution
`Issues with Existing NAPT Boxes
`Examples
`References
`Normative Refer
`Informative Ref
`Authors’ Addresse
`Intellectual Prop
`
`Rosenberg, et al.
`
`Expires August 22,
`
`2005
`
`[Page 3]
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`l.
`
`Introduction
`
`Network Address Translators (NATs), while providing many benefits,
`also come with many drawbacks.
`The most
`troublesome of those
`drawbacks is the fact that they break many existing IP applications,
`and make it difficult to deploy new ones. Guidelines [9] have been
`developed that describe how to build "NAT friendly" protocols, but
`many protocols simply cannot be constructed according to those
`guidelines.
`Examples of such protocols include multimedia
`applications and file sharing.
`
`[1] provides one means for
`Simple Traversal of UDP Through NAT (STUN)
`an application to traverse a NAT.
`STUN allows a client to obtain a
`transport address (and IP address and port) which may be useful for
`receiving packets from a peer. However, addresses obtained by STUN
`may not be usable by all peers.
`Those addresses work depending on
`the topological conditions of the network. Therefore, STUN by itself
`cannot provide a complete solution for NAT traversal.
`
`A complete solution requires a means by which a client can obtain a
`transport address from which it can receive media from any peer which
`can send packets to the public Internet. This can only be
`accomplished by relaying data though a server that resides on the
`public Internet. This specification describes Traversal Using Relay
`NAT (TURN), a protocol that allows a client to obtain IP addresses
`and ports from such a relay.
`
`Although TURN will almost always provide connectivity to a client, it
`comes at high cost to the provider of the TURN server.
`It is
`therefore desirable to use TURN as a last resort only, preferring
`other mechanisms
`(such as STUN or direct connectivity) when possible.
`To accomplish that,
`the Interactive Connectivity Establishment
`(ICE)
`[l3] methodology can be used to discover the optimal means of
`connectivity.
`
`Terminology
`
`the key words MUST, MUST NOT, REQUIRED, SHALL,
`In this document,
`SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to
`be interpreted as described in RFC 2119 [2] and indicate requirement
`levels for compliant TURN implementations.
`
`3.
`
`Definitions
`
`(also just referred to as a client) is
`TURN Client: A TURN client
`an entity that generates TURN requests.
`A TURN client can be an
`end system, such as a Session Initiation Protocol
`(SIP)
`[6] User
`Agent, or can be a network element, such as a Back—to—Back User
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 4]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`The TURN protocol will provide the TURN
`(B2BUA) SIP server.
`Agent
`client with IP addresses that route to it from the public
`Internet.
`
`is
`(also just referred to as a server)
`TURN Server: A TURN Server
`an entity that receives TURN requests, and sends TURN responses.
`The server is capable of acting as a data relay, receiving data on
`the address it provides to clients, and forwarding them to the
`clients.
`
`Transport Address: An IP address and port.
`
`4.
`
`Applicability Statement
`
`TURN is useful for applications that require a client to place a
`transport address into a protocol message, with the expectation that
`the client will be able to receive packets from a single host that
`will send to this address.
`Examples of such protocols include SIP,
`which makes use of the Session Description Protocol
`(SDP)
`[7].
`SDP
`carries and IP address on which the client will receive media packets
`from its peer. Another example of a protocol meeting this criteria
`is the Real Time Streaming Protocol
`(RTSP)
`[8].
`
`transport addresses obtained from the
`When a client is behind a NAT,
`local operating system will not be publically routable, and
`therefore, not useful in these protocols.
`TURN allows a client to
`obtain a transport address,
`from a server on the public Internet,
`which can be used in protocols meeting the above criteria. However,
`the transport addresses obtained from TURN servers are not generally
`useful for receiving data from anywhere.
`They are only useful for
`communicating with a single peer. This is accomplished by having the
`TURN server emulate the behavior of a port-restricted NAT.
`In
`particular,
`the TURN server will only relay packets from an external
`IP address and port towards the client if the client had previously
`sent a packet through the TURN server towards that IP address and
`port. As a result of this, when a TURN server is placed in front of
`a symmetric NAT,
`the resulting combined system has identical security
`properties to a system that just had a port—restricted NAT.
`Since
`clients behind such devices cannot run public servers,
`they cannot
`run them behind TURN servers either.
`
`Overview of Operation
`
`A TURN client
`The typical TURN configuration is shown in Figure 1.
`is connected to private network 1. This network connects to private
`network 2 through NAT 1. Private network 2 connects to the public
`Internet through NAT 2.
`On the public Internet is a TURN server.
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 5]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`/ ----- \
`// TURN
`Server
`
`\\
`
`|
`
`\\
`
`//
`
`|
`
`+ ______________ +
`
`Public Internet
`
`
`
`//
`
`\\
`
`|
`
`TURN \\
`Client
`//
`
`|
`
`\ ----- /
`
`Figure 1
`
`Private NET 1
`
`It is identical in syntax
`TURN is a simple client—server protocol.
`and general operation to STUN,
`in order to facilitate a joint
`implementation of both.
`TURN defines a request message, called
`Allocate, which asks for a public IP address and port.
`TURN can run
`over UDP and TCP, as it allows for a client to request address/port
`pairs for receiving both UDP and TCP.
`
`A TURN client first discovers the address of a TURN server. This can
`be preconfigured, or it can be discovered using SRV records [3] This
`will allow for different TURN servers for UDP and TCP. Once a TURN
`server is discovered,
`the client sends a TURN Allocate request to the
`TURN server.
`TURN provides a mechanism for mutual authentication and
`integrity checks for both requests and responses, based on a shared
`secret. Assuming the request is authenticated and has not been
`tampered with,
`the TURN server remembers the source transport address
`that the request came from (call this SA), and returns a public
`transport address, PA,
`in the TURN response.
`The TURN server is
`responsible for guaranteeing that packets sent to PA route to the
`TURN server. However,
`the TURN server will not relay any packets
`from PA to SA until the client sends a packet through the TURN server
`towards a correspondent.
`To do that, a client sends a TURN SEND
`command, which includes a data packet and a destination IP address
`and port.
`The TURN server, upon receipt of this command, will
`forward the packet to that IP address and port, add a "permission"
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 6]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`so that inbound packets from that
`for that IP address and port,
`address and port are permitted, and set the default destination
`address to that address and port.
`From that point forward, non—TURN
`UDP packets sent from the client to the TURN server are relayed to
`this default IP address and port.
`Packets received from this IP
`address and port are relayed to the client.
`If a packet arrives from
`an IP address and port for which there is a permission, but which is
`not the current default destination IP address and port,
`the TURN
`server forwards this packet to the client wrapped in a DATA command,
`which informs the client of the source IP address and port.
`
`the TURN server does not need to examine the data received;
`For TCP,
`it merely forwards all data between the socket pairs it has
`associated together.
`In the case of UDP,
`the TURN server looks for a
`magic cookie in the first 128 bytes of each UDP packet.
`If present,
`it indicates that the packet is a TURN control packet, used for
`keepalives and teardown of the binding.
`In the case of TCP,
`if
`either side closes a connection,
`the TURN server closes the other
`connection.
`For both UDP and TCP,
`the TURN server can also time out
`a connection in the event data is not received after some configured
`time out period. This period is sent to the client in the TURN
`response to the Allocate request.
`
`6. Message Overview
`
`TURN
`TURN messages are identical to STUN messages in their syntax.
`defines several new messages —
`the Allocate Request,
`the Allocate
`Response,
`the Allocate Error Response,
`the Send Request,
`the Send
`Response,
`the Send Error Response and the Data Indication.
`TURN also
`uses the Shared Secret Request, Shared Secret Response, and Shared
`Secret Error Response defined by STUN.
`TURN makes use of some of the
`STUN attributes (MAPPED—ADDRESS, USERNAME, MESSAGE—INTEGRITY,
`ERROR—CODE, and UNKNOWN—ATTRIBUTES) and also defines several of its
`own. Specifically, TURN adds the LIFETIME attribute, which allows
`the TURN server to tell the client when the binding will be released.
`It defines the MAGIC—COOKIE attribute, which allows the TURN client
`to find TURN messages in a stream of UDP packets.
`It defines the
`BANDWIDTH attribute, which allows a client to inform the server of
`the expected bandwidth usage on the connection. Finally, it defines
`the ALTERNATE—SERVER attribute, which allows the server to redirect
`the TURN client to connect to an alternate server.
`
`7.
`
`Server Behavior
`
`The server behavior depends on whether the request is a Shared Secret
`Request or an Allocate Request.
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 7]
`
`
`
`
`
`Internet-Draft
`
`TURN
`
`February 2005
`
`7.1 Shared Secret Request
`
`Unlike a STUN server, a TURN server provides resources to clients
`that connect to it. Therefore, only authorized clients can gain
`access to a TURN server. This requires that TURN requests be
`authenticated.
`TURN assumes the existence of a long—lived shared
`secret between the client and the TURN server in order to achieve
`this authentication.
`The client uses this long—lived shared secret
`to authenticate itself in a Shared Secret Request, sent over TLS.
`The Shared Secret Response provides the client with a one—time
`username and password. This one—time credential is then used by the
`server to authenticate an Allocate Request.
`The usage of a separate
`long lived and one—time credentials prevents dictionary attacks,
`whereby an observer of a message and its HMAC could guess the
`password by an offline dictionary search.
`
`When a TURN server receives a Shared Secret Request, it first
`executes the processing described in the first three paragraphs of
`Section 8.2 of STUN. This processing will ensure that the Shared
`Secret Request is received over TLS.
`
`the server checks the Shared Secret Request for a
`Assuming it was,
`MESSAGE—INTEGRITY attribute.
`If not present,
`the server generates a
`Shared Secret Error Response with an ERROR—CODE attribute with
`response code 401. That response MUST include a NONCE attribute,
`containing a nonce that the server wishes the client to reflect back
`in a subsequent Shared Secret Request
`(and therefore include the
`message integrity computation).
`The response MUST include a REALM
`attribute, containing a realm from which the username and password
`are scoped [4].
`
`the server checks for
`If the MESSAGE—INTEGRITY attribute was present,
`the existence of the REALM attribute.
`If the attribute is not
`present,
`the server MUST generate a Shared Secret Error Response.
`That response MUST include an ERROR—CODE attribute with response code
`434. That response MUST include a NONCE and a REALM attribute.
`
`the server checks for the
`If the REALM attribute was present,
`If the NONCE attribute is not
`existence of the NONCE attribute.
`present,
`the server MUST generate a Shared Secret Error Response.
`That response MUST include an ERROR-CODE attribute with response code
`435. That response MUST include a NONCE attribute and a REALM
`attribute.
`
`the server checks for the
`If the NONCE attribute was present,
`the
`If it was not present,
`existence of the USERNAME attribute.
`server MUST generate a Shared Secret Error Response.
`The Shared
`Secret Error Response MUST include an ERROR—CODE attribute with
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 8]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`response code 432.
`attribute.
`
`It MUST include a NONCE attribute and a REALM
`
`the server computes the HMAC over the
`If the USERNAME is present,
`request as described in Section 11.2.8 of STUN.
`The key is computed
`as MD5(unq(USERNAME—value) ":" unq(REALM—value) ":" passwd), where
`the password is the password associated with the username and realm
`provided in the request.
`If the server does not have a record for
`that username within that realm,
`the server generates a Shared Secret
`Error Response. That response MUST include an ERROR—CODE attribute
`with response code 436. That response MUST include a NONCE attribute
`and a REALM attribute.
`
`This format for the key was chosen so as to enable a common
`authentication database for SIP and for TURN, as it is expected
`that credentials are usually stored in their hashed forms.
`
`If the computed HMAC differs from the one from the MESSAGE-INTEGRITY
`attribute in the request,
`the server MUST generate a Shared Secret
`Error Response with an ERROR—CODE attribute with response code 431.
`This response MUST include a NONCE attribute and a REALM attribute.
`
`If the computed HMAC doesn’t differ from the one in the request, but
`the nonce is stale,
`the server MUST generate a Shared Secret Error
`Response. That response MUST include an ERROR—CODE attribute with
`response code 430. That response MUST include a NONCE attribute and
`a REALM attribute.
`
`the Shared Secret Error Response is sent over the TLS
`In all cases,
`connection on which the Shared Secret Request was received.
`
`The means for
`The server proceeds to authorize the client.
`It is
`authorization are outside the scope of this specification.
`anticipated that TURN servers will be run by providers that also
`provide an application service, such as SIP or RTSP.
`In that case, a
`user would be authorized to use TURN if they are authorized to use
`the application service.
`
`The server then generates a Shared Secret Response as in Section 8.2
`of STUN. This response will contain a USERNAME and PASSWORD, which
`are used by the client as a short—term shared secret in subsequent
`Allocate requests. Note that STUN specifies that the server has to
`invalidate this username and password after 30 minutes. This is not
`the case in TURN.
`In TURN,
`the server MUST store the allocated
`username and password for a duration of at least 30 minutes. Once an
`Allocate request has been authenticated using that username and
`password,
`if the result was an Allocate Error Response,
`the username
`and password are discarded.
`If the result was an Allocate Response,
`
`Rosenberg, et a1.
`
`Expires August 22, 2005
`
`[Page 9]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`the username and password
`resulting in the creation of a new binding,
`become associated with that binding.
`They can only be used to
`authenticate Allocate requests sent
`from the same source transport
`address in order to refresh or de—allocate that binding. Once the
`binding is deleted,
`the username and password are discarded.
`
`This policy avoids replay attacks, whereby a recorded Allocate
`request is replayed in order to obtain a binding without proper
`authentication.
`It also ensures that existing bindings can be
`refreshed without needed to continuously obtain one—time passwords
`from the TURN server.
`
`7.2 Allocate Request
`
`7.2.1 Overview
`
`Allocate requests are used to obtain an IP address and port that the
`client can use to receive UDP and TCP packets from any host on the
`network, even when the client is behind a symmetric NAT.
`To do this,
`a TURN server allocates a local transport address, and passes it to
`the client in an Allocate Response.
`The server also maintains,
`for
`each local transport address, a list of permissions.
`These
`permissions are IP address and port combinations that the client has
`directed a request to, using the SEND primitive.
`The server
`maintains an IP address and port called the default destination.
`This is the default destination for non—TURN packets received from
`the client.
`
`The server maintains a set of bindings. These bindings are
`associations between the five—tuple of received Allocate requests
`(source IP address and port, destination IP address and port, and
`protocol), called the allocate five—tuple, and another five tuple,
`called the remote five—tuple.
`
`The behavior of the server when receiving an Allocate Request depends
`on whether the request is an initial one, or a subsequent one.
`An
`initial request is one received with a source transport address which
`is not associated with any existing bindings.
`A subsequent request
`is one received that is associated with an existing binding.
`
`7.2.2
`
`Initial Requests
`
`A TURN server MUST be prepared to receive Binding Requests over TCP
`and UDP.
`The port on which to listen is based on the DNS SRV entries
`provided by the server. Typically,
`this will be XXXX,
`the default
`TURN port.
`
`The server MUST check the Allocate Request for a MESSAGE—INTEGRITY
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 10]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`the server generates a Allocate Error
`If not present,
`attribute.
`Response with an ERROR—CODE attribute with response code 401.
`
`the server checks for
`If the MESSAGE—INTEGRITY attribute was present,
`the existence of the USERNAME attribute.
`If it was not present,
`the
`server MUST generate a Allocate Error Response.
`The Allocate Error
`Response MUST include an ERROR—CODE attribute with response code 432.
`
`the server computes the HMAC over the
`If the USERNAME is present,
`request as described in Section 11.2.8 of STUN.
`The key is equal to
`the password associated with the username in the request, where that
`username is a short term username allocated by the TURN server.
`The
`username MUST be one which has been allocated by the server in a
`Shared Secret Response, but has not yet been used to authenticate an
`Allocate request.
`If that username is not known by the server, or
`has already been used,
`the server generates an Allocate Error
`Response. That response MUST include an ERROR—CODE attribute with
`response code 430.
`
`If the computed HMAC differs from the one from the MESSAGE—INTEGRITY
`attribute in the request,
`the server MUST generate a Allocate Error
`Response with an ERROR—CODE attribute with response code 431.
`
`Assuming the message integrity check passed, processing continues.
`The server MUST check for any attributes in the request with values
`less than or equal to 0x7fff which it does not understand.
`If it
`encounters any,
`the server MUST generate an Allocate Error Response,
`and it MUST include an ERROR—CODE attribute with a 420 response code.
`
`That response MUST contain an UNKNOWN—ATTRIBUTES attribute listing
`the attributes with values less than or equal to Ox7fff which were
`not understood.
`
`the Allocate Error Response
`If the Allocate request arrived over TCP,
`is sent on the connection from which the request arrived.
`If the
`Allocate request arrived over UDP,
`the Allocate Error Response is
`sent to the transport address from which the request was received
`(i.e.,
`the source IP address and port), and sent from the transport
`address on which the request was received (i.e.,
`the destination IP
`address and port).
`
`Assuming the Allocate request was authenticated and was well—formed,
`the server attempts to allocate transport addresses.
`It first looks
`for the BANDWIDTH attribute for the request.
`If present,
`the server
`determines whether or not it has sufficient capacity to handle a
`the
`binding that will generate the requested bandwidth.
`If it does,
`server attempts to allocate a port for the client.
`The server MUST
`NOT allocate ports from the well—known port range (0-1023) and MUST
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 11]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`NOT allocate ports from the user registered port range (1024 through
`49151).
`
`If a port meeting the bandwidth constraints cannot be allocated,
`server MUST generate a Allocate Error Response that includes an
`ERROR—CODE attribute with a response code of 300. That response MAY
`include an ALTERNATE—SERVER attribute pointing to an alternate server
`which can be used by the client.
`
`the
`
`the server creates a binding for it.
`Once the port is allocated,
`This binding is a mapping between two five—tuples —
`the allocate
`five—tuple and the remote five-tuple.
`The allocate five—tuple is set
`to the five—tuple of the Allocate Request (that is,
`the protocol of
`the allocate five—tuple is set to the protocol of the Allocate
`Request
`(TCP or UDP),
`the source IP address and port of the allocate
`five—tuple are set to the source IP address and port in the Allocate
`Request, and the destination IP address and port of the allocate
`five—tuple are set to the destination IP address and port in the
`Allocate Request).
`The protocol in the remote five—tuple is set to
`the protocol
`from the Allocate Request.
`The source IP address of the
`remote five—tuple is set to the interface from which the port was
`allocated.
`The source port of the remote five—tuple is set to the
`allocated port.
`If the binding was allocated for TCP,
`the connection
`on which the Allocate request was received is associated with the
`allocate five—tuple in the binding.
`
`The server MUST remember the one—time username and password used to
`obtain the binding.
`
`If the LIFETIME attribute was present in the request, and the value
`is larger than the maximum duration the server is willing to use for
`the lifetime of the binding,
`the server MAY lower it to that maximum.
`However,
`the server MUST NOT increase the duration requested in the
`LIFETIME attribute.
`If there was no LIFETIME attribute,
`the server
`may choose a default duration at its discretion.
`In either cae,
`the
`resulting duration is added to the current time, and a timer is set
`to fire at or after that time. Section 7.5 discusses behavior when
`the timer fires.
`
`Once the port has been obtained from the operating system and the
`activity timer started for the port binding,
`the server generates an
`Allocate Response.
`The Allocate Response MUST contain the same
`transaction ID contained in the Allocate Request.
`The length in the
`message header MUST contain the total length of the message in bytes,
`excluding the header.
`The Allocate Response MUST have a message type
`of "Allocate Response".
`
`The server MUST add a MAPPED—ADDRESS attribute to the Allocate
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 12]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`The IP address component of this attribute MUST be set to
`Response.
`the interface from which the base port was allocated.
`The port
`component of this attribute MUST be set to the base port.
`
`The server MUST add a LIFETIME attribute to the Allocate Response.
`This attribute contains the duration,
`in seconds, of the activity
`timer associated with this binding.
`
`The server MUST add a BANDWIDTH attribute to the Allocate Response.
`This MUST be equal to the attribute from the request,
`if one was
`present. Otherwise, it indicates a per—binding cap that the server
`is placing on the bandwidth usage on each binding.
`Such caps are
`needed to prevent against denial—of—service attacks (See Section 10.
`
`The server MUST add, as the final attribute of the request, a
`MESSAGE—INTEGRITY attribute.
`The key used in the HMAC MUST be the
`same as that used to validate the request.
`
`If the Allocate request was
`The TURN server then sends the response.
`received over TCP,
`the response is sent over that TCP connection.
`If
`the Allocate request was received over UDP,
`the response is sent to
`the transport address from which the request was received (i.e.,
`the
`source IP address and port), and sent from the transport address on
`which the request was received (i.e.,
`the destination IP address and
`port).
`
`the server MUST be prepared to receive a TCP
`If the port was for TCP,
`connection request on that port.
`
`7.2.3 Subsequent Requests
`
`Once a binding has been created for UDP and permissions installed,
`the client can send subsequent Allocate requests to the TURN server.
`To determine which packets are for the TURN server, and which need to
`be relayed,
`the server looks at the packet.
`If the packet is shorter
`than 28 bytes, it is not a TURN request.
`If it is longer than 28
`bytes,
`the server checks bytes 25—28.
`If these bytes are equal to
`the MAGIC—COOKIE,
`the request is a TURN request. Otherwise, it is a
`data packet, and is to be relayed.
`
`The server first authenticates the request. This is done as in
`Section 7.2.2.
`The request MUST be authenticated using the same
`one—time username and password used to allocate that binding
`previously. That is,
`the five—tuple from the Allocate request is
`compared to the allocate five—tuples in existing bindings.
`The
`matching binding is selected.
`The one—time username and password
`associated with that binding MUST match the ones used in the request.
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 13]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`The server looks for the LIFETIME attribute in the Allocate Request.
`If not found, it determines the default refresh duration,
`in seconds,
`for this binding.
`If the LIFETIME attribute was present
`in the
`request, and the value is larger than the maximum duration the server
`is willing to extend the lifetime of the binding,
`the server MAY
`lower it to that maximum. However,
`the server MUST NOT increase the
`duration requested in the LIFETIME attribute.
`The resulting duration
`is added to the current time, and the activity timer for this binding
`is reset to fire at or after that time. Section 7.5 discusses
`behavior when the timer fires.
`
`the server MUST generate an Allocate Response.
`Once the timer is set,
`The Allocate Response MUST contain the same transaction ID contained
`in the Allocate Request.
`The length in the message header MUST
`contain the total length of the message in bytes, excluding the
`header.
`The Allocate Response MUST have a message type of "Allocate
`Response".
`The response MUST contain a MAGIC—COOKIE as the first
`attribute.
`It MUST contain a MAPPED—ADDRESS which contains the
`source IP address and port from the remote five—tuple of the binding.
`It MUST contain a LIFETIME attribute which contains the time from now
`until the point at which the binding will be deleted.
`The final
`attribute MUST be a MESSAGE—INTEGRITY attribute, which MUST use the
`same one—time username and password used to authenticate the request.
`
`The response is sent to the
`The TURN server then sends the response.
`transport address from which the request was received (i.e.,
`the
`source IP address and port), and sent from the transport address on
`which the request was received (i.e.,
`the destination IP address and
`port).
`
`7.3
`
`Send Request
`
`In order for the TURN server to relay packets to and from the client,
`it must be "primed" with one of more Send requests.
`These requests
`are used with UDP, and carry a data payload.
`In addition,
`they
`contain a destination IP address and port.
`A Send Request is like
`any other TURN request.
`A server can disambiguate a Send Request
`from a data packet by looking for the MAGIC—COOKIE attribute, as
`described in Section 7.2.3.
`
`Once the server has identified a request as a Send request,
`server verifies that it has arrived with a source five—tuple
`corresponding to an existing allocation.
`If there is no matching
`allocation,
`the server MUST generate a 437 (No Binding) Send Error
`Response.
`
`the
`
`the server authenticates the request. This is done as in
`Next,
`Section 7.2.2.
`The request MUST be authenticated using the same
`
`Rosenberg, et al.
`
`Expires August 22, 2005
`
`[Page 14]
`
`
`
`
`
`Internet—Draft
`
`TURN
`
`February 2005
`
`one—time username and password used to allocate that binding
`previously. That is,
`the five—tuple from the Send request is
`compared to the allocate five—tuples in existing bindings.
`The
`matching binding is selected.
`The one—time username and password
`associated with t