wdiff draft-rosenberg-midcom-turn-00.txt draft-rosenberg-midcom-turn-01.txt

Internet Engineering Task Force
MIDCOM WG
Internet Draft Rosenberg,Weinberger,Huitema,Mahy
draft-rosenberg-midcom-turn-00.txt dynamicsoft,Microsoft,Cisco
November 14, 2001 J. Rosenberg
Internet-Draft J. Weinberger
Expires: September 1, 2003 dynamicsoft
R. Mahy
Cisco Systems
C. Huitema
Microsoft
March 2002 3, 2003

Traversal Using Relay NAT (TURN)

STATUS OF THIS MEMO
draft-rosenberg-midcom-turn-01

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

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.

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". progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

To view the http://
www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories, see Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 1, 2003.

Abstract

Traversal Using Relay NAT (TURN) is a simple protocol that allows for an
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 connection to
a single peer. TURN does not allow for users to run 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" ``turn'' the tables so that the element on the
inside can be on the receiving end, rather than the sending end, of a
connection that is requested by the client.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . . 7
5. Overview of Operation . . . . . . . . . . . . . . . . . . . 8
6. Message Overview . . . . . . . . . . . . . . . . . . . . . . 10
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . 11
7.1 Shared Secret Request . . . . . . . . . . . . . . . . . . . 11
7.2 Allocate Request . . . . . . . . . . . . . . . . . . . . . . 13
7.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.2 Initial Requests . . . . . . . . . . . . . . . . . . . . . . 13
7.2.3 Requests for Pre-Allocated Ports . . . . . . . . . . . . . . 17
7.2.4 Subsequent Requests . . . . . . . . . . . . . . . . . . . . 18
7.3 Receiving Packets and Connections . . . . . . . . . . . . . 19
7.4 Lifetime Expiration . . . . . . . . . . . . . . . . . . . . 20
8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . 22
8.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2 Obtaining a One Time Password . . . . . . . . . . . . . . . 22
8.3 Allocating a Binding . . . . . . . . . . . . . . . . . . . . 23
8.4 Processing Allocate Responses . . . . . . . . . . . . . . . 24
8.5 Allocating a Pre-Allocated Binding . . . . . . . . . . . . . 25
8.6 Refreshing a Binding . . . . . . . . . . . . . . . . . . . . 26
8.7 Tearing Down a Binding . . . . . . . . . . . . . . . . . . . 26
8.8 Receiving and Sending Data . . . . . . . . . . . . . . . . . 26
9. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 27
9.1 Message Types . . . . . . . . . . . . . . . . . . . . . . . 27
9.2 Message Attributes . . . . . . . . . . . . . . . . . . . . . 27
9.2.1 TRANSPORT-PREFERENCES . . . . . . . . . . . . . . . . . . . 27
9.2.2 LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2.3 ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . . . 28
9.2.4 MAGIC-COOKIE . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2.5 BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.3 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . 30
11. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 32
11.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . 32
11.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . 32
11.3 Brittleness Introduced by TURN . . . . . . . . . . . . . . . 33
11.4 Requirements for a Long Term Solution . . . . . . . . . . . 34
11.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . . 34
12. Requirements Analysis . . . . . . . . . . . . . . . . . . . 35
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Normative References . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . 40

1. 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. Guidlines Guidelines [9] have been
developed [1] that describe how to build "NAT friendly" protocols, but
many protocols simply cannot be constructed according to those
guidelines. Examples of such protocols include almost all peer-to-
peer protocols, for example.

To handle this, we have documented the multimedia
applications and file sharing.

Simple Traversal of UDP Through NAT (STUN) protocol [2], which allows [1] provides one means for clients behind a
NAT to discover the presence of the NAT, and then to allocate
an
address that is useful for receiving data in the case where they are
behind application to traverse a full-cone or restricted-cone NAT. However, it is
acknowledged in that draft that while STUN allows a client to
discover that its behind obtain a symmetric NAT, it provides no assistance
in traversing symmetric NATs.

This protocol serves as
transport address (and IP address and port) which may be useful for
receiving packets from a complement to STUN, handling peer. However, addresses obtained by STUN
may not be usable by all peers. Those addresses work depending on the case where
topological conditions of the user is behind network. Therefore, STUN by itself
cannot provide a symmetric NAT. It allows complete solution for NAT traversal.

A complete solution requires a means by which a client to request an
IP can obtain a
transport address and port that from which it can receive data on media from any other host
on peer which
can send packets to the public Internet. This is accomplished using a server in the service
provider cloud, known as a TURN server. When a host on the Internet
sends to this IP address and port, the TURN server creates an
association between the two. The client behind the NAT will receive
this, and any other subsequent data from that host. In addition, the
client behind the NAT can send data, and that data will only be forwarded
accomplished by the TURN server to the host which connected. TURN servers
purposefully support relaying data though a single association, so server that only a single host
can be connected using the IP address and port provided by resides on the turn
server.
public Internet. This assures that TURN can't be used to violate the policy
that symmetric specification describes Traversal Using Relay
NAT and firewalls are meant to enforce. All TURN does
is allow a client to communicate with a single peer whose address it
doesn't know ahead of time. TURN is not (TURN), a tunneling protocol, and
therefore does not allow for protocol that allows a user client to send obtain IP addresses
and receive UDP, if, for
example, the firewall policy prohibits the usage of UDP. Effectively, ports from such a relay.

Although TURN server is a NAT function at the UDP and TCP layer, and thus
the name of the protocol - its will almost always provide connectivity to a "relay NAT".

2 Do we need this Protocol?

Originally, the TURN protocol was integrated with the STUN protocol
documented in [2]. The authors yanked it out of that document because client, it solves a sufficiently different problem, with differing
requirements. We also observed that there are many other potential
solutions for the symmetric case, including RSIP [3] [4], and more
traditional VPN tunnels. We therefore had to ask ourselves why
another solution was needed in this space. Here are some of the
issues we came up with:

o RSIP and the VPN solutions all allocate an entire IP address
comes at high cost to the client. This means the provider must have sufficient IP
addresses for all the clients which would simultaneously need
service. This could require significant address space. With
this proposal, its an IP address/port thats allocated, which
means very few IP addresses are needed. This is of the standard
NAT argument.

o RSIP and VPN solutions all require tunneling. In this
proposal, there is no tunneling. The result is more efficient
bandwidth usage, which is important for media packets (RTP TURN server. It is
a likely user of this mechanism).

o RSIP and VPN solutions might contradict enterprise firewall
policy, allowing people to run servers,
therefore desirable to use UDP when only
TCP is allowed, and so on. Some would consider this a feature,
not a drawback. But, if the goal is consistency with IT
established policies, it is a drawback. Our proposal provides
a simple, minimalistic functionality that is consistent with
enterprise policy. The only feature TURN adds, is the ability
of as a user behind last resort only, preferring
other mechanisms (such as STUN or direct connectivity) when possible.
To accomplish that, the firewall/NAT Interactive Connectivity Establishment (ICE)
[13] methodology can be used to receive a single incoming
connection, which it has previously requested.

Whether these benefits outweigh discover the cost optimal means of developing and deploying
another protocol is important to consider further.

3
connectivity.

2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", MUST, MUST NOT, REQUIRED, SHALL,
SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and "OPTIONAL" OPTIONAL are to
be interpreted as described in RFC 2119 [5] [2] and indicate requirement
levels for compliant STUN TURN implementations.

3. Definitions

TURN Client: A TURN client (also just referred to as a client) is
an entity that generates TURN requests. A TURN client can be an
end system, such as a SIP Session Initiation Protocol (SIP) [6] User
Agent, or can be a network element, such as a Back-to-Back User
Agent (B2BUA) SIP server. The TURN protocol will provide the STUN
client with IP addresses that route to it from the public
Internet.

TURN Server: A TURN Server (also just referred to as a server) is
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.

5 Overview

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 Operation

/-----\
// 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].

When a client is behind a NAT, transport addresses obtained from the
local operating system will not be publically routable, and
therefore, not useful in these protocols. TURN \\
| Server |
\\ //
\-----/

