< draft-ietf-behave-turn-03.txt   draft-ietf-behave-turn-04.txt >
Behave J. Rosenberg Behave J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track R. Mahy Intended status: Standards Track R. Mahy
Expires: September 5, 2007 Plantronics Expires: January 9, 2008 Plantronics
C. Huitema C. Huitema
Microsoft Microsoft
March 4, 2007 July 8, 2007
Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN) Traversal Using Relays around NAT (TURN): Relay Extensions to Session
draft-ietf-behave-turn-03 Traversal Utilities for NAT (STUN)
draft-ietf-behave-turn-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This specification defines a usage of the Simple Traversal Underneath This specification defines an extension of the Session Traversal
NAT (STUN) Protocol for asking the STUN server to relay packets Utilities for NAT (STUN) Protocol for asking the STUN server to relay
towards a client. This usage is useful for elements behind NATs packets towards a client. This extension, called Traversal Using
whose mapping behavior is address and port dependent. The extension Relays around NAT (TURN), is useful for elements behind NATs whose
mapping behavior is address and port dependent. The extension
purposefully restricts the ways in which the relayed address can be purposefully restricts the ways in which the relayed address can be
used. In particular, it prevents users from running general purpose used. In particular, it prevents users from running general purpose
servers from ports obtained from the STUN server. servers from ports obtained from the STUN server.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
4.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Tuple Terminology . . . . . . . . . . . . . . . . . . . . 8 4.2. Tuple Terminology . . . . . . . . . . . . . . . . . . . . 8
4.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 9
5. New Framing Mechanism for Stream-Oriented Transports . . . . . 10 5. New Framing Mechanism for Stream-Oriented Transports . . . . . 10
6. New STUN Requests and Indications . . . . . . . . . . . . . . 10 6. New STUN Requests and Indications . . . . . . . . . . . . . . 10
6.1. Allocate Request . . . . . . . . . . . . . . . . . . . . . 11 6.1. Allocate Request . . . . . . . . . . . . . . . . . . . . . 11
6.1.1. Client Behavior . . . . . . . . . . . . . . . . . . . 11 6.1.1. Client Behavior . . . . . . . . . . . . . . . . . . . 11
6.1.2. Server Behavior . . . . . . . . . . . . . . . . . . . 13 6.1.2. Server Behavior . . . . . . . . . . . . . . . . . . . 13
6.2. Procedures for all other Requests and Indications . . . . 17 6.2. Procedures for all other Requests and Indications . . . . 17
6.3. Set Active Destination Request . . . . . . . . . . . . . . 18 6.3. Set Active Destination Request . . . . . . . . . . . . . . 18
6.3.1. Client Behavior . . . . . . . . . . . . . . . . . . . 18 6.3.1. Client Behavior . . . . . . . . . . . . . . . . . . . 18
6.3.2. Server Behavior . . . . . . . . . . . . . . . . . . . 19 6.3.2. Server Behavior . . . . . . . . . . . . . . . . . . . 19
6.4. Connect Request . . . . . . . . . . . . . . . . . . . . . 19 6.4. Connect Request . . . . . . . . . . . . . . . . . . . . . 19
6.4.1. Server Behavior . . . . . . . . . . . . . . . . . . . 19 6.4.1. Server Behavior . . . . . . . . . . . . . . . . . . . 20
6.5. Connection Status Indication . . . . . . . . . . . . . . . 20 6.5. Connection Status Indication . . . . . . . . . . . . . . . 20
6.6. Send Indication . . . . . . . . . . . . . . . . . . . . . 20 6.6. Send Indication . . . . . . . . . . . . . . . . . . . . . 20
6.6.1. Client Behavior . . . . . . . . . . . . . . . . . . . 20 6.6.1. Client Behavior . . . . . . . . . . . . . . . . . . . 21
6.6.2. Server Behavior . . . . . . . . . . . . . . . . . . . 21 6.6.2. Server Behavior . . . . . . . . . . . . . . . . . . . 21
6.7. Data Indication . . . . . . . . . . . . . . . . . . . . . 21 6.7. Data Indication . . . . . . . . . . . . . . . . . . . . . 22
6.7.1. Client Behavior . . . . . . . . . . . . . . . . . . . 21 6.7.1. Client Behavior . . . . . . . . . . . . . . . . . . . 22
6.7.2. Server Behavior . . . . . . . . . . . . . . . . . . . 22 6.7.2. Server Behavior . . . . . . . . . . . . . . . . . . . 22
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 22 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2. BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . 23
7.3. REMOTE-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 23 7.3. REMOTE-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 23
7.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.5. RELAY-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 23 7.5. RELAY-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 24
7.6. REQUESTED-PORT-PROPS . . . . . . . . . . . . . . . . . . . 23 7.6. REQUESTED-PORT-PROPS . . . . . . . . . . . . . . . . . . . 24
7.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 24 7.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 25
7.8. REQUESTED-IP . . . . . . . . . . . . . . . . . . . . . . . 25 7.8. REQUESTED-IP . . . . . . . . . . . . . . . . . . . . . . . 25
7.9. CONNECT_STAT . . . . . . . . . . . . . . . . . . . . . . . 25 7.9. CONNECT_STAT . . . . . . . . . . . . . . . . . . . . . . . 25
8. New Error Response Codes . . . . . . . . . . . . . . . . . . . 25 8. New Error Response Codes . . . . . . . . . . . . . . . . . . . 26
9. Client Procedures . . . . . . . . . . . . . . . . . . . . . . 26 9. Client Procedures . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Receiving and Sending Unencapsulated Data . . . . . . . . 26 9.1. Receiving and Sending Unencapsulated Data . . . . . . . . 26
9.1.1. Datagram Protocols . . . . . . . . . . . . . . . . . . 26 9.1.1. Datagram Protocols . . . . . . . . . . . . . . . . . . 27
9.1.2. Stream Transport Protocols . . . . . . . . . . . . . . 27 9.1.2. Stream Transport Protocols . . . . . . . . . . . . . . 27
10. Server Procedures . . . . . . . . . . . . . . . . . . . . . . 27 10. Server Procedures . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Receiving Data on Allocated Transport Addresses . . . . . 27 10.1. Receiving Data on Allocated Transport Addresses . . . . . 27
10.1.1. TCP Processing . . . . . . . . . . . . . . . . . . . . 27 10.1.1. TCP Processing . . . . . . . . . . . . . . . . . . . . 27
10.1.2. UDP Processing . . . . . . . . . . . . . . . . . . . . 28 10.1.2. UDP Processing . . . . . . . . . . . . . . . . . . . . 28
10.2. Receiving Data on Internal Local Transport Addresses . . . 28 10.2. Receiving Data on Internal Local Transport Addresses . . . 29
10.3. Lifetime Expiration . . . . . . . . . . . . . . . . . . . 29 10.3. Lifetime Expiration . . . . . . . . . . . . . . . . . . . 29
11. Formal Definition of STUN Usage . . . . . . . . . . . . . . . 29 11. Client Discovery of TURN Servers . . . . . . . . . . . . . . . 30
11.1. Applicability Statement . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11.2. Client Discovery of Server . . . . . . . . . . . . . . . . 30 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11.3. Server Determination of Usage . . . . . . . . . . . . . . 31 13.1. New STUN Requests, Responses, and Indications . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 31
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
13.1. New STUN Requests, Responses, and Indications . . . . . . 33
13.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 33 13.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 33
13.3. New STUN response codes . . . . . . . . . . . . . . . . . 34 13.3. New STUN response codes . . . . . . . . . . . . . . . . . 33
14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 34 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 34 15. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 35 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
14.3. Brittleness Introduced by STUN relays . . . . . . . . . . 35 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
14.4. Requirements for a Long Term Solution . . . . . . . . . . 36 17.1. Normative References . . . . . . . . . . . . . . . . . . . 38
14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 36 17.2. Informative References . . . . . . . . . . . . . . . . . . 38
15. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 40
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
17.1. Normative References . . . . . . . . . . . . . . . . . . . 41
17.2. Informative References . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
The Simple Traversal Underneath NAT (STUN) [1] provides a suite of Session Traversal Utilities for NAT (STUN) [1] provides a suite of
tools for facilitating the traversal of NAT. Specifically, it tools for facilitating the traversal of NAT. Specifically, it
defines the Binding Request, which is used by a client to determine defines the Binding Request, which is used by a client to determine
its reflexive transport address towards the STUN server. The its reflexive transport address towards the STUN server. The
reflexive transport address can be used by the client for receiving reflexive transport address can be used by the client for receiving
packets from peers, but only when the client is behind "good" NATs. packets from peers, but only when the client is behind "good" NATs.
In particular, if a client is behind a NAT whose mapping behavior In particular, if a client is behind a NAT whose mapping behavior [9]
[10] is address or address and port dependent (sometimes called "bad" is address or address and port dependent (sometimes called "bad"
NATs), the reflexive transport address will not be usable for NATs), the reflexive transport address will not be usable for
communicating with a peer. communicating with a peer.
The only way to obtain a transport address that can be used for The only way to obtain a transport address that can be used for
corresponding with a peer through such a NAT is to make use of a corresponding with a peer through such a NAT is to make use of a
relay. The relay sits on the public side of the NAT, and allocates relay. The relay sits on the public side of the NAT, and allocates
transport addresses to clients reaching it from behind the private transport addresses to clients reaching it from behind the private
side of the NAT. These allocated addresses are from interfaces on side of the NAT. These allocated addresses are from interfaces on
the relay. When the relay receives a packet on one of these the relay. When the relay receives a packet on one of these
allocated addresses, the relay forwards it toward the client. allocated addresses, the relay forwards it toward the client.
This specification defines a usage of STUN, called the relay usage, This specification defines an extension of STUN, called TURN, that
that allows a client to request an address on the STUN server itself, allows a client to request an address on the STUN server itself, so
so that the STUN server acts as a relay. To accomplish that, this that the STUN server acts as a relay. To accomplish that, this
usage defines a handful of new STUN requests and indications. The extension defines a handful of new STUN requests and indications.
Allocate request is the most fundamental component of this usage. It The Allocate request is the most fundamental component of this set of
is used to provide the client with a transport address that is extensions. It is used to provide the client with a transport
relayed through the STUN server. A transport address which relays address that is relayed through the STUN server. A transport address
through an intermediary is called a relayed transport address. which relays through an intermediary is called a relayed transport
address.
Though a relayed address is highly likely to work when corresponding Though a relayed address is highly likely to work when corresponding
with a peer, it comes at high cost to the provider of the relay with a peer, it comes at high cost to the provider of the relay
service. As a consequence, relayed transport addresses should only service. As a consequence, relayed transport addresses should only
be used as a last resort. Protocols using relayed transport be used as a last resort. Protocols using relayed transport
addresses should make use of mechanisms to dynamically determine addresses should make use of mechanisms to dynamically determine
whether such an address is actually needed. One such mechanism, whether such an address is actually needed. One such mechanism,
defined for multimedia session establishment protocols, based on the defined for multimedia session establishment protocols, based on the
offer/answer protocol in RFC 3264 [5], is Interactive Connectivity offer/answer protocol in RFC 3264 [4], is Interactive Connectivity
Establishment (ICE) [9]. Establishment (ICE) [8].
The mechanism defined here was previously a standalone protocol The mechanism defined here was previously a standalone protocol
called Traversal Using Relay NAT (TURN), and is now defined as a called Traversal Using Relay NAT (TURN), and is now defined as an
usage of STUN. extension of STUN. A STUN server that supports these extensions can
be called a 'STUN relay' or more simply a 'TURN server'.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
3. Definitions 3. Definitions
Relayed Transport Address: A transport address that terminates on a Relayed Transport Address: A transport address that terminates on a
server, and is forwarded towards the client. The STUN Allocate server, and is forwarded towards the client. The STUN Allocate
Request can be used to obtain a relayed transport address, for Request can be used to obtain a relayed transport address, for
example. example.
STUN relay client: A STUN client that implements this specification. TURN client: A STUN client that implements this specification. It
It obtains a relayed transport address that it provides to a small obtains a relayed transport address that it provides to a small
number of peers (usually one). number of peers (usually one).
STUN relay server: A STUN server that implements this specification. TURN server: A STUN server that implements this specification. It
It relays data between a STUN relay client and its peer. relays data between a TURN client and its peer.
5-tuple: A combination of the source IP address and port, 5-tuple: A combination of the source IP address and port,
destination IP address and port, and transport protocol (UDP, TCP, destination IP address and port, and transport protocol (UDP, TCP,
or TLS over TCP). It uniquely identifies a TCP connection, TLS or TLS over TCP). It uniquely identifies a TCP connection, TLS
channel, or bi-directional flow of UDP datagrams. channel, or bi-directional flow of UDP datagrams.
permission: TBD Permission: A record of an IP address and transport of a peer that
is permitted to send traffic to the TURN client. The TURN server
will only forward traffic to its client from peers that match an
existing permission.
4. Overview of Operation 4. Overview of Operation
In a typical configuration, a STUN relay client is connected to a In a typical configuration, a TURN client is connected to a private
private network and through one or more NATs to the public Internet. network and through one or more NATs to the public Internet. On the
On the public Internet is a STUN relay server. The STUN Relay usage public Internet is a TURN server. This specification defines several
defines several new messages and a new framing mechanism that add the new messages and a new framing mechanism that add the ability for a
ability for a STUN server to act as a packet relay. The text in this STUN server to act as a packet relay. The text in this section
section explains the typical usage of this relay extension. explains the typical usage of this relay extension.
First the client sends an Allocate request to the server, which the First the client sends an Allocate request to the server, which the
server authenticates. The server generates an Allocate response with server authenticates. The server generates an Allocate response with
the allocated address, port, and target transport. All other STUN the allocated address, port, and target transport. All other STUN
messages defined by the STUN relay usage happen in the context of an messages defined by this specification happen in the context of an
allocation. allocation.
A successful Allocate Request just reserves an address on the STUN A successful Allocate Request just reserves an address on the TURN
relay server. Data does not flow through an allocated port until the server. Data does not flow through an allocated port until the TURN
STUN relay client asks the STUN relay server to open a permission. client asks the TURN server to open a permission. It can do this by
It can do this by sending data to the far end with a Send Indication sending data to the far end with a Send Indication for UDP
for UDP allocations, by sending a ConnectRequest for TCP allocations, allocations, by sending a ConnectRequest for TCP allocations, or by
or by setting the default destination for either transport. While setting the default destination for either transport. While the
the client can request more than one permission per allocation, it client can request more than one permission per allocation, it needs
needs to request each permission explicitly and one at a time. This to request each permission explicitly and one at a time. This
insures that a client can't use a STUN relay server to run a insures that a client can't use a TURN server to run a traditional
traditional server, and partially protects the client from DoS server, and partially protects the client from DoS attacks.
attacks.
Once a permission is open, the client can then receive data flowing Once a permission is open, the client can then receive data flowing
back from its peer. Initially this data is wrapped in a STUN Data back from its peer. Initially this data is wrapped in a STUN Data
Indication. Since multiple permissions can be open simultaneously, Indication. Since multiple permissions can be open simultaneously,
the Data Indication contains the Remote Address attribute so the STUN the Data Indication contains the Remote Address attribute so the TURN
relay client knows which peer sent the data. The client can send client knows which peer sent the data. The client can send data to
data to any of its peers with the Send Indication. any of its peers with the Send Indication.
Once the client wants to primarily receive from one peer, it can send Once the client wants to primarily receive from one peer, it can send
a SetActiveDestination request. All subsequent data received from a SetActiveDestination request. All subsequent data received from
the active peer is forwarded directly to the client and vice versa, the active peer is forwarded directly to the client and vice versa,
except that it is wrapped or framed according to the protocol used except that it is wrapped or framed according to the protocol used
between the STUN relay client and STUN relay server. The client can between the TURN client and TURN server. The client can send
send subsequent SetActiveDestination requests to change or remove the subsequent SetActiveDestination requests to change or remove the
active destination. active destination.
When the STUN relay client to server communication is over a datagram When the TURN client to server communication is over a datagram
protocol (UDP), any datagram received from the active peer that has protocol (UDP), any datagram received from the active peer that has
the STUN magic cookie is wrapped in a Data Indication. Likewise any the STUN magic cookie is wrapped in a Data Indication. Likewise any
datagram sent by the client that has the STUN magic cookie and is datagram sent by the client that has the STUN magic cookie and is
intended for the active peer is wrapped in a Send Indication. This intended for the active peer is wrapped in a Send Indication. This
wrapping prevents the STUN relay server from inappropriately wrapping prevents the STUN relay server from inappropriately
interpreting end-to-end data. interpreting end-to-end data.
Over stream-based transports (TCP and TLS over TCP), the STUN relay Over stream-based transports (TCP and TLS over TCP), the TURN client
client and server always use some additional framing (defined in and server always use some additional framing (defined in Section 5)
Section 5) so that end-to-end data is distinguishable from STUN so that end-to-end data is distinguishable from STUN control
control messages. This additional framing just has a type and a messages. This additional framing just has a type and a length
length field. The value of the type field was chosen so it is always field. The value of the type field was chosen so it is always
distinguishable from an unframed STUN request or response. distinguishable from an unframed STUN request or response.
The SetActiveDestination Request does not close other bindings. Data The SetActiveDestination Request does not close other bindings. Data
to and from other peers is still wrapped in Send and Data indications to and from other peers is still wrapped in Send and Data indications
respectively. respectively.
Allocations can also request specific attributes such as the desired Allocations can also request specific attributes such as the desired
Lifetime of the allocation, and the maximum Bandwidth. Clients can Lifetime of the allocation, and the maximum Bandwidth. Clients can
also request specific port assignment behavior, for example, a also request specific port assignment behavior, for example, a
specific port number, odd or even port numbers, or pairs of specific port number, odd or even port numbers, or pairs of
sequential port numbers. sequential port numbers.
4.1. Transports 4.1. Transports
STUN relay clients can communicate with a STUN relay server using TURN clients can communicate with a TURN server using UDP, TCP, or
UDP, TCP, or TLS over TCP. A STUN relay can even relay traffic TLS over TCP. A TURN can even relay traffic between two different
between two different transports with certain restrictions. A STUN transports with certain restrictions. A TURN can never relay from an
relay can never relay from an unreliable transport (client to server) unreliable transport (client to server) to a reliable transport to
to a reliable transport to the peer. Note that a STUN relay server the peer. Note that a TURN server never has a TLS relationship with
never has a TLS relationship with a client's peer, since the STUN a client's peer, since the TURN server does not interpret data above
relay server does not interpret data above the TCP layer. When the TCP layer. When relaying data sent from a stream-based protocol
relaying data sent from a stream-based protocol to a UDP peer, the to a UDP peer, the TURN server emits datagrams which are the same
STUN relay server emits datagrams which are the same length as the length as the length field in the STUN TCP framing or the length
length field in the STUN TCP framing or the length field in a Send field in a Send Indication. Likewise, when a UDP datagram is relayed
Indication. Likewise, when a UDP datagram is relayed from a peer from a peer over a stream-based transport, the length of the datagram
over a stream-based transport, the length of the datagram is the is the length of the TCP framing or Data Indication.
length of the TCP framing or Data Indication.
+----------------------+--------------------+ +----------------+--------------+
| client to STUN relay | STUN relay to peer | | client to TURN | TURN to peer |
+----------------------+--------------------+ +----------------+--------------+
| UDP | UDP | | UDP | UDP |
| TCP | TCP | | TCP | TCP |
| TCP | UDP | | TCP | UDP |
| TLS | TCP | | TLS | TCP |
| TLS | UDP | | TLS | UDP |
+----------------------+--------------------+ +----------------+--------------+
For STUN relay clients, using TLS over TCP provides two benefits. For TURN clients, using TLS over TCP provides two benefits. When
When using TLS, the client can be assured that the address of the using TLS, the client can be assured that the address of the client's
client's peers are not visible to an attacker except by traffic peers are not visible to an attacker except by traffic analysis
analysis downstream of the STUN relay server. Second, the client may downstream of the TURN server. Second, the client may be able to
be able to communicate with STUN relay servers using TLS that it communicate with TURN servers using TLS that it would not be able to
would not be able to communicate with using TCP or UDP due to the communicate with using TCP or UDP due to the configuration of a
configuration of a firewall between the STUN relay client and its firewall between the TURN client and its server. TLS between the
server. TLS between the client and STUN relay server in this case client and TURN server in this case just facilitates traversal.
just facilitates traversal.
For TCP connections, the Connection Request allows the client to ask For TCP connections, the Connection Request allows the client to ask
the server to open a connection to the peer. This also adds a the server to open a connection to the peer. This also adds a
permission to accept an incoming TCP connection from the remote permission to accept an incoming TCP connection from the remote
address of the peer. When the server and the peer try to open a TCP address of the peer. When the server and the peer try to open a TCP
connection at the same time, this is called TCP simultaneous open. connection at the same time, this is called TCP simultaneous open.
When the STUN relay-to-peer leg is TCP, the STUN relay client needs When the TURN-to-peer leg is TCP, the TURN client needs to be aware
to be aware of the status of these TCP connections. The STUN relay of the status of these TCP connections. The TURN extension defines
extension defines application states for a TCP connection as follows: application states for a TCP connection as follows: LISTEN,
LISTEN, ESTABLISHED, and CLOSED. Consequently, the STUN relay server ESTABLISHED, and CLOSED. Consequently, the TURN server sends a
sends a ConnectionState Indication for a binding whenever the relay ConnectionState Indication for a binding whenever the relay
connection status changes for one of the client's bindings, except connection status changes for one of the client's bindings, except
when the status changes due to a STUN relay client request (ex: an when the status changes due to a TURN client request (ex: an explicit
explicit binding deallocation). binding deallocation).
4.2. Tuple Terminology 4.2. Tuple Terminology
To relay data to and from the correct location, the STUN relay server To relay data to and from the correct location, the TURN server
maintains an association between an internal address (called a maintains an association between an internal address (called a
5-tuple) and one or more external 5-tuples, as shown in Figure 1. 5-tuple) and one or more external 5-tuples, as shown in Figure 1.
The internal 5-tuple identifies the path between the STUN relay The internal 5-tuple identifies the path between the TURN client and
client and the STUN relay server. It consists of the protocol (UDP, the TURN server. It consists of the protocol (UDP, TCP, or TLS over
TCP, or TLS over TCP), the internal local IP address and port number TCP), the internal local IP address and port number and the source IP
and the source IP address and port number of the STUN client, as seen address and port number of the STUN client, as seen by the relay
by the relay server. For example, for UDP, the internal 5-tuple is server. For example, for UDP, the internal 5-tuple is the
the combination of the IP address and port from which the STUN client combination of the IP address and port from which the STUN client
sent its Allocate Request, with the IP address and port from which sent its Allocate Request, with the IP address and port from which
the corresponding Allocate Response was sent. the corresponding Allocate Response was sent.
The external local transport address is the IP address and port The external local transport address is the IP address and port
allocated to the STUN relay client (the allocated transport address). allocated to the TURN client (the allocated transport address). The
The external 5-tuple is the combination of the external local external 5-tuple is the combination of the external local transport
transport address and the IP address and port of an external client address and the IP address and port of an external client that the
that the STUN client is communicating with through the STUN server. STUN client is communicating with through the STUN server.
Initially, there aren't any external 5-tuples, since the STUN client Initially, there aren't any external 5-tuples, since the STUN client
hasn't communicated with any other hosts yet. As packets are hasn't communicated with any other hosts yet. As packets are
received on or sent from the allocated transport address, external received on or sent from the allocated transport address, external
5-tuples are created. 5-tuples are created.
While the terminology used in this document refers to 5-tuples, While the terminology used in this document refers to 5-tuples,
the STUN relay server can store whatever identifier it likes that the TURN server can store whatever identifier it likes that yields
yields identical results. Specifically, many implementations may identical results. Specifically, many implementations may use a
use a file-descriptor in place of a 5-tuple to represent a TCP file-descriptor in place of a 5-tuple to represent a TCP
connection. connection.
+---------+ +---------+
| | | |
| External| | External|
/ | Client | / | Client |
// | | // | |
/ | | / | |
// +---------+ // +---------+
/ /
skipping to change at page 9, line 50 skipping to change at page 9, line 50
5-Tuple 5-tuple 5-Tuple 5-tuple
Figure 1 Figure 1
4.3. Keepalives 4.3. Keepalives
Since the main purpose of STUN and the relay extension are to Since the main purpose of STUN and the relay extension are to
traverse NATs, it is natural to consider which elements are traverse NATs, it is natural to consider which elements are
responsible for generating sufficient periodic traffic to insure that responsible for generating sufficient periodic traffic to insure that
NAT bindings stay alive. Relay clients need to send data frequently NAT bindings stay alive. Relay clients need to send data frequently
enough to keep both NAT bindings and the STUN relay server internal enough to keep both NAT bindings and the TURN server internal
permissions fresh. Like NAT bindings, the STUN relay server bindings permissions fresh. Like NAT bindings, the TURN server bindings are
are refreshed by ordinary data traffic relayed to and from the peer. refreshed by ordinary data traffic relayed to and from the peer.
Unlike permissions, allocations on the STUN relay server have an Unlike permissions, allocations on the TURN server have an explicit
explicit expiration time and need to be refreshed explicitly by the expiration time and need to be refreshed explicitly by the client.
client. When an allocation expires, all permissions associated with When an allocation expires, all permissions associated with that
that allocation are automatically deleted. allocation are automatically deleted.
5. New Framing Mechanism for Stream-Oriented Transports 5. New Framing Mechanism for Stream-Oriented Transports
Over stream-based transports, the STUN relay client and server need Over stream-based transports, the TURN client and server need to use
to use additional framing so that end-to-end data is distinguishable additional framing so that end-to-end data is distinguishable from
from STUN control messages, and so that the relay server can perform STUN control messages, and so that the TURN server can perform
conversion from streams to datagrams and vice versa. This additional conversion from streams to datagrams and vice versa. This additional
framing has a one octet type, one reserved octet, and a 2 octet framing has a one octet type, one reserved octet, and a 2 octet
length field. The first octet of this framing is 0x02 to indicate length field. The first octet of this framing is 0x02 to indicate
STUN messages or 0x03 to indicate end-to-end data to or from the STUN messages or 0x03 to indicate end-to-end data to or from the
active destination. Note that the first octet is always active destination. Note that the first octet is always
distinguishable from an unframed STUN request or response (which is distinguishable from an unframed STUN request or response (which is
always 0x00 or 0x01). The second octet is reserved and MUST be set always 0x00 or 0x01). The second octet is reserved and MUST be set
to zero. The length field counts the number of octets immediately to zero. The length field counts the number of octets immediately
after the length field itself. after the length field itself.
skipping to change at page 10, line 36 skipping to change at page 10, line 36
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved = 0 | Length | | Type | Reserved = 0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Use of this framing mechanism is discussed in Section 9 and Use of this framing mechanism is discussed in Section 9 and
Section 10. Section 10.
6. New STUN Requests and Indications 6. New STUN Requests and Indications
This usage defines three new requests (along with their success and This document defines three new requests (along with their success
error responses) and three indications. It also defines processing and error responses) and three indications. It also defines
rules for the STUN server and client on receipt of non-STUN messages. processing rules for the STUN server and client on receipt of non-
See Section 9 and Section 10 STUN messages. See Section 9 and Section 10
The new messages are: The new messages are:
Request/Response Transactions Request/Response Transactions
0x003 : Allocate 0x003 : Allocate
0x004 : Set Active Destination 0x004 : Set Active Destination
0x005 : Connect 0x005 : Connect
Indications Indications
0x001 : Send 0x006 : Send
0x002 : Data 0x007 : Data
0x003 : Connect Status 0x008 : Connect Status
In addition to STUN Messages (Requests, Responses, and Indications), In addition to STUN Messages (Requests, Responses, and Indications),
STUN relay clients and servers send and receive non-STUN packets on TURN clients and servers send and receive non-STUN packets on the
the same ports used for STUN messages. How these entities same ports used for STUN messages. How these entities distinguish
distinguish STUN and non-STUN traffic is discussed in Section 9 and STUN and non-STUN traffic is discussed in Section 9 and Section 10.
Section 10.
6.1. Allocate Request 6.1. Allocate Request
6.1.1. Client Behavior 6.1.1. Client Behavior
Client behavior for Allocate requests depends on whether the request Client behavior for Allocate requests depends on whether the request
is an initial one, for the purposes of obtaining a new relayed is an initial one, for the purposes of obtaining a new relayed
transport address, or a subsequent one, used for refreshing an transport address, or a subsequent one, used for refreshing an
existing allocation. existing allocation.
skipping to change at page 11, line 51 skipping to change at page 11, line 50
maximum bandwidth that will be used with this binding. If the maximum bandwidth that will be used with this binding. If the
maximum is unknown, the attribute is not included in the request. maximum is unknown, the attribute is not included in the request.
The client MAY request a particular lifetime for the allocation by The client MAY request a particular lifetime for the allocation by
including it in the LIFETIME attribute in the request. The default including it in the LIFETIME attribute in the request. The default
lifetime is 10 minutes. lifetime is 10 minutes.
The client MAY include a REQUESTED-PORT-PROPS, REQUESTED-TRANSPORT, The client MAY include a REQUESTED-PORT-PROPS, REQUESTED-TRANSPORT,
or REQUESTED-IP attribute in the request to obtain specific types of or REQUESTED-IP attribute in the request to obtain specific types of
transport addresses. Whether these are needed depends on the transport addresses. Whether these are needed depends on the
application using the relay usage. As an example, the Real Time application using the TURN server. As an example, the Real Time
Transport Protocol (RTP) [3] requires that RTP and RTCP ports be an Transport Protocol (RTP) [3] requires that RTP and RTCP ports be an
adajacent pair, even and odd respectively, for compatibility with a adajacent pair, even and odd respectively, for compatibility with a
previous version of that specification. The REQUESTED-PORT-PROPS previous version of that specification. The REQUESTED-PORT-PROPS
attribute allows the client to ask the relay for those properties. attribute allows the client to ask the relay for those properties.
The client MUST NOT request the TCP transport in an Allocate request The client MUST NOT request the TCP transport in an Allocate request
sent to the STUN relay server over UDP. sent to the TURN server over UDP.
Processing of the response follows the general procedures of [1]. A Processing of the response follows the general procedures of [1]. A
successful response will include both a RELAY-ADDRESS and an XOR- successful response will include both a RELAY-ADDRESS and an XOR-
MAPPED-ADDRESS attribute, providing both a relayed transport address MAPPED-ADDRESS attribute, providing both a relayed transport address
and a reflexive transport address, respectively, to the client. The and a reflexive transport address, respectively, to the client. The
server will expire the allocation after LIFETIME seconds have passed server will expire the allocation after LIFETIME seconds have passed
if not refreshed by another Allocate request. The server will allow if not refreshed by another Allocate request. The server will allow
the user to send and receive at least the amount of data indicated in the user to send and receive at least the amount of data indicated in
the BANDWIDTH attribute per allocation. (At its discretion the the BANDWIDTH attribute per allocation. (At its discretion the
server can optionally discard data above this threshold.) server can optionally discard data above this threshold.)
skipping to change at page 13, line 9 skipping to change at page 13, line 8
that an error response does not imply that the binding has been that an error response does not imply that the binding has been
expired, just that the refresh has failed. expired, just that the refresh has failed.
If a client no longer needs an allocation, it SHOULD perform an If a client no longer needs an allocation, it SHOULD perform an
explict deallocation. If the client wishes to explicitly remove the explict deallocation. If the client wishes to explicitly remove the
allocation because it no longer needs it, it generates a subsequent allocation because it no longer needs it, it generates a subsequent
Allocate request, but sets the LIFETIME attribute to zero. This will Allocate request, but sets the LIFETIME attribute to zero. This will
cause the server to remove the allocation, and all associated cause the server to remove the allocation, and all associated
bindings. For connection-oriented transports such as TCP, the client bindings. For connection-oriented transports such as TCP, the client
can also remove the allocation (and all associated bindings) by can also remove the allocation (and all associated bindings) by
closing the relevant connection with the STUN relay server. closing the relevant connection with the TURN server.
6.1.2. Server Behavior 6.1.2. Server Behavior
The server first processes the request according to the general The server first processes the request according to the general
request processing rules in [1]. This includes performing request processing rules in [1]. This includes performing
authentication, and checking for mandatory unknown attributes. Due authentication, and checking for mandatory unknown attributes. Due
to the fact that the STUN server is allocating resources for to the fact that the STUN server is allocating resources for
processing the request, Allocate requests MUST be authenticated, and processing the request, Allocate requests MUST be authenticated, and
furthermore, MUST be authenticated using either a shared secret known furthermore, MUST be authenticated using either a shared secret known
between the client and server, or a short term password derived from between the client and server, or a short term password derived from
it. it.
Note that Allocate requests, like most other STUN requests, can be Note that Allocate requests, like most other STUN requests, can be
sent to the STUN server over UDP, TCP, or TCP/TLS. sent to the TURN server over UDP, TCP, or TCP/TLS.
The behavior of the server when receiving an Allocate Request depends The behavior of the server when receiving an Allocate Request depends
on whether the request is an initial one, or a subsequent one. An on whether the request is an initial one, or a subsequent one. An
initial request is one whose source and destination transport address initial request is one whose source and destination transport address
do not match the internal remote and local transport addresses of an do not match the internal remote and local transport addresses of an
existing internal 5-tuple. A subsequent request is one whose source existing internal 5-tuple. A subsequent request is one whose source
and destination transport address matches the internal remote and and destination transport address matches the internal remote and
local transport address of an existing internal 5-tuple. local transport address of an existing internal 5-tuple.
6.1.2.1. Initial Requests 6.1.2.1. Initial Requests
skipping to change at page 15, line 40 skipping to change at page 15, line 40
is accomplished using the 300 error response and ALTERNATE-SERVER is accomplished using the 300 error response and ALTERNATE-SERVER
attribute. If the server does not redirect and cannot service the attribute. If the server does not redirect and cannot service the
request because the server has reached capacity, it sends a 507 request because the server has reached capacity, it sends a 507
(Insufficient Capacity) response. The server can also reject the (Insufficient Capacity) response. The server can also reject the
request with a 486 (Allocation Quota Reached) if the user or client request with a 486 (Allocation Quota Reached) if the user or client
is not authorized to request additional allocations. is not authorized to request additional allocations.
The server SHOULD only allocate ports in the range 1024-65535. This The server SHOULD only allocate ports in the range 1024-65535. This
is one of several ways to prohibit relayed transport addresses from is one of several ways to prohibit relayed transport addresses from
being used to attempt to run standard services. These guidelines are being used to attempt to run standard services. These guidelines are
meant to be consistent with [10], since the relay is effectively a meant to be consistent with [9], since the relay is effectively a
NAT. NAT.
Once the port is allocated, the server associates it with the Once the port is allocated, the server associates it with the
internal 5-tuple and fills in that 5-tuple. The internal remote internal 5-tuple and fills in that 5-tuple. The internal remote
transport address of the internal 5-tuple is set to the source transport address of the internal 5-tuple is set to the source
transport address of the Allocate Request. The internal local transport address of the Allocate Request. The internal local
transport address of the internal 5-tuple is set to the destination transport address of the internal 5-tuple is set to the destination
transport address of the Allocate Request. For TCP, this amounts to transport address of the Allocate Request. For TCP, this amounts to
associating the TCP connection from the STUN relay client with the associating the TCP connection from the TURN client with the
allocated transport address. allocated transport address.
If the Allocate request was authenticated using a shared secret If the Allocate request was authenticated using a shared secret
between the client and server, this credential MUST be associated between the client and server, this credential MUST be associated
with the allocation. If the request was authenticated using a short with the allocation. If the request was authenticated using a short
term password derived from a shared secret, that shared secret MUST term password derived from a shared secret, that shared secret MUST
be associated with the allocation. This is used in all subsequent be associated with the allocation. This is used in all subsequent
requests and indications to ensure that only the same client can use requests and indications to ensure that only the same client can use
or modify the allocation it was given. or modify the allocation it was given.
The allocation created by the Allocate request is also associated The allocation created by the Allocate request is also associated
with a transport address, called the active destination. This with a transport address, called the active destination. This
transport address is used for forwarding data through the STUN relay transport address is used for forwarding data through the TURN
server, and is described in more detail later. It is initially set server, and is described in more detail later. It is initially set
to null when the allocation is created. In addition, the allocation to null when the allocation is created. In addition, the allocation
created by the server is associated with a set of permissions. Each created by the server is associated with a set of permissions. Each
permission is a specific IP address identifying an external client. permission is a specific IP address identifying an external client.
Initially, this list is null. Initially, this list is null.
If the LIFETIME attribute was present in the request, and the value 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 is larger than the maximum duration the server is willing to use for
the lifetime of the allocation, the server MAY lower it to that the lifetime of the allocation, the server MAY lower it to that
maximum. However, the server MUST NOT increase the duration maximum. However, the server MUST NOT increase the duration
skipping to change at page 17, line 40 skipping to change at page 17, line 40
some aspect of the request, the server MUST free the previous some aspect of the request, the server MUST free the previous
allocation and allocate a new request to the client. allocation and allocate a new request to the client.
Finally, a subsequent Allocate request will set a new allocation Finally, a subsequent Allocate request will set a new allocation
expiration timer for the allocation, effectively canceling the expiration timer for the allocation, effectively canceling the
previous lifetime expiration timer. previous lifetime expiration timer.
6.2. Procedures for all other Requests and Indications 6.2. Procedures for all other Requests and Indications
Other than initial Allocate Requests, all requests and indications Other than initial Allocate Requests, all requests and indications
defined by the relay usage need to be sent in the context of a valid defined in this document need to be sent in the context of a valid
allocation. The source and destination IP address and ports for allocation. The source and destination IP address and ports for
these STUN messages MUST match the internal 5-tuple of an existing these STUN messages MUST match the internal 5-tuple of an existing
allocation. These processed using the general server procedures in allocation. These processed using the general server procedures in
[1] with a few important additions. For requests, if there is no [1] with a few important additions. For requests, if there is no
matching allocation, the server MUST generate a 437 (No Binding) Send matching allocation, the server MUST generate a 437 (No Binding) Send
Error Response. For indications, if there is no matching allocation, Error Response. For indications, if there is no matching allocation,
the indication is silently discarded. the indication is silently discarded.
All requests and indications MUST be authenticated using the same All requests and indications MUST be authenticated using the same
shared secret as the one associated with the allocation, or be shared secret as the one associated with the allocation, or be
skipping to change at page 18, line 18 skipping to change at page 18, line 18
6.3. Set Active Destination Request 6.3. Set Active Destination Request
6.3.1. Client Behavior 6.3.1. Client Behavior
The Set Active Destination request allows the client to create an The Set Active Destination request allows the client to create an
optimized relay function between the client and the server. When the optimized relay function between the client and the server. When the
server receives packets from a particular preferred external peer, server receives packets from a particular preferred external peer,
the server will forward those packets towards the client without the server will forward those packets towards the client without
encapsulating them in a Data Indication. Similarly, the client can encapsulating them in a Data Indication. Similarly, the client can
send non-STUN packets to the server without encapsulation, and these send non-STUN packets to the server without encapsulation in a Send
are forwarded to the external peer. Sending and receiving data in Indication, and these packets are forwarded to the external peer.
unencapsulated form is critical for efficiency purposes. One of the Sending and receiving data in unencapsulated form is critical for
primary use cases for the STUN relay usage is in support of Voice efficiency purposes. One of the primary use cases for the STUN relay
over IP (VoIP), which uses very small UDP packets to begin with. The extensions is in support of Voice over IP (VoIP), which uses very
extra overhead of an additional layer of encapsulation is considered small UDP packets to begin with. The extra overhead of an additional
unacceptable. layer of encapsulation is considered unacceptable.
The Set Active Destination request is used by the client to provide The Set Active Destination request is used by the client to provide
the identity of this preferred external peer. The Set Active the identity of this preferred external peer. The Set Active
Destination address MAY contain a REMOTE-ADDRESS attribute. This Destination address MAY contain a REMOTE-ADDRESS attribute. This
attribute, when present, provides the address of the preferred attribute, when present, provides the address of the preferred
external peer to the server. When absent, it clears the value of the external peer to the server. When absent, it clears the value of the
preferred external peer. As a convenience, if the client sets the preferred external peer. As a convenience, if the client sets the
REMOTE-ADDRESS attribute to a peer without a permission, the server REMOTE-ADDRESS attribute to a peer without a permission, the server
will add the corresponding permission. will add the corresponding permission.
The client MUST NOT send a Set Active Destination request with a The client MUST NOT send a Set Active Destination request with a
REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an
active destination is already set for that allocation. If the client active destination is already set for that allocation. If the client
wishes to set a new active destination, it MUST wait until 5 seconds wishes to set a new active destination, it MUST wait until a
after a successful response is received to a Set Destination Request successful response is received to a Set Destination Request removing
removing the active destination. Failure to wait could cause the the active destination. The client SHOULD then continue to wait for
client to receive and attribute late data forwarded by the STUN relay an additional period of up to 5 seconds until it is extremely
server to the wrong peer. unlikely that any data from the previous active destination might
still arrive. Failure to wait could cause the client to receive and
attribute late data forwarded by the TURN server to the wrong peer.
The client MAY wait a shorter period of time if the application has
built-in addressing (such as the RTP [3] Sender Source) that makes it
unlikely the client would incorrectly attribute late data. [OPEN
ISSUE: is this OK with the WG? ]
Consider the case where the active destination is set, and the Consider the case where the active destination is set, and the
server is relaying packets towards the client. The client knows server is relaying packets towards the client. The client knows
the IP address and port where the packets came from - the current the IP address and port where the packets came from - the current
value of the active destination. The client issues a Set Active value of the active destination. The client issues a Set Active
Destination Request to change the active destination, and receives Destination Request to change the active destination, and receives
a response. A moment later, a data packet is received, not a response. A moment later, a data packet is received, not
encapsulated in a STUN Data Indication. What is the source if encapsulated in a STUN Data Indication. What is the source if
this packet? Is it the active destination that existed prior to this packet? Is it the active destination that existed prior to
the Set Active Destination request, or the one after? If the the Set Active Destination request, or the one after? If the
transport between the client and the STUN server is not reliable, transport between the client and the STUN server is not reliable,
skipping to change at page 20, line 22 skipping to change at page 20, line 34
attempt is returned via the Connect Status Indication. attempt is returned via the Connect Status Indication.
Note that the server needs to use the same source connection Note that the server needs to use the same source connection
address for all connections/permissions associated with an address for all connections/permissions associated with an
allocation. For servers written using Berkeley sockets, the allocation. For servers written using Berkeley sockets, the
SO_REUSEADDR flag is typically used to use the same local address SO_REUSEADDR flag is typically used to use the same local address
with multiple sockets. with multiple sockets.
6.5. Connection Status Indication 6.5. Connection Status Indication
TODO: Expand this text. When the TURN to peer leg is TCP, the TURN client needs to be aware
of the status of these TCP connections. The TURN extension defines
When the STUN relay to peer leg is TCP, the STUN relay client needs application states for a TCP connection as follows: LISTEN,
to be aware of the status of these TCP connections. The STUN relay ESTABLISHED, CLOSED. Consequently, the TURN server sends a
extension defines application states for a TCP connection as follows: Connection State Indication for a TCP permission whenever the relay
LISTEN, ESTABLISHED, CLOSED. Consequently, the STUN relay server connection status changes for one of the client's permissions except
sends a Connection State Indication for a TCP permission whenever the when the status changes due to a TURN client request (ex: an explicit
relay connection status changes for one of the client's permissions binding close or deallocation).
except when the status changes due to a STUN relay client request
(ex: an explicit binding close or deallocation).
A STUN relay can only relay to a peer over TCP if the client A TURN can only relay to a peer over TCP if the client
communicates with the server over TCP or TLS over TCP. Because of communicates with the server over TCP or TLS over TCP. Because of
this, the server can be assured that Connection Status Indications this, the server can be assured that Connection Status Indications
are received reliably. are received reliably.
6.6. Send Indication 6.6. Send Indication
6.6.1. Client Behavior 6.6.1. Client Behavior
The Send Indication is used to ask the relay to forward data to a The Send Indication is used to ask the relay to forward data to a
peer. It is typically used to send to a peer other than the active peer. It is typically used to send to a peer other than the active
destination. For TCP allocated transport addresses, the client needs destination. For TCP allocated transport addresses, the client needs
to wait for the peer to open a connection to the STUN relay server to wait for the peer to open a connection to the TURN server before
before it can send data. Data sent with a Send request prior to the it can send data. Data sent with a Send request prior to the opening
opening of a TCP connection is discarded silently by the server. of a TCP connection is discarded silently by the server.
The Send Indication MUST contain a REMOTE-ADDRESS attribute, which The Send Indication MUST contain a REMOTE-ADDRESS attribute, which
contains the IP address and port that the data is being sent to. The contains the IP address and port that the data is being sent to. The
DATA attribute MAY be present, and contains the data that is to be DATA attribute MAY be present, and contains the data that is to be
sent towards REMOTE-ADDRESS. If absent, the server will send an sent towards REMOTE-ADDRESS. If absent, the server will send an
empty UDP packet in the case of UDP. In the case of TCP, the server empty UDP packet in the case of UDP. In the case of TCP, the server
will do nothing. will do nothing.
Since Send is an Indication, it generates no response. The client Since Send is an Indication, it generates no response. The client
must rely on application layer mechanisms to determine if the data must rely on application layer mechanisms to determine if the data
skipping to change at page 22, line 14 skipping to change at page 22, line 27
is not the active destination, this data is relayed towards the is not the active destination, this data is relayed towards the
client in encapsulated form using the Data Indication. client in encapsulated form using the Data Indication.
The Data Indication contains two attributes - DATA and REMOTE- The Data Indication contains two attributes - DATA and REMOTE-
ADDRESS. The REMOTE-ADDRESS attribute indicates the source transport ADDRESS. The REMOTE-ADDRESS attribute indicates the source transport
address that the request came from, and it will equal the external address that the request came from, and it will equal the external
remote transport address of the external peer. When processing this remote transport address of the external peer. When processing this
data, a client MUST treat the data as if it came from this address, data, a client MUST treat the data as if it came from this address,
rather than the stun server itself. The DATA attribute contains the rather than the stun server itself. The DATA attribute contains the
data from the UDP packet or TCP segment that was received. Note that data from the UDP packet or TCP segment that was received. Note that
the STUN relay server will not retransmit this indication over UDP. the TURN server will not retransmit this indication over UDP.
Note that Data Indications are not authenticated and do not Note that Data Indications are not authenticated and do not
contain a MESSAGE-INTEGRITY attribute. Just like non-relayed data contain a MESSAGE-INTEGRITY attribute. Just like non-relayed data
sent over UDP or TCP, the authenticity and integrity of this data sent over UDP or TCP, the authenticity and integrity of this data
can only be assured using security mechanisms at higher layers. can only be assured using security mechanisms at higher layers.
6.7.2. Server Behavior 6.7.2. Server Behavior
A server MUST send data packets towards the client using a Data A server MUST send data packets towards the client using a Data
Indication under the conditions described in Section 10.1. Data Indication under the conditions described in Section 10.1. Data
Indications MUST contain a DATA attribute containing the data to Indications MUST contain a DATA attribute containing the data to
send, and MUST contain a REMOTE-ADDRESS attribute indicating where send, and MUST contain a REMOTE-ADDRESS attribute indicating where
the data came from. the data came from.
7. New Attributes 7. New Attributes
The STUN relay usage defines the following new attributes: This STUN extension defines the following new attributes:
0x000D: LIFETIME 0x000D: LIFETIME
0x0010: BANDWIDTH 0x0010: BANDWIDTH
0x0012: REMOTE-ADDRESS 0x0012: REMOTE-ADDRESS
0x0013: DATA 0x0013: DATA
0x0016: RELAY-ADDRESS 0x0016: RELAY-ADDRESS
0x0018: REQUESTED-PORT-PROPS 0x0018: REQUESTED-PORT-PROPS
0x0019: REQUESTED-TRANSPORT 0x0019: REQUESTED-TRANSPORT
0x0022: REQUESTED-IP 0x0022: REQUESTED-IP
0x0021: TIMER-VAL 0x0021: TIMER-VAL
skipping to change at page 23, line 22 skipping to change at page 23, line 40
kbits per second, that the client expects to use on the binding in kbits per second, that the client expects to use on the binding in
each direction. each direction.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth | | Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.3. REMOTE-ADDRESS 7.3. REMOTE-ADDRESS
The REMOTE-ADDRESS specifies the address and port of the peer as seen The REMOTE-ADDRESS specifies the address and port of the peer as seen
from the STUN relay server. It is encoded in the same way as MAPPED- from the TURN server. It is encoded in the same way as MAPPED-
ADDRESS. ADDRESS.
7.4. DATA 7.4. DATA
The DATA attribute is present in Send Indications and Data The DATA attribute is present in Send Indications and Data
Indications. It contains raw payload data that is to be sent (in the Indications. It contains raw payload data that is to be sent (in the
case of a Send Request) or was received (in the case of a Data case of a Send Request) or was received (in the case of a Data
Indication). It is padded with zeros if its length is not divisible Indication). It is padded with zeros if its length is not divisible
evenly by 4 octets evenly by 4 octets
skipping to change at page 24, line 51 skipping to change at page 25, line 19
unsigned integer. Its values are: unsigned integer. Its values are:
0x0000 0000: UDP 0x0000 0000: UDP
0x0000 0001: TCP 0x0000 0001: TCP
If an Allocate request is sent over TCP and requests a UDP If an Allocate request is sent over TCP and requests a UDP
allocation, or an Allocate request is sent over TLS over TCP and allocation, or an Allocate request is sent over TLS over TCP and
requests a UDP or TCP allocation, the server will relay data between requests a UDP or TCP allocation, the server will relay data between
the two transports. the two transports.
Extensions to the relay usage can define additional transport Extensions to TURN can define additional transport protocols in an
protocols in an IETF-consensus RFC. IETF-consensus RFC.
7.8. REQUESTED-IP 7.8. REQUESTED-IP
The REQUESTED-IP attribute is used by the client to request that a The REQUESTED-IP attribute is used by the client to request that a
specific IP address be allocated to it. This attribute is needed specific IP address be allocated to it. This attribute is needed
since it is anticipated that STUN relays will be multi-homed so as to since it is anticipated that TURN servers will be multi-homed so as
be able to allocate more than 64k transport addresses. As a to be able to allocate more than 64k transport addresses. As a
consequence, a client needing a second transport address on the same consequence, a client needing a second transport address on the same
interface as a previous one can make that request. interface as a previous one can make that request.
The format of this attribute is identical to MAPPED-ADDRESS. The format of this attribute is identical to MAPPED-ADDRESS.
However, the port component of the attribute is ignored by the However, the port component of the attribute is ignored by the
server. If a client wishes to request a specific IP address and server. If a client wishes to request a specific IP address and
port, it uses both the REQUESTED-IP and REQUESTED-PORT-PROPS port, it uses both the REQUESTED-IP and REQUESTED-PORT-PROPS
attributes. attributes.
7.9. CONNECT_STAT 7.9. CONNECT_STAT
This attribute us used by the server to convey the status of server- This attribute is used by the server to convey the status of server-
to-peer connections. It is a 32 bit unsigned integer. Its values to-peer connections. It is a 32 bit unsigned integer. Its values
are: are:
0x0000 0000: LISTEN 0x0000 0000: LISTEN
0x0000 0001: ESTABLISHED 0x0000 0001: ESTABLISHED
0x0000 0002: CLOSED 0x0000 0002: CLOSED
8. New Error Response Codes 8. New Error Response Codes
The STUN relay usage defines the following new Error response codes: This document defines the following new Error response codes:
437 (No Binding): A request was received by the server that 437 (No Binding): A request was received by the server that
requires an allocation to be in place. However, there is none yet requires an allocation to be in place. However, there is none yet
in place. in place.
439 (Active Destination Already Set): A Set Active Destination 439 (Active Destination Already Set): A Set Active Destination
request was received by the server over UDP. However, the active request was received by the server over UDP. However, the active
destination is already set to another value. The client should destination is already set to another value. The client should
reset the active destination, wait for 5 seconds and set the reset the active destination, wait for the hold-down period, and
active destination to the new value. set the active destination to the new value.
442 (Unsupported Transport Protocol): The Allocate request asked 442 (Unsupported Transport Protocol): The Allocate request asked
for a transport protocol to be allocated that is not supported by for a transport protocol to be allocated that is not supported by
the server. the server.
443 (Invalid IP Address): The Allocate request asked for a 443 (Invalid IP Address): The Allocate request asked for a
transport address to be allocated from a specific IP address that transport address to be allocated from a specific IP address that
is not valid on the server. is not valid on the server.
444 (Invalid Port): The Allocate request asked for a port to be 444 (Invalid Port): The Allocate request asked for a port to be
skipping to change at page 26, line 33 skipping to change at page 26, line 51
507 (Insufficient Capacity): The server cannot allocate a new port 507 (Insufficient Capacity): The server cannot allocate a new port
for this client as it has exhausted its relay capacity. for this client as it has exhausted its relay capacity.
9. Client Procedures 9. Client Procedures
9.1. Receiving and Sending Unencapsulated Data 9.1. Receiving and Sending Unencapsulated Data
Once the active destination has been set, a client will receive both Once the active destination has been set, a client will receive both
STUN and non-STUN data on the socket on which the Allocate Request STUN and non-STUN data on the socket on which the Allocate Request
was sent. The encapsulation behavior depends on the transport was sent. The encapsulation behavior depends on the transport
protocol used between the STUN client and the STUN relay server. protocol used between the STUN client and the TURN server.
9.1.1. Datagram Protocols 9.1.1. Datagram Protocols
If the allocation was over UDP, datagrams which contain the STUN If the allocation was over UDP, datagrams which contain the STUN
magic cookie are treated as STUN requests. All other data is non- magic cookie are treated as STUN requests. All other data is non-
STUN data, which MUST be processed as if it had a source IP address STUN data, which MUST be processed as if it had a source IP address
and port equal to the value of the active destination. and port equal to the value of the active destination.
If the client wants to send data to the peer which contains the magic If the client wants to send data to the peer which contains the magic
cookie in the same location as a STUN request, it MUST send that data cookie in the same location as a STUN request, it MUST send that data
skipping to change at page 27, line 13 skipping to change at page 27, line 31
destination is set, the client can send data to that destination at destination is set, the client can send data to that destination at
any time by using the Send Indication. any time by using the Send Indication.
9.1.2. Stream Transport Protocols 9.1.2. Stream Transport Protocols
If the allocation was over TCP or TLS over TCP, the client will If the allocation was over TCP or TLS over TCP, the client will
receive data framed as described in Section 5. The client MUST treat receive data framed as described in Section 5. The client MUST treat
data encapsulated as data with this framing as if it originated from data encapsulated as data with this framing as if it originated from
the active destination. the active destination.
For the STUN relay usage, the client always sends data encapsulated For the any of the methods defined in this document, the client
using this framing scheme. It SHOULD frame data to the active always sends data encapsulated using this framing scheme. It SHOULD
destination as data or it MAY place the data inside a Send frame data to the active destination as data or it MAY place the data
Indications and frame this as STUN traffic. inside a Send Indications and frame this as STUN traffic.
10. Server Procedures 10. Server Procedures
Besides the processing of the request and indications described Besides the processing of the request and indications described
above, this specification defines rules for processing of data above, this specification defines rules for processing of data
packets received by the STUN server. There are two cases - receipt packets received by the STUN server. There are two cases - receipt
of any packets on an allocated address, and receipt of non-STUN data of any packets on an allocated address, and receipt of non-STUN data
on its internal local transport address. on its internal local transport address.
10.1. Receiving Data on Allocated Transport Addresses 10.1. Receiving Data on Allocated Transport Addresses
10.1.1. TCP Processing 10.1.1. TCP Processing
If a server receives a TCP connection request on an allocated TCP If a server receives a TCP connection request on an allocated TCP
transport address, it checks the permissions associated with that transport address, it checks the permissions associated with that
allocation. If the source IP address of the TCP SYN packet matches allocation. If the source IP address of the TCP SYN packet matches
one of the permissions, the TCP connection is accepted. Otherwise, one of the permissions (the source port does not need to match), the
it is rejected. When a TCP connection is accepted, the server sends TCP connection is accepted. Otherwise, it is rejected. When a TCP
the corresponding client a Connect Status Indication with the connection is accepted, the server sends the corresponding client a
CONNECT_STAT attribute set to ESTABLISHED. No information is passed Connect Status Indication with the CONNECT_STAT attribute set to
to the client if the server rejects the connection because there is ESTABLISHED. No information is passed to the client if the server
no corresponding permission. rejects the connection because there is no corresponding permission.
If a server receives data on a TCP connection that terminates on the If a server receives data on a TCP connection that terminates on the
allocated TCP transport address, the server checks the value of the allocated TCP transport address, the server checks the value of the
active destination. If it equals the source IP address and port of active destination. If it equals the source IP address and port of
the data packet (in other words, if the active destination identifies the data packet (in other words, if the active destination identifies
the other side of the TCP connection), the data is taken from the TCP the other side of the TCP connection), the data is taken from the TCP
connection and sent towards the client in unencapsulated form. connection and sent towards the client in unencapsulated form.
Otherwise, the data is sent towards the client in a Data Indication, Otherwise, the data is sent towards the client in a Data Indication,
also known as encapsulated form. In this form, the server MUST add a also known as encapsulated form. In this form, the server MUST add a
REMOTE-ADDRESS which corresponds to the external remote transport REMOTE-ADDRESS which corresponds to the external remote transport
address of the TCP connection, and MUST add a DATA attribute address of the TCP connection, and MUST add a DATA attribute
containing the data received on the TCP connection. containing the data received on the TCP connection.
Note that, because data is forwarded blindly across TCP bindings, Note that, because data is forwarded blindly across TCP bindings,
TLS will successfully operate over a STUN relay allocated TCP port TLS will successfully operate over a TURN allocated TCP port if
if the linkage to the client is also TCP. the linkage to the client is also TCP.
10.1.2. UDP Processing 10.1.2. UDP Processing
If a server receives a UDP packet on an allocated UDP transport If a server receives a UDP packet on an allocated UDP transport
address, it checks the permissions associated with that allocation. address, it checks the permissions associated with that allocation.
If the source IP address of the UDP packet matches one of the If the source IP address of the UDP packet matches one of the
permissions, the UDP packet is accepted. Otherwise, it is discarded. permissions (the source port does not need to match), the UDP packet
If the packet is accepted, it is forwarded to the client. It will be is accepted. Otherwise, it is discarded. If the packet is accepted,
forwarded in either encapsulated or unencapsulated form. it is forwarded to the client. It will be forwarded in either
encapsulated or unencapsulated form.
If the client to server communication is via UDP, the server looks If the client to server communication is via UDP, the server looks
for the existence of the STUN magic cookie in the data received from for the existence of the STUN magic cookie in the data received from
the peer. If the data contains the magic cookie, the server the peer. If the data contains the magic cookie, the server
encapsulates the data in a Data Indication, sets the REMOTE_ADDRESS encapsulates the data in a Data Indication, sets the REMOTE_ADDRESS
attribute, and forwards the indication to the client. If the magic attribute, and forwards the indication to the client. If the magic
cookie is not present, the server checks if the peer is the active cookie is not present, the server checks if the peer is the active
destination. If so the data is forwarded unencapsulated, directly to destination. If so the data is forwarded unencapsulated, directly to
the client. Otherwise the server encapsulates the data in a Data the client. Otherwise the server encapsulates the data in a Data
Indication, sets the REMOTE_ADDRESS and forwards to the client. Indication, sets the REMOTE_ADDRESS and forwards to the client.
skipping to change at page 28, line 44 skipping to change at page 29, line 14
connection to the client. If the TCP connection generates an error connection to the client. If the TCP connection generates an error
(because, for example, the incoming UDP packet rate exceeds the (because, for example, the incoming UDP packet rate exceeds the
throughput of the TCP connection), the data is discarded silently by throughput of the TCP connection), the data is discarded silently by
the server. the server.
10.2. Receiving Data on Internal Local Transport Addresses 10.2. Receiving Data on Internal Local Transport Addresses
If a server receives non-STUN UDP data from the client on its If a server receives non-STUN UDP data from the client on its
internal local transport address, and it is coming from an internal internal local transport address, and it is coming from an internal
remote transport address associated with an existing allocation, it remote transport address associated with an existing allocation, it
represents UDP data that the client wishes to forward. If the active represents UDP data that the client wishes to forward. If there is
destination is not set, the server MUST discard the packet. If the no allocation associated with the source IP address and port number,
active destination is set, the server places the data from the client or if there is an associated allocation but the active destination is
in a UDP payload, and sets the destination address and port to the not set, the server MUST discard the packet. If the active
active destination. The UDP packet is then sent with a source IP destination is set, the server places the data from the client in a
address and port equal to the allocated transport address. Note that UDP payload, and sets the destination address and port to the active
the server will not retransmit the UDP datagram. destination. The UDP packet is then sent with a source IP address
and port equal to the allocated transport address. Note that the
server will not retransmit the UDP datagram.
If a server receives framed data on a TCP connection from a client, If a server receives framed data on a TCP connection from a client,
the server retrieves the allocation bound to that connection. If the the server retrieves the allocation bound to that connection. If the
active destination for the allocation is not set, the server MUST active destination for the allocation is not set, the server MUST
discard the data and close the connection. If the active destination discard the data and close the connection. If the active destination
is set, and the allocated transport protocol is TCP, the server is set, and the allocated transport protocol is TCP, the server
forwards the data over the connection to the active destination. The forwards the data over the connection to the active destination. The
data is then sent over that connection. If the connection is not data is then sent over that connection. If the connection is not
established or if the transmission fails due to a TCP error, the data established or if the transmission fails due to a TCP error, the data
is discarded silently by the server. If the active destination is is discarded silently by the server. If the active destination is
skipping to change at page 29, line 40 skipping to change at page 30, line 13
connections from the allocated transport address to external peers connections from the allocated transport address to external peers
(applicable only when the allocated transport address was TCP), and (applicable only when the allocated transport address was TCP), and
then freeing the allocated transport address (and all associated then freeing the allocated transport address (and all associated
state maintained by the server) for use by other clients. A state maintained by the server) for use by other clients. A
suggested value for the allocation expiration timer is 10 minutes. suggested value for the allocation expiration timer is 10 minutes.
The server is also expected to run a permission inactivity timer for The server is also expected to run a permission inactivity timer for
each permission associated with an Allocation. If no traffic from each permission associated with an Allocation. If no traffic from
the client is received, the permission inactivity timer will the client is received, the permission inactivity timer will
eventually expire and the server MUST delete the permission. A eventually expire and the server MUST delete the permission. A
suggested value for the permission inactivity timer is 60 seconds. suggested value for the permission inactivity timer for UDP
allocations is 60 seconds.
11. Formal Definition of STUN Usage
11.1. Applicability Statement
STUN requires all usages to define the applicability of the usage
[1]. This section contains that information for the relay usage.
The relayed transport address obtained from the Allocate request has
specific properties which limit its applicability. The transport
address will only be 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
small number of hosts (typically one). Data from the peer is only
relayed to the client after the client sends packets towards the
peer. Because of this limitation, relayed transport addresses
obtained from an Allocate request are only useful when combined with
rendezvous protocols of some sort, which allow the client to discover
the addresses of the hosts it will be corresponding with. Examples
of such protocols include the Session Initiation Protocol (SIP) [4].
This limitation is purposeful. Relayed transport addresses obtained
from the Allocate request can not be used to run general purpose
servers, such as a web or email server. This means that the relay
usage can be safely permitted to pass through NATs and firewalls
without fear of compromising the purpose of having them there in the
first place. Indeed, a relayed transport address obtained from a
STUN relay has many of the properties of a transport address obtained
from a NAT whose filtering policies are address dependent, but whose
mapping properties are endpoint independent [10], and thus "good"
NATs. Indeed, to some degree, the relay turns a bad NAT into a good
NAT by, quite ironically, adding another NAT function - the relay
itself.
11.2. Client Discovery of Server
STUN requires all usages to define the mechanism by which a client
discovers the server [1]. This section contains that information for
the relay usage.
The relay usage differs from the other usages defined in [1] in that
it demands substantial resources from the STUN server. In addition,
it seems likely that administrators might want to block connections
from clients to the STUN server for relaying separately from
connections for the purposes of binding discovery. As a consequence,
the relay usage is expected to typically run on a separate port from
other usages. The client discovers the address and port of the STUN
server for the relay usage using the same DNS procedures defined in
[1], but using an SRV service name of "stun-relay" instead of just
"stun".
For example, to find STUN relay servers in the example.com domain,
the STUN relay client performs a lookup for '_stun-
relay._udp.example.com', '_stun-relay._tcp.example.com', and '_stun-
relay._tls.example.com' if the STUN client wants to communicate with
the STUN relay server using UDP, TCP, or TLS over TCP, respectively.
The client assumes that all permissable transport protocols are
supported from the STUN relay server to the peer for the client to
server protocol selected.
11.3. Server Determination of Usage 11. Client Discovery of TURN Servers
STUN requires all usages to define the mechanism by which the server The STUN relay extensions differ from the binding requests defined in
determines the usage [1]. This section contains that information for [1] in that they demands substantial resources from the STUN server.
the relay usage. In addition, it seems likely that administrators might want to block
connections from clients to the STUN server for relaying separately
from connections for the purposes of binding discovery. As a
consequence, TURN is expected to typically run on a separate port
from basic STUN. The client discovers the address and port of the
TURN server using the same DNS procedures defined in [1], but using
an SRV service name of "stun-relay" instead of just "stun".
The STUN server is designed so the relay usage can run on a separate For example, to find TURN servers in the example.com domain, the TURN
source port from non-relay usages. Since the client looks up the client performs a lookup for '_stun-relay._udp.example.com', '_stun-
port number for the relay usage separately, servers can be configured relay._tcp.example.com', and '_stun-relay._tls.example.com' if the
to rely on this property. The STUN server MAY accept both relay and STUN client wants to communicate with the TURN server using UDP, TCP,
non-relay usages on the same port number, in which case it uses or TLS over TCP, respectively. The client assumes that all
framing hints and choice of STUN messages to detect the STUN usage in permissable transport protocols are supported from the TURN server to
use by a specific client. the peer for the client to server protocol selected.
The relay usage is defined by a specific set of requests and The STUN server is designed so the relay usage can run on a
indications. As a consequence, the server knows that this usage is separate source port from non-relay usages. Since the client
being used because those request and indications were used. Over looks up the port number for the relay usage separately, servers
UDP, once an active destination has been set, the server also needs can be configured to rely on this property. The STUN server MAY
to check the source address and port of a datagram to determine if accept both relay and non-relay usages on the same port number, in
that source tuple is allocated for the relay usage. For stream-based which case it uses framing hints and choice of STUN messages to
protocols, the server can recognize STUN relay traffic from other detect the STUN usage in use by a specific client.
usages, since STUN relay traffic on these transports always uses the
framing described in the next section (Section 5).
12. Security Considerations 12. Security Considerations
TODO: Need to spend more time on this. STUN servers implementing the TURN extensions allocate bandwidth and
port resources to clients, in contrast to the Binding method defined
STUN servers implementing this relay usage allocate bandwidth and in [1]. Therefore, a STUN server providing the relay usage requires
port resources to clients, in contrast to the usages defined in [1].
Therefore, a STUN server providing the relay usage requires
authentication and authorization of STUN requests. This authentication and authorization of STUN requests. This
authentication is provided by mechanisms defined in the STUN authentication is provided by mechanisms defined in the STUN
specification itself. In particular, digest authentication and the specification itself. In particular, digest authentication and the
usage of short-term passwords, obtained through a digest exchange usage of short-term passwords, obtained through a digest exchange
over TLS, are available. The usage of short-tem passwords ensures over TLS, are available. The usage of short-term passwords ensures
that the Allocate Requests, which often do not run over TLS, are not that the Allocate Requests, which often do not run over TLS, are not
susceptible to offline dictionary attacks that can be used to guess susceptible to offline dictionary attacks that can be used to guess
the long lived shared secret between the client and the server. the long lived shared secret between the client and the server.
Because STUN servers implementing the relay usage allocate resources, Because TURN servers allocate resources, they can be susceptible to
they can be susceptible to denial-of-service attacks. All Allocate denial-of-service attacks. All Allocate Requests are authenticated,
Requests are authenticated, so that an unknown attacker cannot launch so that an unknown attacker cannot launch an attack. An
an attack. An authenticated attacker can generate multiple Allocate authenticated attacker can generate multiple Allocate Requests,
Requests, however. To prevent a single malicious user from however. To prevent a single malicious user from allocating all of
allocating all of the resources on the server, it is RECOMMENDED that the resources on the server, it is RECOMMENDED that a server
a server implement a modest per user cap on the amount of bandwidth implement a modest per user cap on the amount of bandwidth that can
that can be allocated. Such a mechanism does not prevent a large be allocated. Such a mechanism does not prevent a large number of
number of malicious users from each requesting a small number of malicious users from each requesting a small number of allocations.
allocations. Attacks as these are possible using botnets, and are Attacks as these are possible using botnets, and are difficult to
difficult to detect and prevent. Implementors of the STUN relay detect and prevent. Implementors of TURN should keep up with best
usage should keep up with best practices around detection of practices around detection of anomalous botnet attacks.
anomalous botnet attacks.
A client will use the transport address learned from the RELAY- A client will use the transport address learned from the RELAY-
ADDRESS attribute of the Allocate Response to tell other users how to ADDRESS attribute of the Allocate Response to tell other users how to
reach them. Therefore, a client needs to be certain that this reach them. Therefore, a client needs to be certain that this
address is valid, and will actually route to them. Such validation address is valid, and will actually route to them. Such validation
occurs through the message integrity checks provided in the Allocate occurs through the message integrity checks provided in the Allocate
response. They can guarantee the authenticity and integrity of the response. They can guarantee the authenticity and integrity of the
allocated addresses. Note that the STUN relay usage is not allocated addresses. Note that TURN is not susceptible to the
susceptible to the attacks described in Section 12.2.3, 12.2.4, attacks described in Section 12.2.3, 12.2.4, 12.2.5 or 12.2.6 of RFC
12.2.5 or 12.2.6 of RFC 3489 [[TODO: Update references once 3489bis 3489 [[TODO: Update references once 3489bis is more stable]]. These
is more stable]]. These attacks are based on the fact that a STUN attacks are based on the fact that a STUN server mirrors the source
server mirrors the source IP address, which cannot be authenticated. IP address, which cannot be authenticated. STUN does not use the
STUN does not use the source address of the Allocate Request in source address of the Allocate Request in providing the RELAY-
providing the RELAY-ADDRESS, and therefore, those attacks do not ADDRESS, and therefore, those attacks do not apply.
apply.
The relay usage cannot be used by clients for subverting firewall TURN cannot be used by clients for subverting firewall policies.
policies. The relay usage has fairly limited applicability, TURN has fairly limited applicability, requiring a user to send a
requiring a user to send a packet to a peer before being able to packet to a peer before being able to receive a packet from that
receive a packet from that peer. This applies to both TCP and UDP. peer. This applies to both TCP and UDP. Thus, it does not provide a
Thus, it does not provide a general technique for externalizing TCP general technique for externalizing TCP and UDP sockets. Rather, it
and UDP sockets. Rather, it has similar security properties to the has similar security properties to the placement of an address-
placement of an address-restricted NAT in the network, allowing restricted NAT in the network, allowing messaging in from a peer only
messaging in from a peer only if the internal client has sent a if the internal client has sent a packet out towards the IP address
packet out towards the IP address of that peer. This limitation of that peer. This limitation means that TURN cannot be used to run
means that the relay usage cannot be used to run web servers, email web servers, email servers, SIP servers, or other network servers
servers, SIP servers, or other network servers that service a large that service a large number of clients. Rather, it facilitates
number of clients. Rather, it facilitates rendezvous of NATted rendezvous of NATted clients that use some other protocol, such as
clients that use some other protocol, such as SIP, to communicate IP SIP, to communicate IP addresses and ports for communications.
addresses and ports for communications.
Confidentiality of the transport addresses learned through Allocate Confidentiality of the transport addresses learned through Allocate
requests does not appear to be that important, and therefore, this requests does not appear to be that important, and therefore, this
capability is not provided. capability is not provided.
Relay servers are useful even for users not behind a NAT. They can Relay servers are useful even for users not behind a NAT. They can
provide a way for truly anonymous communications. A user can cause a provide a way for truly anonymous communications. A user can cause a
call to have its media routed through a STUN server, so that the call to have its media routed through a STUN server, so that the
user's IP addresses are never revealed. user's IP addresses are never revealed.
TCP transport addresses allocated by Allocate requests will properly TCP transport addresses allocated by Allocate requests will properly
work with TLS and SSL. However, any relay addresses learned through work with TLS and SSL. However, any relay addresses learned through
an Allcoate will not operate properly with IPSec Authentication an Allcoate will not operate properly with IPSec Authentication
Header (AH) [6] in transport mode. IPSec ESP [7] and any tunnel-mode Header (AH) [5] in transport mode. IPSec ESP [6] and any tunnel-mode
ESP or AH should still operate. ESP or AH should still operate.
13. IANA Considerations 13. IANA Considerations
This specification defines several new STUN messages, STUN This specification defines several new STUN messages, STUN
attributes, and STUN response codes. This section directs IANA to attributes, and STUN response codes. This section directs IANA to
add these new protocol elements to the IANA registry of STUN protocol add these new protocol elements to the IANA registry of STUN protocol
elements. elements.
13.1. New STUN Requests, Responses, and Indications 13.1. New STUN Requests, Responses, and Indications
Request/Response Transactions Request/Response Transactions
0x003 : Allocate 0x003 : Allocate
0x004 : Set Active Destination 0x004 : Set Active Destination
0x005 : Connect 0x005 : Connect
Indications Indications
0x001 : Send 0x006 : Send
0x002 : Data 0x007 : Data
0x003 : Connect Status 0x008 : Connect Status
13.2. New STUN Attributes 13.2. New STUN Attributes
0x000D: LIFETIME 0x000D: LIFETIME
0x0010: BANDWIDTH 0x0010: BANDWIDTH
0x0012: REMOTE-ADDRESS 0x0012: REMOTE-ADDRESS
0x0013: DATA 0x0013: DATA
0x0016: RELAY-ADDRESS 0x0016: RELAY-ADDRESS
0x0018: REQUESTED-PORT-PROPS 0x0018: REQUESTED-PORT-PROPS
0x0019: REQUESTED-TRANSPORT 0x0019: REQUESTED-TRANSPORT
0x0022: REQUESTED-IP 0x0022: REQUESTED-IP
0x0021: TIMER-VAL 0x0021: TIMER-VAL
0x0023: CONNECT_STAT 0x0023: CONNECT_STAT
13.3. New STUN response codes 13.3. New STUN response codes
437 No Binding 437 No Binding
439 Active Destination Already Set 439 Active Destination Already Set
441 -- Wrong User --
442 Unsupported Transport Protocol 442 Unsupported Transport Protocol
443 Invalid IP Address 443 Invalid IP Address
444 Invalid Port 444 Invalid Port
445 Operation for TCP Only 445 Operation for TCP Only
446 Connection Already Exists 446 Connection Already Exists
447 --
486 Allocation Quota Reached 486 Allocation Quota Reached
507 Insufficient Capacity 507 Insufficient Capacity
14. IAB Considerations 14. IAB Considerations
The IAB has studied the problem of ``Unilateral Self Address The IAB has studied the problem of "Unilateral Self Address Fixing",
Fixing'', which is the general process by which a client attempts to which is the general process by which a client attempts to determine
determine its address in another realm on the other side of a NAT its address in another realm on the other side of a NAT through a
through a collaborative protocol reflection mechanism RFC 3424 [8]. collaborative protocol reflection mechanism RFC 3424 [7]. The TURN
The STUN relay extension is an example of a protocol that performs extension is an example of a protocol that performs this type of
this type of function. The IAB has mandated that any protocols function. The IAB has mandated that any protocols developed for this
developed for this purpose document a specific set of considerations. purpose document a specific set of considerations.
This section meets those requirements.
14.1. Problem Definition
>From RFC 3424 [8], 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 the STUN relay extension 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 also possible to send packets so that
the recipient sees a source address equal to the allocated address.
STUN relays, by design, does not allow a client to run a server (such
as a web or SMTP server) using a STUN relay address. STUN relays are
useful even when NAT is not present, to provide anonymity services.
14.2. Exit Strategy
From [8], any UNSAF proposal must provide:
Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed.
It is expected that STUN relays will be useful indefinitely, to
provide anonymity services. When used to facilitate NAT traversal,
STUN relay does not itself provide an exit strategy. That is
provided by the Interactive Connectivity Establishment (ICE) [9]
mechanism. ICE allows two cooperating clients to interactively
determine the best addresses to use when communicating. ICE uses
STUN-allocated relay addresses as a last resort, only 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 STUN relay
addresses, but not use them, and therefore, de-allocate them.
Servers will see a decrease in usage. Once a provider sees that its
STUN relay servers are not being used at all (that is, no media flows
through them), they can simply remove them. ICE will operate without
STUN-allocated relay addresses.
14.3. Brittleness Introduced by STUN relays
From [8], 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.
The STUN relay extension introduces brittleness in a few ways.
First, it adds another server element to any system, which adds
another point of failure. It requires clients to demultiplex STUN
relay packets and data based on hunting for a MAGIC-COOKIE in the
STUN messages. It is possible (with extremely small probabilities)
that this cookie could appear within a data stream, resulting in mis-
classification. That might introduce errors into the data stream
(they would appear as lost packets), and also result in loss of a
binding. STUN relay relies on any NAT bindings existing for the
duration of the bindings held by the STUN relay server. Neither the
client nor the STUN relay 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 STUN for some period, the address might become
useless spontaneously.
STUN relays 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 B, whose location is 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 STUN relay addresses. However, when used, this
problem will exist.
Note that STUN relay does not suffer from many of the points of
brittleness introduced by the STUN binding or discovery usages. STUN
relay will work with all existing NAT types known at the time of
writing, and for the forseeable future. STUN relay does not
introduce any topological constraints. STUN relay does not rely on
any heuristics for NAT type classification.
14.4. Requirements for a Long Term Solution
>From [8]}, 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 STUN relay continues to validate our belief in
the requirements outlined in Section 14.4 of STUN.
14.5. Issues with Existing NAPT Boxes
>From [8], 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 TURN is an extension of the STUN protocol. As such, the specific
try and provide "generic" ALG functionality. These generic ALGs hunt usages of STUN that use the TURN extensions need to specifically
for IP addresses, either in text or binary form within a packet, and address these considerations. Currently the only STUN usage that
rewrite them if they match a binding. This usage avoids that problem uses TURN is ICE [8].
by using the XOR-MAPPED-ADDRESS attribute instead of the MAPPED-
ADDRESS
15. Example 15. Example
In this example, a client is behind a NAT. The client has a private In this example, a client is behind a NAT. The client has a private
address of 10.0.1.1. The STUN server is on the public side of the address of 10.0.1.1. The STUN server is on the public side of the
NAT, and is listening for STUN relay requests on 192.0.2.3:8776. The NAT, and is listening for TURN requests on 192.0.2.3:8776. The
public side of the NAT has an IP address of 192.0.2.1. The client is public side of the NAT has an IP address of 192.0.2.1. The client is
attempting to send a SIP INVITE to a peer, and wishes to allocate an attempting to send a SIP INVITE to a peer, and wishes to allocate an
IP address and port for inclusion in the SDP of the INVITE. IP address and port for inclusion in the SDP of the INVITE.
Normally, STUN relays would be used in conjunction with ICE when Normally, TURNs would be used in conjunction with ICE when applied to
applied to SIP. For simplicities sake, STUN relay is showed without SIP. For simplicities sake, TURN is showed without ICE.
ICE.
The client communicates with a SIP user agent on the public network. The client communicates with a SIP user agent on the public network.
This user agent uses a 192.0.2.17:12734 for receipt of its RTP This user agent uses a 192.0.2.17:12734 for receipt of its RTP
packets. packets.
Client NAT STUN Server Peer Client NAT STUN Server Peer
| | | | | | | |
|(1) Allocate | | | |(1) Allocate | | |
|S=10.0.1.1:4334 | | | |S=10.0.1.1:4334 | | |
|D=192.0.2.3:8776 | | | |D=192.0.2.3:8776 | | |
skipping to change at page 41, line 41 skipping to change at page 38, line 35
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Marc Petit-Huguenin for his comments The authors would like to thank Marc Petit-Huguenin for his comments
and suggestions. and suggestions.
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] Rosenberg, J., "Simple Traversal Underneath Network Address [1] Rosenberg, J., "Session Traversal Utilities for (NAT) (STUN)",
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 draft-ietf-behave-rfc3489bis-06 (work in progress), March 2007.
(work in progress), October 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
17.2. Informative References 17.2. Informative References
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [5] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, [6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005. December 2005.
[8] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- [7] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002. RFC 3424, November 2002.
[9] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [8] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in Offer/Answer Protocols", draft-ietf-mmusic-ice-16 (work in
progress), January 2007. progress), June 2007.
[10] Audet, F. and C. Jennings, "NAT Behavioral Requirements for [9] Audet, F. and C. Jennings, "NAT Behavioral Requirements for
Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress),
October 2006. October 2006.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
 End of changes. 102 change blocks. 
512 lines changed or deleted 337 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/