+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+

+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+

/-----\
// 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 \\
| Client |
\\ // Private NET 1
\-----/

Figure 1: servers are not generally
useful for receiving data from anywhere. They are only useful for
communicating with a single peer. Once a host sends packets to that
transport address, it is ``locked down'', meaning that packets from
other hosts will not be forwarded to the client. This is done
purposefully, so as to prevent TURN from being used to run servers
(such as a web server) on a client behind a NAT. In this way,
enterprises which deploy NATs and firewalls to prevent users from
running servers, can be confident that TURN Configuration will not cause any
violations in their enterprise security policies.

5. Overview of Operation

The typical TURN configuration is shown in Figure 1. A TURN client 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.

/-----\
// TURN \\
| Server |
\\ //
\-----/

+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+

+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+

/-----\
// TURN \\
| Client |
\\ // Private NET 1
\-----/

Figure 1

TURN is a simple client-server protocol. There It is just identical in syntax
and general operation to STUN, in order to facilitate a joint
implementation of both. TURN defines a single 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 [6]. [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 digest mechanism for mutual authentication capability,
mirroring the operation of HTTP digest [7] that allows the server to
authenticate the client, and
integrity checks for the client to authenticate the
server. both requests and responses, based on a shared
secret. Assuming the request is authenticated, authenticated and has not been
tampered with, the TURN server remembers the source IP transport address and port
that the request came from (call this SA:SP), SA), and returns a public IP address and port, PA:PP,
transport address, PA, in the TURN response. This public address and port have The TURN server is
responsible for guaranteeing that packets sent to PA route to the
TURN server. The TURN server then waits for data on PA:PP. PA. When data is
received (either a UDP packet or a TCP connection request), the TURN
server accepts the connection (in the case of TCP), and then stores
the remote address and port where the data came from (RA:RP). (RA). The data
just received, if any, are then forwarded to SA:SP. SA. The TURN server then
acts as a relay. Any data received from SA:SP SA are forwarded to RA:RP. RA. Any
data sent from RA:RP RA to PA:PP PA are sent to
SA:SP. The SA.

For TCP, the TURN server does not need to examine the data received;
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.

TURN also allows a client to request an odd or even port when one is
allocated, and for it to pre-allocate the next higher port. This is
useful for securing consecutive ports for usage with the Real Time
Transport Protocol (RTP) [5].

6. Message Overview

TURN messages are TLV (type-length-value) encoded using big endian
(network ordered) binary. TURN messages are formatted identically identical to STUN messages, as it is expected that these protocols will frequently
be used together. messages in their syntax. TURN uses
defines three new messages - the MAPPED-ADDRESS attribute defined in STUN. This address
always appears in Allocate Request, the Allocate
Response, and the Allocate Error Response. TURN also defines a
CHALLENGE and an AUTHENTICATION attribute. They are very similar to uses the Shared
Secret Request, Shared Secret Response, and Shared Secret Error
Response defined by STUN. TURN makes use of some of the Authorization STUN
attributes (MAPPED-ADDRESS, USERNAME, MESSAGE-INTEGRITY, ERROR-CODE,
and WWW-Authenticate headers in RFC 2617 [7], UNKNOWN-ATTRIBUTES) and
convey also defines several of its own.
Specifically, TURN adds TRANSPORT-PREFERENCES attribute, which allows
a realm, nonce, username, client to request an odd or even port, and signature. Unlike HTTP Digest,
TURN authentication covers to pre-allocate the next
higher port. It defines the entire message.

A LIFETIME attribute indicates how long attribute, which allows the mapped address 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
Allocate response is valid for. The ALTERNATE-SERVER attribute in an
Allocate response indicates that attribute, which allows the allocation server was full, and to redirect
the TURN client to connect to an alternate should be used instead.

7 server.

7. Server Behavior

The server behavior depends on whether the request is a Shared Secret
Request or an Allocate Request.

7.1 Shared Secret Request

Unlike a STUN server, a TURN server generates provides resources to clients
that connect to it. Therefore, only authorized clients can gain
access to a single response when TURN server. This requires that TURN requests be
authenticated. TURN assumes the existence of a request 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 received
(assuming then used by the request 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.

Assuming it was, the server checks the Shared Secret Request for a
MESSAGE-INTEGRITY attribute. If not discarded). The present, the server generates a
Shared Secret Error Response with an ERROR-CODE attribute with
response code 401. That response MUST contain include a NONCE attribute,
containing a nonce that the same transaction ID contained in server wishes the request. The length client to reflect back
in a subsequent Shared Secret Request (and therefore include the
message header integrity computation). The response MUST contain include a REALM
attribute, containing a realm from which the total length username and password
are scoped [4].

If the MESSAGE-INTEGRITY attribute was present, the server checks for
the existence of the message in bytes,
excluding REALM attribute. If the header.

7.1 Client Authentication

The request can be authenticated. This attribute is done using not
present, the server MUST generate a challenge- Shared Secret Error Response.
That response mechanism. When MUST include an ERROR-CODE attribute with response code
434. That response MUST include a request is received without proper
credentials (which are present in NONCE and a REALM attribute.

If the AUTHENTICATION attribute), REALM attribute was present, the server MAY checks for the
existence of the NONCE attribute. If the NONCE attribute is not
present, the server MUST generate a challenge response. A challenge Shared Secret Error Response.
That response MUST
NOT contain any attributes except the CHALLENGE attribute. This include an ERROR-CODE attribute contains with response code
435. That response MUST include a realm NONCE attribute and a nonce. The usage REALM
attribute.

If the NONCE attribute was present, the server checks for the
existence of the realm USERNAME attribute. If it was not present, the
server MUST generate a Shared Secret Error Response. The Shared
Secret Error Response MUST include an ERROR-CODE attribute with
response code 432. It MUST include a NONCE attribute and
nonce a REALM
attribute.

If the USERNAME is identical to their usage in responses for Digest
authentication to HTTP requests, present, the server computes the HMAC over the
request as described in RFC 2617 [7]. Section 11.2.8 of STUN. The client, upon receiving this challenge, can generate a new
request, this time key is computed
as MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" passwd), where
the password is the password associated with an AUTHENTICATION attribute, which reflects the nonce username and realm back to
provided in the server, and contains request. If the server does not have a keyed hash
over record for
that username within that realm, the message using 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 user's name key was chosen so as to enable a common
authentication database for SIP and password. When this for TURN, as it is
received at expected
that credentials are usually stored in their hashed forms. [[OPEN
ISSUE: Is support of MD5-sess needed?]]

If the server, computed HMAC differs from the server validates one from the AUTHENTICATION
attribute. 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 is done by computing response MUST include a NONCE attribute and a REALM attribute.

If the computed HMAC doesn't differ from the keyed hash one in the same way request, but
the client does, 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 comparing a
REALM attribute.

In all cases, the results. If there Shared Secret Error Response is a match, sent over the TLS
connection on which the Shared Secret Request was received.

The server considers proceeds to authorize the request authenticated. Otherwise, if it fails, client. The means for
authorization are outside the server SHOULD proceed scope of this specification. It is
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 AUTHENTICATION attribute where
not present, typically resulting in another challenge.

7.2 Server Authentication application service.

The client can demand authentication 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 server. To do this, it
includes client as a CHALLENGE attribute short-term shared secret in the request. When subsequent
Allocate requests. Note that STUN specifies that the server
receives this, assuming that 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
request, result was an Allocate Error Response, the response contains (in addition to username
and password are discarded. If the other attributes)
an AUTHENTICATION attribute. A TURN Server MUST NOT include result was an
AUTHENTICATION attribute Allocate Response,
resulting in the creation of a response, if new binding, the server did not
successfully username and password
become associated with that binding. They can only be used to
authenticate Allocate requests sent from the client same source transport
address in order to refresh or de-allocate that binding. Once the corresponding request.
This attribute contains a hash of the message contents,
binding is deleted, the nonce, 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 shared secret between the client and TURN server.

7.3 Allocation
Allocation

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.

When To do this,
a client is behind TURN server allocates a symmetric NAT, the IP address local transport address, and port passes it
obtains from the Allocate response cannot be used to receive packets
from any host on the Internet. Only the recipient of the request can
send packets to
the client at in an Allocate Response. When the mapped address. Unfortunately, server receives packets
on this
is therefore limited to allocated address, it acts as a relay, and forwards them
towards the server that received source of the TURN Allocate request.
Therefore, the The server acts as an intermediary. It returns its own IP remembers the
source transport address where that packet came from, and a free port in the response. "locks
down". This can be used by means that packets sent from the client in any applications it is running. Any packets received by to the TURN
server on that IP address and port are forwarded to the client. Since
the server is on the public Internet and not natted, anyone can send
to it. that address.

As a result, the server MUST maintain maintains a set of mappings. bindings. These
mappings 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.

When

The behavior of the server when receiving an authenticated Allocate Request depends
on whether the request is received, an initial one, or a partially
filled-in remote five-tuple subsequent one. An
initial request is constructed. This remote five-tuple
consists of the same protocol as the five-tuple from the Allocate
request, and one received with a destination IP source transport address and port which
is not associated with any existing bindings. A subsequent request is
one received that route to the is associated with an existing binding.

7.2.2 Initial Requests

A TURN
server. This IP address server MUST be prepared to receive Binding Requests over TCP
and UDP. The port from the remote five-tuple on which to listen is known
as based on the mapped address. The mapped address is returned to DNS SRV entries
provided by the client
in server. Typically, this will be XXXX, the default
TURN response, using port. [[OPEN ISSUE: Can we just use the MAPPED-ADDRESS attribute. STUN port?]].

The address
and port in the MAPPED-ADDRESS attribute server MUST NOT correspond to an
address and port already present in another remote five-tuple.
Effectively, it is check the Allocate Request for a new address and port that is allocated to MESSAGE-INTEGRITY
attribute. If not present, the
client, and thus server generates a Allocate Error
Response with an ERROR-CODE attribute with response code 401.

If the name MESSAGE-INTEGRITY attribute was present, the server checks for
the existence of the request. Of course, USERNAME attribute. If it is possible
that there are no more address/port pairs available, due to depleted
resources. In that case, was not present, the
server SHOULD MUST generate a response that Allocate Error Response. The Allocate Error
Response MUST NOT contain a MAPPED-ADDRESS attribute. Instead, it MAY contain
an ALTERNATE-SERVER attribute, which contains the address and port of include an alternate server. ERROR-CODE attribute with response code 432.

If the ALTERNATE-SERVER attribute USERNAME is not present, the client will instead use DNS procedures, server computes the HMAC over the
request as described below,
to find an alternate. in Section 11.2.8 of STUN. The TURN server MUST listen for packets on key is equal to
the MAPPED-ADDRESS, using password associated with the protocol username in the remote five-tuple. When a packet request, where that
username is received, a short term username allocated by the
source IP address and port of that packet 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 fill in authenticate an
Allocate request. If that username is not known by the
remaining two fields in server, or has
already been used, the remote five-tuple. In server generates an Allocate Error Response.
That response MUST include an ERROR-CODE attribute with response code
430.

If the case of TCP, computed HMAC differs from the one from the MESSAGE-INTEGRITY
attribute in the request, the TURN server MUST accept the TCP connection. In generate a Allocate Error
Response with an ERROR-CODE attribute with response code 431.

Assuming the case of UDP, message integrity check passed, processing continues.
The server MUST check for any data present attributes in the packet MUST be forwarded request with values
less than or equal to 0x7fff which it does not understand. If it
encounters any, the source
address and port of the allocate five-tuple, server MUST generate an Allocate Error Response,
and it MUST be 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 0x7fff which were
not understood.

If the Allocate request arrived over TCP, the Allocate Error Response
is sent on the connection from which the destination address and port of request arrived. If the allocate five-tuple, using
Allocate request arrived over UDP, the protocol of Allocate Error Response is
sent to the five-tuple.

From then on, any packets transport address from which the request was received on
(i.e., the MAPPED-ADDRESS, with a source IP address and port matching port), and sent from the source transport
address on which the request was received (i.e., the destination IP
address and port of port).

Assuming the remote
tuple, MUST have their data forwarded to Allocate request was authenticated and was well-formed,
the server attempts to allocate five-tuple in transport addresses. It first looks
for the same fashion described above. In BANDWIDTH attribute for the case of TCP, any other
connection requests request. If present, the server
determines whether or not it has sufficient capacity to handle a
binding that will generate the MAPPED-ADDRESS MUST be refused.

In requested bandwidth. If so, the case server
looks for the presence of TCP, if either connection (the one associated with the TRANSPORT-PREFERENCES attribute in the
request. If the attribute indicates that an even port is requested,
the server attempts to allocate five-tupe or a transport address with an even
port. If the one associated attribute indicates that an odd port is requested, the
server attempts to allocate a transport address with an odd port. If
the remote five-tuple) attribute indicates that there is closed, no preference for port parity,
or if the TURN TRANSPORT-PREFERENCES attribute was absent, the server
attempts to allocate a port with either parity. The server MUST close NOT
allocate ports from the other connection, well-known port range (0-1023) and
destroy MUST NOT
allocate ports from the mapping between user registered port range (1024 through
49151).

This aspect of the tuples. protocol helps guarantee that users cannot run
servers (such as a web server, SIP server, or SMTP server) using
TURN.

The TURN server SHOULD maintain an activity timer TRANSPORT-PREFERENCES attribute can also indicate a preference
for the mapping. a specific port, pre-allocated previously by a prior Allocate
request. This timer fires after case is described in Section 7.2.3.

If a configurable amount port meeting the constraints (including bandwidth) cannot be
allocated, the server MUST generate a Allocate Error Response that
includes an ERROR-CODE attribute with a response code of time (called 300. That
response MAY include an ALTERNATE-SERVER attribute pointing to an
alternate server which can be used by the
lifetime) has expired without data having been received from either
five-tuple. When client.

Assuming a port was allocated according to the preferences (call this timer fires, both connections are closed (in
the TCP case), base port), the server checks to see if the TRANSPORT-PREFERENCES
attribute is present, and indicates a desire to pre-allocate the mapping between next
higher port (called the tuples MUST be destroyed. pre-allocated port). If so, the TURN server is using activity timers,
attempts to allocate that port from its local operating system. If it MUST include the
lifetime interval in
cannot be allocated, the LIFETIME attribute server can do one of the original Allocate
request.

OPEN ISSUE: Might be nice two things. First, it
MAY try to request allocate a lifetime different base port, in the
Allocate request. TURN could be used for very long lived
associations, such as a connection between a user and its
proxy. Asking for a long one in hopes that case (only useful for
TCP) would be a good thing. the next
higher port is available. If the TURN server receives data on believes that there are no
adjacent ports meeting the Allocate tuple before parity constraints present in the
remote-tuple has been filled in, request,
the TURN server MUST treat MAY generate an Allocate Error Response that data
as includes an
ERROR-CODE attribute with a TURN request. This means it will be responded response code of 300. That response MAY
include an ALTERNATE-SERVER attribute pointing to as an alternate server
which can be used by the original
request, providing client.

Once a base port is allocated, the same MAPPED-ADDRESS once more. server creates a binding for it.
This binding is needed
for reliability purposes.

8 Client Behavior

The behavior of a mapping between two five-tuples - the client is very simple. Its main task allocate
five-tuple and the remote five-tuple. The allocate five-tuple is set
to
discover the TURN server, formulate the request, and handle request
reliability.

8.1 Discovery

Generally, the client will be configured with a domain name five-tuple of the
provider Allocate Request (that is, the protocol of
the TURN servers. This domain name allocate five-tuple is resolved set to an the protocol of the Allocate
Request (TCP or UDP), the source IP address and port of using the SRV procedures specified in [6]. The
service name is "turn". The protocol can be either "udp" or "tcp".

There is no reason at all that a turn server couldn't also
make use of SCTP.

The procedures of RFC 2782 allocate
five-tuple are followed to determine the server set to
contact, with the following additions. If an attempt is made to
contact a server, source IP address and that attempt results port in an ICMP error, or no
response with 30 seconds, the client SHOULD attempt to contact the
next server. Furthermore, if the client is trying to contact a
server, Allocate
Request, and a server was contacted, but the response did not contain
a MAPPED-ADDRESS or ALTERNATE-SERVER attribute, destination IP address and port of the client SHOULD
attempt allocate
five-tuple are set to contact the next server.

The default port for TURN requests is [to be assigned by IANA].
Administrators SHOULD use this destination IP address and port in their SRV records, but MAY use
others.

This would allow a firewall admin to open the TURN port, so
hosts within
Allocate Request). The protocol in the enterprise could access new applications.
Whether they will or won't do this remote five-tuple is a good question.

8.2 Authentication

A request formulated by the client follows the syntax rules defined
in Section 10. Any two requests that are not bit-wise identical, or
not sent set to
the same server protocol from the same Allocate Request. The source IP address and port, MUST
carry different transaction IDs. The transaction ID MUST be uniformly
and randomly chosen between 0 and 2^^32 - 1.

Once formulated, the client sends of the request. Reliability
remote five-tuple is
accomplished through client retransmissions. Clients SHOULD
retransmit set to the request starting with an interval of 100ms, doubling
every retransmit. interface from which the base port
was allocated. The client MAY give up after 32 seconds, or MAY
continue trying. source port of the remote five-tuple is set to the
base port. If the response contains a CHALLENGE attribute, binding was allocated for TCP, the client formulates
a new request (with a new transaction ID), but otherwise identical to connection on
which the previous request, Allocate request was received is associated with the addition of
allocate five-tuple in the AUTHENTICATION
attribute. binding.

The realm server MUST remember the one-time username and nonce fields of this attribute are copied
from password used to
obtain the response. binding.

If a port was pre-allocated, a binding is also created for it. The username
allocate five-tuple is left empty. The protocol in the user's identity at remote
five-tuple is set to the given
realm. protocol from the Allocate Request. The signature is computed as described in Section 10.2.2.

A request with an AUTHENTICATION attribute MAY also contain a
CHALLENGE attribute, requesting authentication
source IP address of the server.

A client MAY cache remote five-tuple is set to the realm and nonce fields interface
from which the response, and
use them pre-allocated port was allocated. The source port of
the remote five-tuple is set to construct the AUTHENTICATION attribute pre-allocated port. The identity
of the user (defined as the username provided in subsequent
requests the Shared Secret
Request used to obtain the same TURN server (identified by one-time password used in the destination IP
address and port).

8.3 Allocate request

An Allocate request has
Request) is associated with this pre-allocated tuple. Only that user
can perform an allocation for this tuple. Furthermore, a timer is
set. If no mandatory attributes, and allocation is made against this pre-allocation within 5
minutes, the only
optional attributes are AUTHENTICATION port is released and CHALLENGE, whose usage the binding is
described above. deleted.

If the response contains an ALTERNATE-SERVER attribute, LIFETIME attribute was present in the client
SHOULD formulate a new Allocate request, and send 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 server.
Otherwise, if maximum.
However, the server MUST NOT increase the duration requested in the
LIFETIME attribute. If there is no ALTERNATE-SERVER attribute, but was no MAPPED-
ADDRESS LIFETIME attribute, the client SHOULD continue SRV procedures from server
may choose a default duration at its discretion. In either cae, the
point it left off
resulting duration is added to find the next available server.

Otherwise, the response will contain current time, and a MAPPED-ADDRESS attribute with
an IP address timer is set
to fire at or after that time. Section 7.4 discusses behavior when
the timer fires.

Once the base port has been obtained from the operating system, the
pre-allocated port obtained, and the activity timer started for the
base port that binding, the client can use within server generates an application. Allocate Response. The response will also
Allocate Response MUST contain a LIFETIME attribute, which indicates
amount of time until the mapping will be invalidated. same transaction ID contained in
the Allocate Request. The TURN client should listen for data on length in the same socket used to
send message header MUST contain
the total length of the message in bytes, excluding the header. The
Allocate address. Any data sent Response MUST have a message type of "Allocate Response".

The server MUST add a MAPPED-ADDRESS attribute to the MAPPED-ADDRESS will
show up on Allocate
Response. The IP address component of this socket. Once it receives data, the client can send
data, and it will attribute MUST be delivered set to
the same host and port interface from which sent
the data to the MAPPED-ADDRESS.

9 Example Usage

9.1 UDP Allocation

Figure 2 shows the process of allocating a request for receipt base port was allocated. The port
component of UDP
packets.

In message 1, this attribute MUST be set to the client sends base port.

The server MUST add a TURN Allocate request LIFETIME attribute to the server. Allocate Response.
This passes through attribute contains the NAT, which rewrites duration, in seconds, of the source address
(message 2). activity
timer associated with this binding.

The TURN server allocates MUST add a MAPPED-ADDRESS,
9.8.7.6:1124, and returns it in BANDWIDTH attribute to the TURN response (message 3). Allocate Response.
This
response has its destination rewritten by MUST be equal to the NAT (message 4). The
client can then use this information in an application, such as SIP
[8], and attribute from the result is request, if one was
present. Otherwise, it indicates a per-binding cap that the address server is passed to some other
element (message 5), called
placing on the peer. The peer then decides bandwidth usage on each binding. Such caps are needed
to send
data prevent against denial-of-service attacks (See Section 10.

The server MUST add, as the final attribute of some sort (perhaps RTP packets), to the client. It sends it
to request, a
MESSAGE-INTEGRITY attribute. The key used in the mapped address, 9.8.7.6:1124, which will arrive at HMAC MUST be the
same as that used to validate the request.

The TURN server and then is forwarded to the client. Any data the client sends
is then forwarded back to the peer.

9.2 Authentication
TURN NAT Turn
Client Server
| | |
| response. If the Allocate |
| with CHALLENGE |
|-------->|--------->|
| | |
| Response with |
| CHALLENGE |
|<--------|<---------|
| | |
| request was
received over TCP, the response is sent over that TCP connection.
Once the response is sent, the TURN server begins acting as a relay
for that connection (see Section 7.3). If the Allocate with |
| CHALLENGE 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 |
| AUTHENTICATION |
|-------->|--------->|
| | | <-- TURN Server now waiting
| Response with |
port), and sent from the transport address on MAPPED-ADDRESS
| AUTHENTICATION which the request was
received (i.e., the destination IP address and |
| MAPPED-ADDRESS |
| | X <-----| Packet Loss
| | |
| .. client waits .. |
| | |
| port).

Additionally, if the base port was for UDP, the server MUST be
prepared to receive UDP packets once the TURN response is sent. If
the base port was for TCP, the server MUST be prepared to receive a
TCP connection request on that port. Behavior when either occurs is
described in Section 7.3.

7.2.3 Requests for Pre-Allocated Ports

The TRANSPORT-PREFERENCES attribute of the Allocate with |
| CHALLENGE Request can
indicate a desire to allocate a port that was previously
pre-allocated by a prior Allocate request. If such an indication is
present, the server checks that this port has been pre-allocated by a
previous Allocate Request. The only user authorized to allocate a
pre-allocated address is the same one that generated the
pre-allocation. Note that the one-time usernames for both requests
(the pre-allocation and |
| AUTHENTICATION |
|-------->|--------->|
| | |
| Response the final allocation) will be different.
However, both MUST have been obtained through Shared Secret Requests
authenticated as being sent from the same user.

If the Allocate request arrives on a different protocol than was used
to make the pre-allocation, the server MUST send an Allocate Error
Response. That response MUST contain an ERROR-CODE attribute with |
| AUTHENTICATION and |
| MAPPED-ADDRESS |
|<--------|----------|
| | |

Figure 3: Flow a
response code of 400.

Assuming the requested port has been pre-allocated by the same user,
the server completes the allocation by setting the allocate
five-tuple for mutual authentication

Figure 3 shows the basic flow binding to be equal to that of the Allocate
request. The server sets the activity timer for mutual authentication. this binding, and
generates an Allocate Response. This response MUST contain a
MAPPED-ADDRESS attribute which contains the interface from which the
pre-allocated port was obtained, along with the pre-allocated port.
The response MUST contain a LIFETIME attribute and a
MESSAGE-INTEGRITY attribute as well.

7.2.4 Subsequent Requests

Once a binding has been created, packets received from the client
sends are
generally forwarded to the remote client. However, if the binding is
UDP, 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.

Any TRANSPORT-PREFERENCE attribute in the request is ignored. An
Allocate Request sent to an existing binding is always a challenge. refresh or
deallocation. The server wishes 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.4 discusses behavior when the timer fires.

Once the timer is set, the server MUST generate 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 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 client, so request.

The TURN server then sends the response. If the Allocate request was
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).

7.3 Receiving Packets and Connections

If a TURN server receives a TCP connection request on a port it responds has
allocated, the server retrieves the binding whose remote five-tuple
has a source address and source port that match the IP address and
port to which the connection was made, and whose transport is TCP. If
the destination IP address and port of the remote five-tuple in the
binding are already filled in (which means that a connection was
already made to this tuple), the connection request is rejected.
Otherwise, it is accepted. If the connection is accepted, the server
MUST set the destination IP address and port of the remote five-tuple
to the source IP address and port in the SYN packet. It also
associates this connection with its own challenge, but
no authentication attribute. the remote five-tuple.

If a TURN server receives a UDP packet on a port it has allocated,
the server retrieves the binding whose remote five-tuple has a source
address and source port that match the IP address and port to which
the connection was made, and whose transport is UDP. If the
destination IP address and port of the remote five-tuple in the
binding are already filled in, and do not match the source IP address
and port of the UDP packet, the server drops the packet and MAY
generate a port unreachable ICMP error. If the packet was not
discareded, it is forwarded. To forward, the packet is sent with a
source IP address and port equal to the destination IP address and
port in the allocate five-tuple, and with a destination address and
port equal to the source IP address and port in the allocate
five-tuple. If the destination address and port of the remote
five-tuple were not filled in, they are populated at this time. The client retries
server MUST set the request, once
again destination IP address and port of the remote
five-tuple to the source IP address and port in the UDP packet.

The process of filling in the destination IP address and port of the
remote five-tuple is called "locking down". Once done, the client can
only send and receive packets with the specific peer from which the
first packet or connection was received.

If a challenge attribute TURN server receives a UDP packet on a port it has allocated,
the server retrieves the binding whose remote five-tuple has a source
address and also source port that match the IP address and port to which
the connection was made, and whose transport is UDP. If the
destination IP address and port of the remote five-tuple in the
binding are already filled in, and they match the source IP address
and port of the UDP packet, the server MUST forward the UDP packet as
above.

If a TURN server receives data on a TCP connection that was opened to
a port it had allocated, the server MUST forward this data onto the
connection associated with allocate-tuple in the binding.

If a TURN server receives data on a TCP connection that is associated
with an authentication
attribute. The allocate five-tuple, the binding for that tuple is retrieved.
If the destination IP address and port of that tuple have not been
filled in yet, the data is discarded. If the destination address and
port have been filled in, the connection associated with the remote
five-tuple is obtained, and the data is forwarded on that connection.

Note that, because data is forwarded blindly across TCP bindings, TLS
will successfully operate over a TURN allocated TCP port.

Similarly, if a TURN server accepts this, receives a UDP packet on one of its
public TURN ports, it checks to see if the source IP address and sends port
match those of the allocate five-tuples in an existing binding. If
there is a response match, the the UDP packet is not a TURN request (see
Section 7.2.4 for details on how this determination is made), the
destination IP address and port in the remote five-tuple of the
binding are checked. If they are not filled in yet, the UDP packet is
discarded. If they are, the packet is forwarded. It is forwarded
using the source IP address and port from the remote five-tuple, and
a destination IP address and port from the remote five-tuple.

If a TCP connection associated with an allocate five-tuple is closed,
the connection associated with the corresponding remote five-tuple is
also closed. At that point, the binding is destroyed. Similarly, if
the TCP connection associated with a remote five-tuple is closed, the
connection associated with the corresponding allocate five-tuple is
closed, and the binding is destroyed.

7.4 Lifetime Expiration

When the activity timer for a binding fires, the server checks to see
if there has been any activity on the binding since its own
authentication attribute, creation, or
since the last firing of the timer, whichever is more recent.
Activity is defined as connection establishment, or packet
transmission in either direction. If there has been activity, the
timer is set to fire once again in M seconds, where M is the value of
the LIFETIME attribute returned in the most recent Allocate Response
for this binding.

If there has been no activity, the server MUST destroy the binding,
along with its associated one-time password. If the mapped address. A retransmit binding was over
TCP, the server MUST close any connections it is holding to the
client and to the remote client.

Client behavior is broken into several separate steps. First, the
client obtains a one-time username and password. Secondly, it
generates initial Allocate | |
|------------------>| src=1.2.3.4:6544 | |
| | dest=9.8.7.6:8765 | |
| |------------------>| |
| |(3) Response | |
|(4) Response | mapped=9.8.7.6:1124, src=9.8.7.6:8765 |
| mapped=9.8.7.6:1123 dest=1.2.3.4:6544 | |
| src=9.8.7.6:8765 |<------------------| |
| dest=10.0.1.1:8898| | |
|<------------------| | |
| | | |
|(5) Sends 9.8.7.6:1124 to peer | |
|---------------------------------------------------------->|
| | | |
| | |(6) Data |
| | | src=5.5.5.5:5555 |
| |(7) Data | dest=9.8.7.6:1124 |
| | src=9.8.7.6:8765 |<------------------|
|(8) Data | dest=1.2.3.4:6544 | |
| src=9.8.7.6:8765 |<------------------| |
| dest=10.0.1.1:8898| | |
|<------------------| | |
| | | |
|(9) Data Response | | |
| src=10.0.1.1:8898 | | |
| dest=9.8.7.6:8765 |(10) Data Response | |
|------------------>| src=1.2.3.4:6544 |(11) Data Response |
| | dest=9.8.7.6:8765 | src=9.8.7.6:1124 |
| |------------------>| dest=5.5.5.5:5555 |
| | |------------------>|
| | | |

Figure 2: Example flow
of Requests, and processes the request triggers responses. It
manages those addresses (refreshing and tearing them down), and
processes data received on those addresses.

8.1 Discovery

Generally, the same response to client will be sent.

10 Protocol Details

This section presents configured with a domain name of the detailed encoding
provider of the attributes which TURN servers. This domain name is resolved to an IP
address and port of using the SRV procedures [3]. When sending a
Shared Secret request, the service name is "turn" and the protocol is
"tcp". RFC 2782 spells out the details of how a set of SRV records
are new sorted and then tried. However, it only states that the client
should "try to connect to the (protocol, address, service)" without
giving any details on what happens in the event of failure. Those
details are described here for TURN. The general message structure

For TURN requests, failure occurs if there is a transport failure of
some sort (generally, due to fatal ICMP errors in UDP or connection
failures in TCP). Failure also occurs if the the request does not
solicit a response after 9.5 seconds. If a failure occurs, the client
SHOULD create a new request, which is identical to STUN
[2].

10.1 Message Header the previous, but
has a different transaction ID and MESSAGE-INTEGRITY attribute. That
request is sent to the next element in the list as specified by
RFC~2782.

8.2 Obtaining a One Time Password

In order to allocate addresses, a client must obtain a one-time
username and password from the TURN defines two new Message Types:

0x0002 : Allocate Request
0x0102 : Allocate server. A unique username and
password are required for each distinct address allocated from the
server.

To obtain a one-time username and password, the client generates and
sends a Shared Secret Request. This is done as described in Section
9.2 of STUN. This request will have no attributes, and therefore,
based on the processing in Section 7.1, the server will reject it
with a Shared Secret Error Response

10.2 Message Attributes with a 401 response code. That
response will contain a NONCE and a REALM. The following additional client SHOULD generate
a new Shared Secret Request (with a new transaction ID), which
contains the NONCE and REALM attributes are defined:

0x0004: CHALLENGE
0x0005: AUTHENTICATION
0x0006: LIFETIME
0x0007: ALTERNATE-SERVER

10.2.1 CHALLENGE copied from the 401 response.
The CHALLENGE attribute request MUST include the USERNAME attribute, which contains a challenge, either from
username supplied by the server, user for credentials the specified realm. The request
MUST include a MESSAGE-INTEGRITY attribute as the last attribute. The
key for the HMAC is computed as described in order Section 7.1.

If the response (either to process the request, initial request or to the second
attempt with the credentials) is a Shared Secret Error Response, the
processing depends on the the value of the response code in the
ERROR-CODE attribute. If the response code was a 430, the client
SHOULD generate a new Shared Secret Request, using the username and
password provided by the user, and the REALM and NONCE provided in
the 430 response. For a 431 or 436 response code, the client SHOULD
alert the user. For a 432, 434 and 435 response codes, if the client
had omitted the USERNAME, REALM or NONCE attributes, respectively,
from the client,
for credentials previous request, it SHOULD retry, this time including the
USERNAME, NONCE, REALM, and MESSAGE-INTEGRITY attributes. For a 500
response code, the client MAY wait several seconds and then retry the
request. For a 600 response code, the client MUST NOT retry the
request, and SHOULD display the reason phrase to the user. Unknown
attributes between 400 and 499 are treated like a 400, unknown
attributes between 500 and 599 are treated like a 500, and unknown
attributes between 600 and 699 are treated like a 600. Any response
between 100 and 399 MUST result in order the cessation of request
retransmissions, but otherwise is discarded.

If a client receives a Shared Secret Response with an attribute whose
type is greater than 0x7fff, the attribute MUST be ignored. If the
client receives a Shared Secret Response with an attribute whose type
is less than or equal to process 0x7fff, the response. response is ignored.

If the response is a Shared Secret Response, it will contain the
USERNAME and PASSWORD attributes. The CHALLENGE contains two strings: client can use these to
authenticate an Allocate Request, as described below.

A client MAY send multiple Shared Secret Requests over the same TLS
connection, and MAY do so without waiting for responses to previous
requests. The client SHOULD close its connection when it has
completed allocating usernames and passwords.

8.3 Allocating a realm, Binding

When a client wishes to obtain a transport address, it sends an
Allocate Request to the TURN server. Requests for TCP transport
addresses MUST be sent over a TCP connection, and requests for UDP
transport addresses MUST be sent over UDP.

First, the client obtains a nonce. Both are
encoded one-time username and password, using a 16 bit length followed by the string.
mechanisms described in Section 8.2. The client then formulates an
Allocate Request. The string request MUST contain a transaction ID, unique
for each request, and uniformly and randomly distributed between 0
and 2**128 - 1. The message type of the request MUST
NOT be null terminated. ``Allocate
Request''. The 32 bit alignment length is set as described in Section 11.1 of STUN.

The Allocate request MUST contain the MAGIC-COOKIE attribute as the
first attribute. If the client wishes to allocate an odd or even
port, it can do so by including the lengths TRANSPORT-PREFERENCES attribute
in the
diagram below request. That attribute can also be used by the client if it
wishes to pre-allocate the port one higher.

The client SHOULD include a BANDWIDTH attribute, which indicates the
maximum bandwidth that will be used with this binding. If the maximum
is unknown, the attribute is not included in the request.

The client MAY request a particular lifetime for readability purposes only. No padding the binding by
including it in the LIFETIME attribute in the request. If the no data
is
required after sent or received on the end binding before expiration of the string for lifetime,
the realm.

The realm represents client MUST include a domain USERNAME attribute, containing a username
obtained from a previous Shared Secret Response. The request MUST
include a MESSAGE-INTEGRITY attribute as the last attribute. The key
is equal to the password obtained from the PASSWORD attribute of the
Shared Secret Response. The Allocate Request MUST be sent to the same
IP address and port as the Shared Secret Request. This is because one
time passwords are expected to be host-specific. Rules for
retransmissions for Allocate Requests sent over which UDP are identical to
those for STUN Binding Requests. Allocate Requests sent over TCP are
not retransmitted. Transaction timeouts are identical to those for
STUN Binding Requests, independent of the entity transport protocol.

8.4 Processing Allocate Responses

If the response is an Allocate Error Response, the client checks the
response code from the ERROR-CODE attribute of the response. For a
400 response code, the client SHOULD display the reason phrase to supply the
user. For a 420 response code, the client SHOULD retry the request,
this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES
attribute of the response. For a 430 response code, the client SHOULD
obtain a new one-time username and password. It password, and retry the Allocate
Request with a new transaction. For 401 and 432 response codes, if
the client had omitted the USERNAME or MESSAGE-INTEGRITY attribute as
indicated by the error, it SHOULD try again with those attributes. A
new one-time username and password is defined needed in [7]. The nonce that case. For a 431
response code, the client SHOULD alert the user, and MAY try the
request again after obtaining a new username and password. For a 300
response code, the client SHOULD attempt a new TURN transaction to
the server indicated in the ALTERNATE-SERVER attribute. For a 500
response code, the client MAY wait several seconds and then retry the
request with a new username and password. For a 600 response code,
the client MUST NOT retry the request, and SHOULD display the reason
phrase to the user. Unknown attributes between 400 and 499 are
treated like a 400, unknown attributes between 500 and 599 are
treated like a 500, and unknown attributes between 600 and 699 are
treated like a 600. Unknown attributes between 300 and 399 are
treated like 300. Any response between 100 and 299 MUST result in the
cessation of any request retransmissions, but otherwise is discarded.

If a randomly
chosen string that client receives a response with an attribute whose type is fed into
greater than 0x7fff, the signature computation. Nonce
selection procedures can attribute MUST be found ignored. If the client
receives a response with an attribute whose type is less than or
equal to 0x7fff, any request retransmissions MUST cease, but the
entire response is otherwise ignored.

If the response is an Allocate Response, the client MUST check the
response for a MESSAGE-INTEGRITY attribute. If not present, the
client MUST discard the response. If present, the client computes the
HMAC over the response. The key MUST be same as used to compute the
MESSAGE-INTEGRITY attribute in [7] the request. If the computed HMAC
differs from the one in the response, the client MUST discard the
response, and [9].

10.2.2 AUTHENTICATION SHOULD alert the user about a possible attack. If the
computed HMAC matches the one from the response, processing
continues.

The authentication attribute provides credentials. It contains three
strings: MAPPED-ADDRESS in the Binding Response can be used by the client
for receiving packets. The server will expire the binding after
LIFETIME seconds have passed with no activity. The server will allow
the user to send and receive no more than the amount of data
indicated in the BANDWIDTH attribute.

8.5 Allocating a realm, Pre-Allocated Binding

If the initial Allocate Request included TRANSPORT-PREFERENCES that
indicated a nonce, desire to pre-allocate the port one-higher, the client
MAY allocate that port at a signature, later time. It MUST do so within 4
minutes of receiving the Allocate Response, or the pre-allocated port
will expire.

To allocate the port, the client generates an Allocate Request as
described in Section 8.3. A new username and password MUST be used
for this allocation. The request MUST contain a username. They TRANSPORT-PREFERENCES
attribute. It MUST indicate an explicit interface and port, whose
value is one higher than the port number returned in the prior
Allocate Response.

Processing of the responses is identical to Section 8.4. However, the
client SHOULD explicitly check that received packets are
encoded TURN
responses, as opposed to data packets, using the techniques described
in Section 7.2.4.

8.6 Refreshing a 16 bit length, followed by Binding

If there has been no activity on a UDP binding for a period of time
equalling 3/4 of the string (the strings
MUST NOT lifetime of the binding (as conveyed in the
LIFETIME attribute of the Allocate Response), the client SHOULD
refresh the binding with another Allocate Request if it wishes to
keep it. Note that only UDP bindings can be null terminated).

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Realm ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Signature ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Username ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The realm and nonce refreshed. For TCP,
application-specific keepalives are needed.

To perform a refresh, the client generates an Allocate Request as
described in [7]. The Section 8.3. However, the one-time username is and password
used MUST be the user
identity. same as those used in the successful Allocate
Request for that binding. The signature client will need to look for the TURN
response amongst the data packets using the MAGIC-COOKIE, as
described in Section 7.2.4. Processing of that response is computed as follows. defined
in Section 8.4. If the response was an Allocate Response, and the
MAPPED-ADDRESS contains the same transport address as previously
obtained, the binding has been refreshed. The entire TURN request, including LIFETIME attribute
indicates the TURN headers, up amount of additional time the binding will live without
activity. If, however, the response was an Allocate Error Response
with an ERROR-CODE indicating a 430 response, it means that the
binding has expired at the server. The client MAY use the procedures
in Section 8.3 to obtain a new binding (this will require a new
one-time username and password. Other response codes do not imply
that the end of binding has been expired, just that the last refresh has failed.

8.7 Tearing Down a Binding

If a client no longer needs a binding, it SHOULD tear it down. For
TCP, this is done by closing the connection. For UDP, this is done by
performing a refresh, as described in Section 8.6, but with a
LIFETIME attribute before indicating a time of 0.

8.8 Receiving and Sending Data

Once a binding has been allocated by an Allocate Response, the AUTHENTICATION attribute, client
MUST be prepared to receive data from the socket on which the
Allocate Request was sent. For UDP, the client MUST be prepared to
disambiguate TURN messages from data for a period of 32 seconds
following the first TURN response. This disambiguation is taken done using
the MAGIC-COOKIE, as
string "S". String "S" described in Section 7.2.4.

Once data has been received, the client MAY send data to its peer by
sending data on that same socket. Sending data on the socket before
data is base64 encoded received will cause the data to become string "B". be discarded by the server.

9. Protocol Details

This section presents the detailed encoding of the message types,
attributes, and response codes which are new to TURN. The
signature general
message structure of TURN is computed as the request-digest token, according identical to STUN [1].

9.1 Message Types

TURN defines three new Message Types:

0x0003 : Allocate Request
0x0103 : Allocate Response
0x0113 : Allocate Error Response

9.2 Message Attributes

TURN defines the following message attributes:

0x000c: TRANSPORT-PREFERENCES
0x000d: LIFETIME
0x000e: ALTERNATE-SERVER
0x000f: MAGIC-COOKIE
0x0010: BANDWIDTH

9.2.1 TRANSPORT-PREFERENCES

The TRANSPORT-PREFERENCES attribute indicates preferences for the
ports allocated by the TURN server. It is either 32 or 96 bits long,
depending on the
rules value of RFC 2617, as if A1 was equal the Typ bits. These bits indicate the
preferences for the allocated port:

0b00: no preferences
0b01: odd port parity
0b10: even port parity
0b11: allocate a pre-allocated port

When the Typ bits are 0b11, the following 64 bits encode the
pre-allocated transport address. They are in the same format used for
MAPPED-ADDRESS.

The P bit indicates a desire for pre-allocating the port one-higher.
If 1, it means pre-allocation is desired. This bit MUST NOT be set to string "B", and qop was
unspecified.

10.2.3
1 if the Typ bits are 0b11. That is, pre-allocation cannot be done
again when allocating a previously pre-allocated port.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |P|Typ|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.2.2 LIFETIME

The lifetime attribute represents the duration that for which the server
will maintain a mapping is
valid. binding in the absence of data traffic either from or
to the client. It is a 32 bit value representing the number of
seconds remaining until expiration.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10.2.4

9.2.3 ALTERNATE-SERVER

The alternate server represents an alternate IP address and port for
a different allocation TURN server to try. It is encoded in the same way as
MAPPED-ADDRESS.

9.2.4 MAGIC-COOKIE

The MAGIC-COOKIE is used by TURN clients and servers to disambiguate
TURN traffic from data traffic. Its value ix 0x72c64bc6.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|1|1|0|0|1|0|1|1|0|0|0|1|1|0|0|1|0|0|1|0|1|1|1|1|0|0|0|1|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.2.5 BANDWIDTH

The bandwidth attribute represents the peak bandwidth, measured in
kbits per second, that the client expects to use on the binding. The
value represents the sum in the receive and send directions.
[[Editors note: Need to define leaky bucket parameters for this.]]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.3 Response Codes

TURN defines the following new response codes:

300 (Try Alternate): The client should contact an alternate server
for this request.

434 (Missing Realm): The REALM attribute was not present in the
request.

435 (Missing Nonce): The NONCE attribute was not present in the
request.

436 (Unknown Username): The USERNAME supplied in the Shared Secret
Request is not known in the given REALM.

10. Security Considerations

TURN servers, unlike STUN servers, create state upon processing servers allocate bandwidth and port resources to clients.
Therefore, a TURN server requires authentication and authorization of
TURN requests. As This authentication is provided by a result, they SHOULD authenticate all requests before
allocating client digest
over TLS, which results in the generation of a mapping one-time password that
is used in a single subsequent Allocate Request. This mechanism
protects against eavesdropping attacks and man-in-the-middle attacks.
The usage of one-time passwords ensures that the Allocate Requests,
which do not run over TLS, are not susceptible to offline dictionary
attacks that can be used to guess the client. Furthermore, it long lived shared secret
between the client and the server.

Because TURN servers allocate resources, they can be susceptible to
denial-of-service attacks. All Allocate Requests are authenticated,
so that an unknown attacker cannot launch an attack. An authenticated
attacker can generate multiple Allocate Requests, but each requires a
new one-time username and password. It is RECOMMENDED that authorization policies be used servers
implement a cap on the number of one-time passwords that are
allocated to any specific user at a time (around 5 or 10 should be
sufficient). This will prevent floods of Allocate requests from a
single user, in an attempt to use up the resources of the system. A
single malicious user could generate a single Allocate Request,
obtain a binding, and then flood the server with data over this
binding, in an attempt to deny others service. However, this attack
requires the attacker themselves to receive the data being sent at
the server. To ameliorate these kinds of attacks, servers SHOULD
implement a bandwidth cap on each binding (conveyed to the client in
the BANDWIDTH attribute of the Allocate Response), and discard
packets beyond the threshold.

A client will use the transport address learned from
allocating more than the
MAPPED-ADDRESS attribute of the Binding Response to tell other users
how to reach them. Therefore, a configured number client needs to be certain that this
address is valid, and will actually route to them. Such validation
occurs through the TLS and HMAC-based authentication and integrity
checks provided in TURN. They can guarantee the authenticity and
integrity of mappings. This prevents
hogging the mapped addressses. Note that TURN is not susceptible
to the attacks described in Section 12.2.3, 12.2.4, 12.2.5 or 12.2.6
of resources by an attacker. STUN. These attacks are based on the fact that a STUN server
mirrors the source IP address, which cannot be authenticated. TURN
does not use the source address of the Binding Request, and
therefore, those attacks do not apply.

Confidentiality of the transport addresses learned through TURN does
not appear to be that important, and therefore, this capability is
not provided.

TURN servers are useful even for users not behind a NAT. They can
provide a way for truly anonymous communications. A user can cause a
call to have its media routed through a TURN server, so that the
user's IP addresses are never revealed.

TCP transport addresses allocated by TURN will properly work with TLS
and SSL. However, any addresses allocated by TURN will not operate
properly with IPSec Authentication Header (AH) [10] in transport
mode. IPSec ESP [11] and any tunnel-mode ESP or AH should still
operate.

11. IAB Considerations

The IAB has studied the important property problem of ``Unilateral Self Address
Fixing'', 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 RFC 3424 [12].
TURN is an example of a protocol that performs this type of function.
The IAB has mandated that compromise any protocols developed for this purpose
document a specific set of considerations. This section meets those
requirements.

11.1 Problem Definition

From RFC 3424 [12], any UNSAF proposal must provide:

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; this is why "short term
fixes usually aren't".

The specific problem being solved by TURN servers
cannot cause security breaches when is for a client, which may
be located behind a NAT of any type, to obtain an IP address and port
on the public Internet, 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. Both UDP and TCP are
addressed. It is within also possible to send packets so that the recipient
sees a source address equal to the allocated address. TURN, by
design, does not allow a client to run a server (such as a web or
SMTP server) using a TURN address. TURN is useful even when NAT is
not present, to provide anonymity services.

11.2 Exit Strategy

From [12], any UNSAF proposal must provide:

Description of an
enterprise. The 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.

It is expected that TURN will be useful indefinitely, to provide
anonymity services. When used to facilitate NAT traversal, TURN does
not iself provide an exit strategy. That is provided by the
Interactive Connectivity Establishment (ICE) [13] mechanism. ICE
allows two cooperating clients to interactively determine the best
addresses to use when communicating. ICE uses TURN-allocated
addresses as a last resort, only thing when no other means of connectivity
exists. As a result, as NATs phase out, and as IPv6 is deployed, ICE
will increasingly use other addresses (host local addresses).
Therefore, clients will allocate TURN addresses, but not use them,
and therefore, de-allocate them. Servers will see a decrease in
usage. Once a provider sees that its TURN servers are not being used
at all (that is, no media flows through them), they can simply remove
them. ICE will operate without TURN-allocated addresses.

11.3 Brittleness Introduced by TURN

From [12], any UNSAF proposal must provide:

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.

TURN introduces brittleness in a compromised few ways. First, it adds another
server can do element to any system, which adds another point of failure.
TURN requires clients to demultiplex TURN packets and data based on
hunting for a MAGIC-COOKIE in the TURN messages. It is return
false addresses, possible (with
extremely small probabilities) that this cookie could appear within a
data stream, resulting in mis-classification. That might introduce
errors into the inability data stream (they would appear as lost packets), and
also result in loss of a binding. TURN relies on any NAT bindings
existing for the duration of the bindings held by the TURN server.
Neither the client nor the TURN server have a way of reliably
determining this lifetime (STUN can provide a means, but it is
heuristic in nature and not reliable). Therefore, if there is no
activity on an address learned from TURN for some period, the address
might become useless spontaneously.

TURN will result in potentially significant increases in packet
latencies, and also increases in packet loss probabilities. That is
because it introduces an intermediary on the path of a packet from
point A to receive
any data at all. The protocol B, whose location is therefore fail safe.

12 Authors Addresses

Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com

Joel Weinberger
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jweinberger@dynamicsoft.com

Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: huitema@microsoft.com

Rohan Mahy
Cisco Systems
170 West Tasman Dr, MS: SJC-21/3
Phone: +1 408 526 8570
Email: rohan@cisco.com

13 Bibliography

[1] D. Senie, "NAT friendly application design guidelines," Internet
Draft, Internet Engineering Task Force, Mar. 2001. Work determined by application-layer
processing, not underlying routing topologies. Therefore, a packet
sent from one user on a LAN to another on the same LAN may do a trip
around the world before arriving. When combined with ICE, some of the
most problematic cases are avoided (such as this example) by avoiding
the usage of TURN addresses. However, when used, this problem will
exist.

Note that TURN does not suffer from many of the points of brittleness
introduced by STUN. TURN will work with all existing NAT types known
at the time of writing, and for the forseeable future. TURN does not
introduce any topological constraints. TURN does not rely on any
heuristics for NAT type classification.

11.4 Requirements for a Long Term Solution

From [12]}, any UNSAF proposal must provide:

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

Our experience with TURN continues to validate our belief in progress.

[2] J. the
requirements outlined in Section 14.4 of STUN.

11.5 Issues with Existing NAPT Boxes

From [12], any UNSAF proposal must provide:

Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports.

A number of NAT boxes are now being deployed into the market which
try and provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This will interfere with proper
operation of any UNSAF mechanism, including TURN. However, if a NAT
tries to modify a MAPPED-ADDRESS in a TURN Allocate Response, this
will be detected by the client as an attack.

12. Requirements Analysis

TODO.

13. Examples

TODO.

Normative References

[1] Rosenberg, J. Weinberger, C. J., Huitema, and R. C., Mahy, R. and J. Weinberger, "STUN -
simple traversal
Simple Traversal of UDP through NATs," Internet Draft, Internet
Engineering Task Force, Oct. 2001. Work in progress.

[3] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm
specific IP: framework," Request for Comments 3102, Internet
Engineering Task Force, Oct. 2001.

[4] M. Borella, D. Grabelsky, J. Lo, and K. Taniguchi, "Realm
specific IP: protocol specification," Request for Comments 3103,
Internet Engineering Task Force, Oct. 2001.

[5] S. Through Network Address Translators",
draft-ietf-midcom-stun-05 (work in progress), December 2002.

[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels," Request for Comments Indicate Requirement
Levels", BCP 14, RFC 2119, Internet Engineering Task Force,
Mar. March 1997.

[6] A.

[3] Gulbrandsen, P. A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)," Request for Comments SRV)", RFC 2782,
Internet Engineering Task Force, Feb.
February 2000.

[7] J.

[4] Franks, P. J., Hallam-Baker, J. P., Hostetler, S. J., Lawrence, P. S.,
Leach,
A. P., Luotonen, A. and L. Stewart, "HTTP authentication: Authentication:
Basic and digest
access authentication," Request for Comments Digest Access Authentication", RFC 2617, Internet
Engineering Task Force, June 1999.

[8] M. Handley, H.

Informative References

[5] Schulzrinne, E. Schooler, H., Casner, S., Frederick, R. and J. V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.

[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999.
Session Initiation Protocol", RFC 3261, June 2002.

[7] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.

[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.

[9] J. Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.

[10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.

[11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.

[12] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.

[13] Rosenberg, "Request header integrity J., "Interactive Connectivity Establishment (ICE): A
Methodology for SIP Nettwork Address Translator (NAT) Traversal
for the Session Initiation Protocol (SIP)",
draft-rosenberg-sipping-ice-00 (work in progress), February
2003.

Authors' Addresses

Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
East Hanover, NJ 07936
US

Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Joel Weinberger
dynamicsoft
72 Eagle Rock Avenue
East Hanover, NJ 07936
US

Phone: +1 973 952-5000
EMail: jweinberger@dynamicsoft.com

Rohan Mahy
Cisco Systems
101 Cooper St
Santa Cruz, CA 95060
US

EMail: rohan@cisco.com

Christian Huitema
Microsoft
One Microsoft Way
Redmond, WA 98052-6399
US

EMail: huitema@microsoft.com

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and HTTP digest
using predictive nonces," Internet Draft,
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in progress.

Table its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of Contents

1 Introduction ........................................ 1
2 Do we need any
kind, provided that the above copyright notice and this Protocol? .......................... 2
3 Terminology ......................................... 3
4 Definitions ......................................... 3
5 Overview paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Operation ............................... 4
6 Message Overview .................................... 5
7 Server Behavior ..................................... 6
7.1 Client Authentication ............................... 6
7.2 Server Authentication ............................... 6
7.3 Allocation .......................................... 6
8 Client Behavior ..................................... 8
8.1 Discovery ........................................... 8
8.2 Authentication ...................................... 9
8.3 Allocate request .................................... 10
9 Example Usage ....................................... 10
9.1 UDP Allocation ...................................... 10
9.2 Authentication ...................................... 10
10 Protocol Details .................................... 13
10.1 Message Header ...................................... 13
10.2 Message Attributes .................................. 13
10.2.1 CHALLENGE ........................................... 13
10.2.2 AUTHENTICATION ...................................... 14
10.2.3 LIFETIME ............................................ 14
10.2.4 ALTERNATE-SERVER .................................... 15
11 Security Considerations ............................. 15
12 Authors Addresses ................................... 15
13 Bibliography ........................................ 16
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.