< draft-rosenberg-midcom-turn-00.txt		draft-rosenberg-midcom-turn-01.txt >
	Internet Engineering Task Force MIDCOM WG		MIDCOM J. Rosenberg
	Internet Draft Rosenberg,Weinberger,Huitema,Mahy		Internet-Draft J. Weinberger
	draft-rosenberg-midcom-turn-00.txt dynamicsoft,Microsoft,Cisco		Expires: September 1, 2003 dynamicsoft
	November 14, 2001		R. Mahy
	Expires: March 2002		Cisco Systems
			C. Huitema
			Microsoft
			March 3, 2003
	Traversal Using Relay NAT (TURN)		Traversal Using Relay NAT (TURN)
			draft-rosenberg-midcom-turn-01
	STATUS OF THIS MEMO		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 other
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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://
	http://www.ietf.org/ietf/1id-abstracts.txt		www.ietf.org/ietf/1id-abstracts.txt.
	To view the list Internet-Draft Shadow Directories, see		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		This Internet-Draft will expire on September 1, 2003.
	Traversal Using Relay NAT (TURN) is a simple protocol that allows for		Copyright Notice
	an element behind a NAT or firewall to receive incoming data over TCP
	or UDP connections. It is most useful for elements behind symmetric
	NATs or firewalls that wish to be on the receiving end of a
	connection to a single peer. TURN does not allow for users to run
	servers on well known ports if they are behind a nat; it supports the
	connection of a user behind a nat to only a single peer. In that
	regard, its role is to provide the same security functions provided
	by symmetric NATs and firewalls, but to "turn" the tables so that the
	element on the inside can be on the receiving end, rather than the
	sending end, of a connection that is requested by the client.
	1 Introduction		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Network Address Translators (NATs), while providing many benefits,
	also come with many drawbacks. The most troublesome of those
	drawbacks is the fact that they break many existing IP applications,
	and make it difficult to deploy new ones. Guidlines have been
	developed [1] that describe how to build "NAT friendly" protocols,
	but many protocols simply cannot be constructed according to those
	guidelines. Examples of such protocols include almost all peer-to-
	peer protocols, for example.
	To handle this, we have documented the Simple Traversal of UDP		Abstract
	Through NAT (STUN) protocol [2], which allows for clients behind a
	NAT to discover the presence of the NAT, and then to allocate an
	address that is useful for receiving data in the case where they are
	behind a full-cone or restricted-cone NAT. However, it is
	acknowledged in that draft that while STUN allows a client to
	discover that its behind a symmetric NAT, it provides no assistance
	in traversing symmetric NATs.
	This protocol serves as a complement to STUN, handling the case where		Traversal Using Relay NAT (TURN) is a protocol that allows for an
	the user is behind a symmetric NAT. It allows a client to request an		element behind a NAT or firewall to receive incoming data over TCP or
	IP address and port that it can receive data on from any other host		UDP connections. It is most useful for elements behind symmetric NATs
	on the Internet. This is accomplished using a server in the service		or firewalls that wish to be on the receiving end of a connection to
	provider cloud, known as a TURN server. When a host on the Internet		a single peer. TURN does not allow for users to run servers on well
	sends to this IP address and port, the TURN server creates an		known ports if they are behind a nat; it supports the connection of a
	association between the two. The client behind the NAT will receive		user behind a nat to only a single peer. In that regard, its role is
	this, and any other subsequent data from that host. In addition, the		to provide the same security functions provided by symmetric NATs and
	client behind the NAT can send data, and that data will be forwarded		firewalls, but to ``turn'' the tables so that the element on the
	by the TURN server to the host which connected. TURN servers		inside can be on the receiving end, rather than the sending end, of a
	purposefully support a single association, so that only a single host		connection that is requested by the client.
	can be connected using the IP address and port provided by the turn
	server. This assures that TURN can't be used to violate the policy
	that symmetric NAT and firewalls are meant to enforce. All TURN does
	is allow a client to communicate with a single peer whose address it
	doesn't know ahead of time. TURN is not a tunneling protocol, and
	therefore does not allow for a user to send and receive UDP, if, for
	example, the firewall policy prohibits the usage of UDP. Effectively,
	a TURN server is a NAT function at the UDP and TCP layer, and thus
	the name of the protocol - its a "relay NAT".
	2 Do we need this Protocol?		Table of Contents
	Originally, the TURN protocol was integrated with the STUN protocol		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	documented in [2]. The authors yanked it out of that document because		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
	it solves a sufficiently different problem, with differing		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 6
	requirements. We also observed that there are many other potential		4. Applicability Statement . . . . . . . . . . . . . . . . . . 7
	solutions for the symmetric case, including RSIP [3] [4], and more		5. Overview of Operation . . . . . . . . . . . . . . . . . . . 8
	traditional VPN tunnels. We therefore had to ask ourselves why		6. Message Overview . . . . . . . . . . . . . . . . . . . . . . 10
	another solution was needed in this space. Here are some of the		7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . 11
	issues we came up with:		7.1 Shared Secret Request . . . . . . . . . . . . . . . . . . . 11
			7.2 Allocate Request . . . . . . . . . . . . . . . . . . . . . . 13
			7.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 13
			7.2.2 Initial Requests . . . . . . . . . . . . . . . . . . . . . . 13
			7.2.3 Requests for Pre-Allocated Ports . . . . . . . . . . . . . . 17
			7.2.4 Subsequent Requests . . . . . . . . . . . . . . . . . . . . 18
			7.3 Receiving Packets and Connections . . . . . . . . . . . . . 19
			7.4 Lifetime Expiration . . . . . . . . . . . . . . . . . . . . 20
			8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . 22
			8.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 22
			8.2 Obtaining a One Time Password . . . . . . . . . . . . . . . 22
			8.3 Allocating a Binding . . . . . . . . . . . . . . . . . . . . 23
			8.4 Processing Allocate Responses . . . . . . . . . . . . . . . 24
			8.5 Allocating a Pre-Allocated Binding . . . . . . . . . . . . . 25
			8.6 Refreshing a Binding . . . . . . . . . . . . . . . . . . . . 26
			8.7 Tearing Down a Binding . . . . . . . . . . . . . . . . . . . 26
			8.8 Receiving and Sending Data . . . . . . . . . . . . . . . . . 26
			9. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 27
			9.1 Message Types . . . . . . . . . . . . . . . . . . . . . . . 27
			9.2 Message Attributes . . . . . . . . . . . . . . . . . . . . . 27
			9.2.1 TRANSPORT-PREFERENCES . . . . . . . . . . . . . . . . . . . 27
			9.2.2 LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . . 28
			9.2.3 ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . . . 28
			9.2.4 MAGIC-COOKIE . . . . . . . . . . . . . . . . . . . . . . . . 28
			9.2.5 BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . . 28
			9.3 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 29
			10. Security Considerations . . . . . . . . . . . . . . . . . . 30
			11. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 32
			11.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . 32
			11.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . 32
			11.3 Brittleness Introduced by TURN . . . . . . . . . . . . . . . 33
			11.4 Requirements for a Long Term Solution . . . . . . . . . . . 34
			11.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . . 34
			12. Requirements Analysis . . . . . . . . . . . . . . . . . . . 35
			13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36
			Normative References . . . . . . . . . . . . . . . . . . . . 37
			Informative References . . . . . . . . . . . . . . . . . . . 38
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
			Intellectual Property and Copyright Statements . . . . . . . 40
	o RSIP and the VPN solutions all allocate an entire IP address		1. Introduction
	to the client. This means the provider must have sufficient IP
	addresses for all the clients which would simultaneously need
	service. This could require significant address space. With
	this proposal, its an IP address/port thats allocated, which
	means very few IP addresses are needed. This is the standard
	NAT argument.
	o RSIP and VPN solutions all require tunneling. In this		Network Address Translators (NATs), while providing many benefits,
	proposal, there is no tunneling. The result is more efficient		also come with many drawbacks. The most troublesome of those
	bandwidth usage, which is important for media packets (RTP is		drawbacks is the fact that they break many existing IP applications,
	a likely user of this mechanism).		and make it difficult to deploy new ones. Guidelines [9] have been
			developed that describe how to build "NAT friendly" protocols, but
			many protocols simply cannot be constructed according to those
			guidelines. Examples of such protocols include multimedia
			applications and file sharing.
	o RSIP and VPN solutions might contradict enterprise firewall		Simple Traversal of UDP Through NAT (STUN) [1] provides one means for
	policy, allowing people to run servers, to use UDP when only		an application to traverse a NAT. STUN allows a client to obtain a
	TCP is allowed, and so on. Some would consider this a feature,		transport address (and IP address and port) which may be useful for
	not a drawback. But, if the goal is consistency with IT		receiving packets from a peer. However, addresses obtained by STUN
	established policies, it is a drawback. Our proposal provides		may not be usable by all peers. Those addresses work depending on the
	a simple, minimalistic functionality that is consistent with		topological conditions of the network. Therefore, STUN by itself
	enterprise policy. The only feature TURN adds, is the ability		cannot provide a complete solution for NAT traversal.
	of a user behind the firewall/NAT to receive a single incoming
	connection, which it has previously requested.
	Whether these benefits outweigh the cost of developing and deploying		A complete solution requires a means by which a client can obtain a
	another protocol is important to consider further.		transport address from which it can receive media from any peer which
			can send packets to the public Internet. This can only be
			accomplished by relaying data though a server that resides on the
			public Internet. This specification describes Traversal Using Relay
			NAT (TURN), a protocol that allows a client to obtain IP addresses
			and ports from such a relay.
	3 Terminology		Although TURN will almost always provide connectivity to a client, it
			comes at high cost to the provider of the TURN server. It is
			therefore desirable to use TURN as a last resort only, preferring
			other mechanisms (such as STUN or direct connectivity) when possible.
			To accomplish that, the Interactive Connectivity Establishment (ICE)
			[13] methodology can be used to discover the optimal means of
			connectivity.
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		2. Terminology
	"SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] and
	indicate requirement levels for compliant STUN implementations.
	4 Definitions		In this document, the key words MUST, MUST NOT, REQUIRED, SHALL,
			SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to
			be interpreted as described in RFC 2119 [2] and indicate requirement
			levels for compliant TURN implementations.
	TURN Client: A TURN client (also just referred to as a client)		3. Definitions
	is an entity that generates TURN requests. A TURN client
	can be an end system, such as a SIP User Agent, or can be a
	network element, such as a Back-to-Back User Agent (B2BUA)
	SIP server. The TURN protocol will provide the STUN client
	with IP addresses that route to it from the public
	Internet.
	TURN Server: A TURN Server (also just referred to as a server)		TURN Client: A TURN client (also just referred to as a client) is
	is an entity that receives TURN requests, and sends TURN		an entity that generates TURN requests. A TURN client can be an
	responses. The server is capable of acting as a data relay,		end system, such as a Session Initiation Protocol (SIP) [6] User
	receiving data on the address it provides to clients, and		Agent, or can be a network element, such as a Back-to-Back User
	forwarding them to the clients.		Agent (B2BUA) SIP server. The TURN protocol will provide the STUN
			client with IP addresses that route to it from the public
			Internet.
	5 Overview of Operation		TURN Server: A TURN Server (also just referred to as a server) is
			an entity that receives TURN requests, and sends TURN responses.
			The server is capable of acting as a data relay, receiving data on
			the address it provides to clients, and forwarding them to the
			clients.
	/-----\		Transport Address: An IP address and port.
	// TURN \\
	| Server |
	\\ //
	\-----/
	+--------------+ Public Internet		4. Applicability Statement
	................| NAT 2 |.......................
	+--------------+
	+--------------+ Private NET 2		TURN is useful for applications that require a client to place a
	................| NAT 1 |.......................		transport address into a protocol message, with the expectation that
	+--------------+		the client will be able to receive packets from a single host that
			will send to this address. Examples of such protocols include SIP,
			which makes use of the Session Description Protocol (SDP) [7]. SDP
			carries and IP address on which the client will receive media packets
			from its peer. Another example of a protocol meeting this criteria is
			the Real Time Streaming Protocol (RTSP) [8].
	/-----\		When a client is behind a NAT, transport addresses obtained from the
	// TURN \\		local operating system will not be publically routable, and
	| Client |		therefore, not useful in these protocols. TURN allows a client to
	\\ // Private NET 1		obtain a transport address, from a server on the public Internet,
	\-----/		which can be used in protocols meeting the above criteria. However,
			the transport addresses obtained from TURN servers are not generally
			useful for receiving data from anywhere. They are only useful for
			communicating with a single peer. Once a host sends packets to that
			transport address, it is ``locked down'', meaning that packets from
			other hosts will not be forwarded to the client. This is done
			purposefully, so as to prevent TURN from being used to run servers
			(such as a web server) on a client behind a NAT. In this way,
			enterprises which deploy NATs and firewalls to prevent users from
			running servers, can be confident that TURN will not cause any
			violations in their enterprise security policies.
	Figure 1: TURN Configuration		5. Overview of Operation
	The typical TURN configuration is shown in Figure 1. A TURN client is		The typical TURN configuration is shown in Figure 1. A TURN client is
	connected to private network 1. This network connects to private		connected to private network 1. This network connects to private
	network 2 through NAT 1. Private network 2 connects to the public		network 2 through NAT 1. Private network 2 connects to the public
	Internet through NAT 2. On the public Internet is a TURN server.		Internet through NAT 2. On the public Internet is a TURN server.
	TURN is a simple client-server protocol. There is just a single		/-----\
	request message, called Allocate, which asks for a public IP address		// TURN \\
	and port. TURN can run over UDP and TCP, as it allows for a client to		| Server |
	request address/port pairs for receiving both UDP and TCP.		\\ //
			\-----/
			+--------------+ Public Internet
			................| NAT 2 |.......................
			+--------------+
			+--------------+ Private NET 2
			................| NAT 1 |.......................
			+--------------+
			/-----\
			// TURN \\
			| Client |
			\\ // Private NET 1
			\-----/
			Figure 1
			TURN is a simple client-server protocol. It is identical in syntax
			and general operation to STUN, in order to facilitate a joint
			implementation of both. TURN defines a request message, called
			Allocate, which asks for a public IP address and port. TURN can run
			over UDP and TCP, as it allows for a client to request address/port
			pairs for receiving both UDP and TCP.
	A TURN client first discovers the address of a TURN server. This can		A TURN client first discovers the address of a TURN server. This can
	be preconfigured, or it can be discovered using SRV records [6]. This		be preconfigured, or it can be discovered using SRV records [3] This
	will allow for different TURN servers for UDP and TCP. Once a TURN		will allow for different TURN servers for UDP and TCP. Once a TURN
	server is discovered, the client sends a TURN Allocate request to the		server is discovered, the client sends a TURN Allocate request to the
	TURN server. TURN provides a digest authentication capability,		TURN server. TURN provides a mechanism for mutual authentication and
	mirroring the operation of HTTP digest [7] that allows the server to		integrity checks for both requests and responses, based on a shared
	authenticate the client, and for the client to authenticate the		secret. Assuming the request is authenticated and has not been
	server. Assuming the request is authenticated, the TURN server		tampered with, the TURN server remembers the source transport address
	remembers the source IP address and port that the request came from		that the request came from (call this SA), and returns a public
	(call this SA:SP), and returns a public IP address and port, PA:PP,		transport address, PA, in the TURN response. The TURN server is
	in the TURN response. This public address and port have to route to		responsible for guaranteeing that packets sent to PA route to the
	the TURN server. The TURN server then waits for data on PA:PP. When		TURN server. The TURN server then waits for data on PA. When data is
	data is received (either a UDP packet or a TCP connection request),		received (either a UDP packet or a TCP connection request), the TURN
	the TURN server accepts the connection (in the case of TCP), and then		server accepts the connection (in the case of TCP), and then stores
	stores the remote address and port where the data came from (RA:RP).		the remote address and port where the data came from (RA). The data
	The data just received, if any, are then forwarded to SA:SP. The TURN		just received, if any, are then forwarded to SA. The TURN server then
	server then acts as a relay. Any data received from SA:SP are		acts as a relay. Any data received from SA are forwarded to RA. Any
	forwarded to RA:RP. Any data sent from RA:RP to PA:PP are sent to		data sent from RA to PA are sent to SA.
	SA:SP. The TURN server does not need to examine the data received; it
	merely forwards all data between the socket pairs it has associated
	together.
	In the case of TCP, if either side closes a connection, the TURN		For TCP, the TURN server does not need to examine the data received;
	server closes the other connection. For both UDP and TCP, the TURN		it merely forwards all data between the socket pairs it has
	server can also time out a connection in the event data is not		associated together. In the case of UDP, the TURN server looks for a
	received after some configured time out period. This period is sent		magic cookie in the first 128 bytes of each UDP packet. If present,
	to the client in the TURN response to the Allocate request.		it indicates that the packet is a TURN control packet, used for
			keepalives and teardown of the binding. In the case of TCP, if either
			side closes a connection, the TURN server closes the other
			connection. For both UDP and TCP, the TURN server can also time out a
			connection in the event data is not received after some configured
			time out period. This period is sent to the client in the TURN
			response to the Allocate request.
	6 Message Overview		TURN also allows a client to request an odd or even port when one is
			allocated, and for it to pre-allocate the next higher port. This is
			useful for securing consecutive ports for usage with the Real Time
			Transport Protocol (RTP) [5].
	TURN messages are TLV (type-length-value) encoded using big endian		6. Message Overview
	(network ordered) binary. TURN messages are formatted identically to
	STUN messages, as it is expected that these protocols will frequently
	be used together.
	TURN uses the MAPPED-ADDRESS attribute defined in STUN. This address		TURN messages are identical to STUN messages in their syntax. TURN
	always appears in the Allocate Response. TURN also defines a		defines three new messages - the Allocate Request, the Allocate
	CHALLENGE and an AUTHENTICATION attribute. They are very similar to		Response, and the Allocate Error Response. TURN also uses the Shared
	the Authorization and WWW-Authenticate headers in RFC 2617 [7], and		Secret Request, Shared Secret Response, and Shared Secret Error
	convey a realm, nonce, username, and signature. Unlike HTTP Digest,		Response defined by STUN. TURN makes use of some of the STUN
	TURN authentication covers the entire message.		attributes (MAPPED-ADDRESS, USERNAME, MESSAGE-INTEGRITY, ERROR-CODE,
			and UNKNOWN-ATTRIBUTES) and also defines several of its own.
			Specifically, TURN adds TRANSPORT-PREFERENCES attribute, which allows
			a client to request an odd or even port, and to pre-allocate the next
			higher port. It defines the LIFETIME attribute, which allows the TURN
			server to tell the client when the binding will be released. It
			defines the MAGIC-COOKIE attribute, which allows the TURN client to
			find TURN messages in a stream of UDP packets. It defines the
			BANDWIDTH attribute, which allows a client to inform the server of
			the expected bandwidth usage on the connection. Finally, it defines
			the ALTERNATE-SERVER attribute, which allows the server to redirect
			the TURN client to connect to an alternate server.
	A LIFETIME attribute indicates how long the mapped address in the		7. Server Behavior
	Allocate response is valid for. The ALTERNATE-SERVER attribute in an
	Allocate response indicates that the allocation server was full, and
	the alternate should be used instead.
	7 Server Behavior		The server behavior depends on whether the request is a Shared Secret
			Request or an Allocate Request.
	A TURN server generates a single response when a request is received		7.1 Shared Secret Request
	(assuming the request is not discarded). The response MUST contain
	the same transaction ID contained in the request. The length in the
	message header MUST contain the total length of the message in bytes,
	excluding the header.
	7.1 Client Authentication		Unlike a STUN server, a TURN server provides resources to clients
			that connect to it. Therefore, only authorized clients can gain
			access to a TURN server. This requires that TURN requests be
			authenticated. TURN assumes the existence of a long-lived shared
			secret between the client and the TURN server in order to achieve
			this authentication. The client uses this long-lived shared secret to
			authenticate itself in a Shared Secret Request, sent over TLS. The
			Shared Secret Response provides the client with a one-time username
			and password. This one-time credential is then used by the server to
			authenticate an Allocate Request. The usage of a separate long lived
			and one-time credentials prevents dictionary attacks, whereby an
			observer of a message and its HMAC could guess the password by an
			offline dictionary search.
	The request can be authenticated. This is done using a challenge-		When a TURN server receives a Shared Secret Request, it first
	response mechanism. When a request is received without proper		executes the processing described in the first three paragraphs of
	credentials (which are present in the AUTHENTICATION attribute), the		Section 8.2 of STUN. This processing will ensure that the Shared
	server MAY generate a challenge response. A challenge response MUST		Secret Request is received over TLS.
	NOT contain any attributes except the CHALLENGE attribute. This
	attribute contains a realm and a nonce. The usage of the realm and
	nonce is identical to their usage in responses for Digest
	authentication to HTTP requests, as described in RFC 2617 [7].
	The client, upon receiving this challenge, can generate a new		Assuming it was, the server checks the Shared Secret Request for a
	request, this time with an AUTHENTICATION attribute, which reflects		MESSAGE-INTEGRITY attribute. If not present, the server generates a
	the nonce and realm back to the server, and contains a keyed hash		Shared Secret Error Response with an ERROR-CODE attribute with
	over the message using the user's name and password. When this is		response code 401. That response MUST include a NONCE attribute,
	received at the server, the server validates the AUTHENTICATION		containing a nonce that the server wishes the client to reflect back
	attribute. This is done by computing the keyed hash in the same way		in a subsequent Shared Secret Request (and therefore include the
	the client does, and comparing the results. If there is a match, the		message integrity computation). The response MUST include a REALM
	server considers the request authenticated. Otherwise, if it fails,		attribute, containing a realm from which the username and password
	the server SHOULD proceed as if the AUTHENTICATION attribute where		are scoped [4].
	not present, typically resulting in another challenge.
	7.2 Server Authentication		If the MESSAGE-INTEGRITY attribute was present, the server checks for
			the existence of the REALM attribute. If the attribute is not
			present, the server MUST generate a Shared Secret Error Response.
			That response MUST include an ERROR-CODE attribute with response code
			434. That response MUST include a NONCE and a REALM attribute.
	The client can demand authentication of the server. To do this, it		If the REALM attribute was present, the server checks for the
	includes a CHALLENGE attribute in the request. When the server		existence of the NONCE attribute. If the NONCE attribute is not
	receives this, assuming that the server has authenticated the		present, the server MUST generate a Shared Secret Error Response.
	request, the response contains (in addition to the other attributes)		That response MUST include an ERROR-CODE attribute with response code
	an AUTHENTICATION attribute. A TURN Server MUST NOT include an		435. That response MUST include a NONCE attribute and a REALM
	AUTHENTICATION attribute in a response, if the server did not		attribute.
	successfully authenticate the client in the corresponding request.
	This attribute contains a hash of the message contents, the nonce,
	and the shared secret between the client and server.
	7.3 Allocation		If the NONCE attribute was present, the server checks for the
	Allocation requests are used to obtain an IP address and port that		existence of the USERNAME attribute. If it was not present, the
	the client can use to receive UDP and TCP packets from any host on		server MUST generate a Shared Secret Error Response. The Shared
	the network, even when the client is behind a symmetric NAT.		Secret Error Response MUST include an ERROR-CODE attribute with
			response code 432. It MUST include a NONCE attribute and a REALM
			attribute.
	When a client is behind a symmetric NAT, the IP address and port it		If the USERNAME is present, the server computes the HMAC over the
	obtains from the Allocate response cannot be used to receive packets		request as described in Section 11.2.8 of STUN. The key is computed
	from any host on the Internet. Only the recipient of the request can		as MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" passwd), where
	send packets to the client at the mapped address. Unfortunately, this		the password is the password associated with the username and realm
	is therefore limited to the server that received the TURN request.		provided in the request. If the server does not have a record for
	Therefore, the server acts as an intermediary. It returns its own IP		that username within that realm, the server generates a Shared Secret
	address and a free port in the response. This can be used by the		Error Response. That response MUST include an ERROR-CODE attribute
	client in any applications it is running. Any packets received by the		with response code 436. That response MUST include a NONCE attribute
	server on that IP address and port are forwarded to the client. Since		and a REALM attribute.
	the server is on the public Internet and not natted, anyone can send
	to it.
	As a result, the server MUST maintain a set of mappings. These		This format for the key was chosen so as to enable a common
	mappings are associations between the five-tuple of received Allocate		authentication database for SIP and for TURN, as it is expected
	requests (source IP address and port, destination IP address and		that credentials are usually stored in their hashed forms. [[OPEN
	port, and protocol), called the allocate five-tuple, and another five		ISSUE: Is support of MD5-sess needed?]]
	tuple, called the remote five-tuple.
	When an authenticated Allocate request is received, a partially		If the computed HMAC differs from the one from the MESSAGE-INTEGRITY
	filled-in remote five-tuple is constructed. This remote five-tuple		attribute in the request, the server MUST generate a Shared Secret
	consists of the same protocol as the five-tuple from the Allocate		Error Response with an ERROR-CODE attribute with response code 431.
	request, and a destination IP address and port that route to the TURN		This response MUST include a NONCE attribute and a REALM attribute.
	server. This IP address and port from the remote five-tuple is known
	as the mapped address. The mapped address is returned to the client
	in the TURN response, using the MAPPED-ADDRESS attribute. The address
	and port in the MAPPED-ADDRESS attribute MUST NOT correspond to an
	address and port already present in another remote five-tuple.
	Effectively, it is a new address and port that is allocated to the
	client, and thus the name of the request. Of course, it is possible
	that there are no more address/port pairs available, due to depleted
	resources. In that case, the server SHOULD generate a response that
	MUST NOT contain a MAPPED-ADDRESS attribute. Instead, it MAY contain
	an ALTERNATE-SERVER attribute, which contains the address and port of
	an alternate server. If the ALTERNATE-SERVER attribute is not
	present, the client will instead use DNS procedures, described below,
	to find an alternate.
	The TURN server MUST listen for packets on the MAPPED-ADDRESS, using		If the computed HMAC doesn't differ from the one in the request, but
	the protocol in the remote five-tuple. When a packet is received, the		the nonce is stale, the server MUST generate a Shared Secret Error
	source IP address and port of that packet MUST be used to fill in the		Response. That response MUST include an ERROR-CODE attribute with
	remaining two fields in the remote five-tuple. In the case of TCP,		response code 430. That response MUST include a NONCE attribute and a
	the TURN server MUST accept the TCP connection. In the case of UDP,		REALM attribute.
	any data present in the packet MUST be forwarded to the source
	address and port of the allocate five-tuple, and MUST be sent from
	the destination address and port of the allocate five-tuple, using
	the protocol of the five-tuple.
	From then on, any packets received on the MAPPED-ADDRESS, with a		In all cases, the Shared Secret Error Response is sent over the TLS
	source IP and port matching the source IP and port of the remote		connection on which the Shared Secret Request was received.
	tuple, MUST have their data forwarded to the allocate five-tuple in
	the same fashion described above. In the case of TCP, any other
	connection requests to the MAPPED-ADDRESS MUST be refused.
	In the case of TCP, if either connection (the one associated with the		The server proceeds to authorize the client. The means for
	allocate five-tupe or the one associated with the remote five-tuple)		authorization are outside the scope of this specification. It is
	is closed, the TURN server MUST close the other connection, and		anticipated that TURN servers will be run by providers that also
	destroy the mapping between the tuples.		provide an application service, such as SIP or RTSP. In that case, a
			user would be authorized to use TURN if they are authorized to use
			the application service.
	The TURN server SHOULD maintain an activity timer for the mapping.		The server then generates a Shared Secret Response as in Section 8.2
	This timer fires after a configurable amount of time (called the		of STUN. This response will contain a USERNAME and PASSWORD, which
	lifetime) has expired without data having been received from either		are used by the client as a short-term shared secret in subsequent
	five-tuple. When this timer fires, both connections are closed (in		Allocate requests. Note that STUN specifies that the server has to
	the TCP case), and the mapping between the tuples MUST be destroyed.		invalidate this username and password after 30 minutes. This is not
	If the TURN server is using activity timers, it MUST include the		the case in TURN. In TURN, the server MUST store the allocated
	lifetime interval in the LIFETIME attribute of the original Allocate		username and password for a duration of at least 30 minutes. Once an
	request.		Allocate request has been authenticated using that username and
			password, if the result was an Allocate Error Response, the username
			and password are discarded. If the result was an Allocate Response,
			resulting in the creation of a new binding, the username and password
			become associated with that binding. They can only be used to
			authenticate Allocate requests sent from the same source transport
			address in order to refresh or de-allocate that binding. Once the
			binding is deleted, the username and password are discarded.
	OPEN ISSUE: Might be nice to request a lifetime in the		This policy avoids replay attacks, whereby a recorded Allocate
	Allocate request. TURN could be used for very long lived		request is replayed in order to obtain a binding without proper
	associations, such as a connection between a user and its		authentication. It also ensures that existing bindings can be
	proxy. Asking for a long one in that case (only useful for		refreshed without needed to continuously obtain one-time passwords
	TCP) would be a good thing.		from the TURN server.
	If the TURN server receives data on the Allocate tuple before the		7.2 Allocate Request
	remote-tuple has been filled in, the TURN server MUST treat that data
	as a TURN request. This means it will be responded to as the original
	request, providing the same MAPPED-ADDRESS once more. This is needed
	for reliability purposes.
	8 Client Behavior		7.2.1 Overview
	The behavior of the client is very simple. Its main task is to		Allocate requests are used to obtain an IP address and port that the
	discover the TURN server, formulate the request, and handle request		client can use to receive UDP and TCP packets from any host on the
	reliability.		network, even when the client is behind a symmetric NAT. To do this,
			a TURN server allocates a local transport address, and passes it to
			the client in an Allocate Response. When the server receives packets
			on this allocated address, it acts as a relay, and forwards them
			towards the source of the Allocate request. The server remembers the
			source transport address where that packet came from, and "locks
			down". This means that packets sent from the client to the TURN
			server are forwarded to that address.
			As a result, the server maintains a set of bindings. These bindings
			are associations between the five-tuple of received Allocate requests
			(source IP address and port, destination IP address and port, and
			protocol), called the allocate five-tuple, and another five tuple,
			called the remote five-tuple.
			The behavior of the server when receiving an Allocate Request depends
			on whether the request is an initial one, or a subsequent one. An
			initial request is one received with a source transport address which
			is not associated with any existing bindings. A subsequent request is
			one received that is associated with an existing binding.
			7.2.2 Initial Requests
			A TURN server MUST be prepared to receive Binding Requests over TCP
			and UDP. The port on which to listen is based on the DNS SRV entries
			provided by the server. Typically, this will be XXXX, the default
			TURN port. [[OPEN ISSUE: Can we just use the STUN port?]].
			The server MUST check the Allocate Request for a MESSAGE-INTEGRITY
			attribute. If not present, the server generates a Allocate Error
			Response with an ERROR-CODE attribute with response code 401.
			If the MESSAGE-INTEGRITY attribute was present, the server checks for
			the existence of the USERNAME attribute. If it was not present, the
			server MUST generate a Allocate Error Response. The Allocate Error
			Response MUST include an ERROR-CODE attribute with response code 432.
			If the USERNAME is present, the server computes the HMAC over the
			request as described in Section 11.2.8 of STUN. The key is equal to
			the password associated with the username in the request, where that
			username is a short term username allocated by the TURN server. The
			username MUST be one which has been allocated by the server in a
			Shared Secret Response, but has not yet been used to authenticate an
			Allocate request. If that username is not known by the server, or has
			already been used, the server generates an Allocate Error Response.
			That response MUST include an ERROR-CODE attribute with response code
			430.
			If the computed HMAC differs from the one from the MESSAGE-INTEGRITY
			attribute in the request, the server MUST generate a Allocate Error
			Response with an ERROR-CODE attribute with response code 431.
			Assuming the message integrity check passed, processing continues.
			The server MUST check for any attributes in the request with values
			less than or equal to 0x7fff which it does not understand. If it
			encounters any, the server MUST generate an Allocate Error Response,
			and it MUST include an ERROR-CODE attribute with a 420 response code.
			That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing
			the attributes with values less than or equal to 0x7fff which were
			not understood.
			If the Allocate request arrived over TCP, the Allocate Error Response
			is sent on the connection from which the request arrived. If the
			Allocate request arrived over UDP, the Allocate Error Response is
			sent to the transport address from which the request was received
			(i.e., the source IP address and port), and sent from the transport
			address on which the request was received (i.e., the destination IP
			address and port).
			Assuming the Allocate request was authenticated and was well-formed,
			the server attempts to allocate transport addresses. It first looks
			for the BANDWIDTH attribute for the request. If present, the server
			determines whether or not it has sufficient capacity to handle a
			binding that will generate the requested bandwidth. If so, the server
			looks for the presence of the TRANSPORT-PREFERENCES attribute in the
			request. If the attribute indicates that an even port is requested,
			the server attempts to allocate a transport address with an even
			port. If the attribute indicates that an odd port is requested, the
			server attempts to allocate a transport address with an odd port. If
			the attribute indicates that there is no preference for port parity,
			or if the TRANSPORT-PREFERENCES attribute was absent, the server
			attempts to allocate a port with either parity. The server MUST NOT
			allocate ports from the well-known port range (0-1023) and MUST NOT
			allocate ports from the user registered port range (1024 through
			49151).
			This aspect of the protocol helps guarantee that users cannot run
			servers (such as a web server, SIP server, or SMTP server) using
			TURN.
			The TRANSPORT-PREFERENCES attribute can also indicate a preference
			for a specific port, pre-allocated previously by a prior Allocate
			request. This case is described in Section 7.2.3.
			If a port meeting the constraints (including bandwidth) cannot be
			allocated, the server MUST generate a Allocate Error Response that
			includes an ERROR-CODE attribute with a response code of 300. That
			response MAY include an ALTERNATE-SERVER attribute pointing to an
			alternate server which can be used by the client.
			Assuming a port was allocated according to the preferences (call this
			the base port), the server checks to see if the TRANSPORT-PREFERENCES
			attribute is present, and indicates a desire to pre-allocate the next
			higher port (called the pre-allocated port). If so, the server
			attempts to allocate that port from its local operating system. If it
			cannot be allocated, the server can do one of two things. First, it
			MAY try to allocate a different base port, in the hopes that the next
			higher port is available. If the server believes that there are no
			adjacent ports meeting the parity constraints present in the request,
			the server MAY generate an Allocate Error Response that includes an
			ERROR-CODE attribute with a response code of 300. That response MAY
			include an ALTERNATE-SERVER attribute pointing to an alternate server
			which can be used by the client.
			Once a base port is allocated, the server creates a binding for it.
			This binding is a mapping between two five-tuples - the allocate
			five-tuple and the remote five-tuple. The allocate five-tuple is set
			to the five-tuple of the Allocate Request (that is, the protocol of
			the allocate five-tuple is set to the protocol of the Allocate
			Request (TCP or UDP), the source IP address and port of the allocate
			five-tuple are set to the source IP address and port in the Allocate
			Request, and the destination IP address and port of the allocate
			five-tuple are set to the destination IP address and port in the
			Allocate Request). The protocol in the remote five-tuple is set to
			the protocol from the Allocate Request. The source IP address of the
			remote five-tuple is set to the interface from which the base port
			was allocated. The source port of the remote five-tuple is set to the
			base port. If the binding was allocated for TCP, the connection on
			which the Allocate request was received is associated with the
			allocate five-tuple in the binding.
			The server MUST remember the one-time username and password used to
			obtain the binding.
			If a port was pre-allocated, a binding is also created for it. The
			allocate five-tuple is left empty. The protocol in the remote
			five-tuple is set to the protocol from the Allocate Request. The
			source IP address of the remote five-tuple is set to the interface
			from which the pre-allocated port was allocated. The source port of
			the remote five-tuple is set to the pre-allocated port. The identity
			of the user (defined as the username provided in the Shared Secret
			Request used to obtain the one-time password used in the Allocate
			Request) is associated with this pre-allocated tuple. Only that user
			can perform an allocation for this tuple. Furthermore, a timer is
			set. If no allocation is made against this pre-allocation within 5
			minutes, the port is released and the binding is deleted.
			If the LIFETIME attribute was present in the request, and the value
			is larger than the maximum duration the server is willing to use for
			the lifetime of the binding, the server MAY lower it to that maximum.
			However, the server MUST NOT increase the duration requested in the
			LIFETIME attribute. If there was no LIFETIME attribute, the server
			may choose a default duration at its discretion. In either cae, the
			resulting duration is added to the current time, and a timer is set
			to fire at or after that time. Section 7.4 discusses behavior when
			the timer fires.
			Once the base port has been obtained from the operating system, the
			pre-allocated port obtained, and the activity timer started for the
			base port binding, the server generates an Allocate Response. The
			Allocate Response MUST contain the same transaction ID contained in
			the Allocate Request. The length in the message header MUST contain
			the total length of the message in bytes, excluding the header. The
			Allocate Response MUST have a message type of "Allocate Response".
			The server MUST add a MAPPED-ADDRESS attribute to the Allocate
			Response. The IP address component of this attribute MUST be set to
			the interface from which the base port was allocated. The port
			component of this attribute MUST be set to the base port.
			The server MUST add a LIFETIME attribute to the Allocate Response.
			This attribute contains the duration, in seconds, of the activity
			timer associated with this binding.
			The server MUST add a BANDWIDTH attribute to the Allocate Response.
			This MUST be equal to the attribute from the request, if one was
			present. Otherwise, it indicates a per-binding cap that the server is
			placing on the bandwidth usage on each binding. Such caps are needed
			to prevent against denial-of-service attacks (See Section 10.
			The server MUST add, as the final attribute of the request, a
			MESSAGE-INTEGRITY attribute. The key used in the HMAC MUST be the
			same as that used to validate the request.
			The TURN server then sends the response. If the Allocate request was
			received over TCP, the response is sent over that TCP connection.
			Once the response is sent, the TURN server begins acting as a relay
			for that connection (see Section 7.3). If the Allocate request was
			received over UDP, the response is sent to the transport address from
			which the request was received (i.e., the source IP address and
			port), and sent from the transport address on which the request was
			received (i.e., the destination IP address and port).
			Additionally, if the base port was for UDP, the server MUST be
			prepared to receive UDP packets once the TURN response is sent. If
			the base port was for TCP, the server MUST be prepared to receive a
			TCP connection request on that port. Behavior when either occurs is
			described in Section 7.3.
			7.2.3 Requests for Pre-Allocated Ports
			The TRANSPORT-PREFERENCES attribute of the Allocate Request can
			indicate a desire to allocate a port that was previously
			pre-allocated by a prior Allocate request. If such an indication is
			present, the server checks that this port has been pre-allocated by a
			previous Allocate Request. The only user authorized to allocate a
			pre-allocated address is the same one that generated the
			pre-allocation. Note that the one-time usernames for both requests
			(the pre-allocation and the final allocation) will be different.
			However, both MUST have been obtained through Shared Secret Requests
			authenticated as being sent from the same user.
			If the Allocate request arrives on a different protocol than was used
			to make the pre-allocation, the server MUST send an Allocate Error
			Response. That response MUST contain an ERROR-CODE attribute with a
			response code of 400.
			Assuming the requested port has been pre-allocated by the same user,
			the server completes the allocation by setting the allocate
			five-tuple for the binding to be equal to that of the Allocate
			request. The server sets the activity timer for this binding, and
			generates an Allocate Response. This response MUST contain a
			MAPPED-ADDRESS attribute which contains the interface from which the
			pre-allocated port was obtained, along with the pre-allocated port.
			The response MUST contain a LIFETIME attribute and a
			MESSAGE-INTEGRITY attribute as well.
			7.2.4 Subsequent Requests
			Once a binding has been created, packets received from the client are
			generally forwarded to the remote client. However, if the binding is
			UDP, the client can send subsequent Allocate requests to the TURN
			server. To determine which packets are for the TURN server, and which
			need to be relayed, the server looks at the packet. If the packet is
			shorter than 28 bytes, it is not a TURN request. If it is longer than
			28 bytes, the server checks bytes 25-28. If these bytes are equal to
			the MAGIC-COOKIE, the request is a TURN request. Otherwise, it is a
			data packet, and is to be relayed.
			The server first authenticates the request. This is done as in
			Section 7.2.2. The request MUST be authenticated using the same
			one-time username and password used to allocate that binding
			previously. That is, the five-tuple from the Allocate request is
			compared to the allocate five-tuples in existing bindings. The
			matching binding is selected. The one-time username and password
			associated with that binding MUST match the ones used in the request.
			Any TRANSPORT-PREFERENCE attribute in the request is ignored. An
			Allocate Request sent to an existing binding is always a refresh or
			deallocation. The server looks for the LIFETIME attribute in the
			Allocate Request. If not found, it determines the default refresh
			duration, in seconds, for this binding. If the LIFETIME attribute was
			present in the request, and the value is larger than the maximum
			duration the server is willing to extend the lifetime of the binding,
			the server MAY lower it to that maximum. However, the server MUST NOT
			increase the duration requested in the LIFETIME attribute. The
			resulting duration is added to the current time, and the activity
			timer for this binding is reset to fire at or after that time.
			Section 7.4 discusses behavior when the timer fires.
			Once the timer is set, the server MUST generate an Allocate Response.
			The Allocate Response MUST contain the same transaction ID contained
			in the Allocate Request. The length in the message header MUST
			contain the total length of the message in bytes, excluding the
			header. The Allocate Response MUST have a message type of "Allocate
			Response". The response MUST contain a MAGIC-COOKIE as the first
			attribute. It MUST contain a MAPPED-ADDRESS which contains the source
			IP address and port from the remote five-tuple of the binding. It
			MUST contain a LIFETIME attribute which contains the time from now
			until the point at which the binding will be deleted. The final
			attribute MUST be a MESSAGE-INTEGRITY attribute, which MUST use the
			same one-time username and password used to authenticate the request.
			The TURN server then sends the response. If the Allocate request was
			received over TCP, the response is sent over that TCP connection. If
			the Allocate request was received over UDP, the response is sent to
			the transport address from which the request was received (i.e., the
			source IP address and port), and sent from the transport address on
			which the request was received (i.e., the destination IP address and
			port).
			7.3 Receiving Packets and Connections
			If a TURN server receives a TCP connection request on a port it has
			allocated, the server retrieves the binding whose remote five-tuple
			has a source address and source port that match the IP address and
			port to which the connection was made, and whose transport is TCP. If
			the destination IP address and port of the remote five-tuple in the
			binding are already filled in (which means that a connection was
			already made to this tuple), the connection request is rejected.
			Otherwise, it is accepted. If the connection is accepted, the server
			MUST set the destination IP address and port of the remote five-tuple
			to the source IP address and port in the SYN packet. It also
			associates this connection with the remote five-tuple.
			If a TURN server receives a UDP packet on a port it has allocated,
			the server retrieves the binding whose remote five-tuple has a source
			address and source port that match the IP address and port to which
			the connection was made, and whose transport is UDP. If the
			destination IP address and port of the remote five-tuple in the
			binding are already filled in, and do not match the source IP address
			and port of the UDP packet, the server drops the packet and MAY
			generate a port unreachable ICMP error. If the packet was not
			discareded, it is forwarded. To forward, the packet is sent with a
			source IP address and port equal to the destination IP address and
			port in the allocate five-tuple, and with a destination address and
			port equal to the source IP address and port in the allocate
			five-tuple. If the destination address and port of the remote
			five-tuple were not filled in, they are populated at this time. The
			server MUST set the destination IP address and port of the remote
			five-tuple to the source IP address and port in the UDP packet.
			The process of filling in the destination IP address and port of the
			remote five-tuple is called "locking down". Once done, the client can
			only send and receive packets with the specific peer from which the
			first packet or connection was received.
			If a TURN server receives a UDP packet on a port it has allocated,
			the server retrieves the binding whose remote five-tuple has a source
			address and source port that match the IP address and port to which
			the connection was made, and whose transport is UDP. If the
			destination IP address and port of the remote five-tuple in the
			binding are already filled in, and they match the source IP address
			and port of the UDP packet, the server MUST forward the UDP packet as
			above.
			If a TURN server receives data on a TCP connection that was opened to
			a port it had allocated, the server MUST forward this data onto the
			connection associated with allocate-tuple in the binding.
			If a TURN server receives data on a TCP connection that is associated
			with an allocate five-tuple, the binding for that tuple is retrieved.
			If the destination IP address and port of that tuple have not been
			filled in yet, the data is discarded. If the destination address and
			port have been filled in, the connection associated with the remote
			five-tuple is obtained, and the data is forwarded on that connection.
			Note that, because data is forwarded blindly across TCP bindings, TLS
			will successfully operate over a TURN allocated TCP port.
			Similarly, if a TURN server receives a UDP packet on one of its
			public TURN ports, it checks to see if the source IP address and port
			match those of the allocate five-tuples in an existing binding. If
			there is a match, the the UDP packet is not a TURN request (see
			Section 7.2.4 for details on how this determination is made), the
			destination IP address and port in the remote five-tuple of the
			binding are checked. If they are not filled in yet, the UDP packet is
			discarded. If they are, the packet is forwarded. It is forwarded
			using the source IP address and port from the remote five-tuple, and
			a destination IP address and port from the remote five-tuple.
			If a TCP connection associated with an allocate five-tuple is closed,
			the connection associated with the corresponding remote five-tuple is
			also closed. At that point, the binding is destroyed. Similarly, if
			the TCP connection associated with a remote five-tuple is closed, the
			connection associated with the corresponding allocate five-tuple is
			closed, and the binding is destroyed.
			7.4 Lifetime Expiration
			When the activity timer for a binding fires, the server checks to see
			if there has been any activity on the binding since its creation, or
			since the last firing of the timer, whichever is more recent.
			Activity is defined as connection establishment, or packet
			transmission in either direction. If there has been activity, the
			timer is set to fire once again in M seconds, where M is the value of
			the LIFETIME attribute returned in the most recent Allocate Response
			for this binding.
			If there has been no activity, the server MUST destroy the binding,
			along with its associated one-time password. If the binding was over
			TCP, the server MUST close any connections it is holding to the
			client and to the remote client.
			8. Client Behavior
			Client behavior is broken into several separate steps. First, the
			client obtains a one-time username and password. Secondly, it
			generates initial Allocate Requests, and processes the responses. It
			manages those addresses (refreshing and tearing them down), and
			processes data received on those addresses.
	8.1 Discovery		8.1 Discovery
	Generally, the client will be configured with a domain name of the		Generally, the client will be configured with a domain name of the
	provider of the TURN servers. This domain name is resolved to an IP		provider of the TURN servers. This domain name is resolved to an IP
	address and port of using the SRV procedures specified in [6]. The		address and port of using the SRV procedures [3]. When sending a
	service name is "turn". The protocol can be either "udp" or "tcp".		Shared Secret request, the service name is "turn" and the protocol is
			"tcp". RFC 2782 spells out the details of how a set of SRV records
			are sorted and then tried. However, it only states that the client
			should "try to connect to the (protocol, address, service)" without
			giving any details on what happens in the event of failure. Those
			details are described here for TURN.
	There is no reason at all that a turn server couldn't also		For TURN requests, failure occurs if there is a transport failure of
	make use of SCTP.		some sort (generally, due to fatal ICMP errors in UDP or connection
			failures in TCP). Failure also occurs if the the request does not
			solicit a response after 9.5 seconds. If a failure occurs, the client
			SHOULD create a new request, which is identical to the previous, but
			has a different transaction ID and MESSAGE-INTEGRITY attribute. That
			request is sent to the next element in the list as specified by
			RFC~2782.
	The procedures of RFC 2782 are followed to determine the server to		8.2 Obtaining a One Time Password
	contact, with the following additions. If an attempt is made to
	contact a server, and that attempt results in an ICMP error, or no
	response with 30 seconds, the client SHOULD attempt to contact the
	next server. Furthermore, if the client is trying to contact a
	server, and a server was contacted, but the response did not contain
	a MAPPED-ADDRESS or ALTERNATE-SERVER attribute, the client SHOULD
	attempt to contact the next server.
	The default port for TURN requests is [to be assigned by IANA].		In order to allocate addresses, a client must obtain a one-time
	Administrators SHOULD use this port in their SRV records, but MAY use		username and password from the TURN server. A unique username and
	others.		password are required for each distinct address allocated from the
			server.
	This would allow a firewall admin to open the TURN port, so		To obtain a one-time username and password, the client generates and
	hosts within the enterprise could access new applications.		sends a Shared Secret Request. This is done as described in Section
	Whether they will or won't do this is a good question.		9.2 of STUN. This request will have no attributes, and therefore,
			based on the processing in Section 7.1, the server will reject it
			with a Shared Secret Error Response with a 401 response code. That
			response will contain a NONCE and a REALM. The client SHOULD generate
			a new Shared Secret Request (with a new transaction ID), which
			contains the NONCE and REALM attributes copied from the 401 response.
			The request MUST include the USERNAME attribute, which contains a
			username supplied by the user for the specified realm. The request
			MUST include a MESSAGE-INTEGRITY attribute as the last attribute. The
			key for the HMAC is computed as described in Section 7.1.
	8.2 Authentication		If the response (either to the initial request or to the second
			attempt with the credentials) is a Shared Secret Error Response, the
			processing depends on the the value of the response code in the
			ERROR-CODE attribute. If the response code was a 430, the client
			SHOULD generate a new Shared Secret Request, using the username and
			password provided by the user, and the REALM and NONCE provided in
			the 430 response. For a 431 or 436 response code, the client SHOULD
			alert the user. For a 432, 434 and 435 response codes, if the client
			had omitted the USERNAME, REALM or NONCE attributes, respectively,
			from the previous request, it SHOULD retry, this time including the
			USERNAME, NONCE, REALM, and MESSAGE-INTEGRITY attributes. For a 500
			response code, the client MAY wait several seconds and then retry the
			request. For a 600 response code, the client MUST NOT retry the
			request, and SHOULD display the reason phrase to the user. Unknown
			attributes between 400 and 499 are treated like a 400, unknown
			attributes between 500 and 599 are treated like a 500, and unknown
			attributes between 600 and 699 are treated like a 600. Any response
			between 100 and 399 MUST result in the cessation of request
			retransmissions, but otherwise is discarded.
	A request formulated by the client follows the syntax rules defined		If a client receives a Shared Secret Response with an attribute whose
	in Section 10. Any two requests that are not bit-wise identical, or		type is greater than 0x7fff, the attribute MUST be ignored. If the
	not sent to the same server from the same IP address and port, MUST		client receives a Shared Secret Response with an attribute whose type
	carry different transaction IDs. The transaction ID MUST be uniformly		is less than or equal to 0x7fff, the response is ignored.
	and randomly chosen between 0 and 2^^32 - 1.
	Once formulated, the client sends the request. Reliability is		If the response is a Shared Secret Response, it will contain the
	accomplished through client retransmissions. Clients SHOULD		USERNAME and PASSWORD attributes. The client can use these to
	retransmit the request starting with an interval of 100ms, doubling		authenticate an Allocate Request, as described below.
	every retransmit. The client MAY give up after 32 seconds, or MAY
	continue trying.
	If the response contains a CHALLENGE attribute, the client formulates		A client MAY send multiple Shared Secret Requests over the same TLS
	a new request (with a new transaction ID), but otherwise identical to		connection, and MAY do so without waiting for responses to previous
	the previous request, with the addition of the AUTHENTICATION		requests. The client SHOULD close its connection when it has
	attribute. The realm and nonce fields of this attribute are copied		completed allocating usernames and passwords.
	from the response. The username is the user's identity at the given
	realm. The signature is computed as described in Section 10.2.2.
	A request with an AUTHENTICATION attribute MAY also contain a		8.3 Allocating a Binding
	CHALLENGE attribute, requesting authentication of the server.
	A client MAY cache the realm and nonce fields from the response, and		When a client wishes to obtain a transport address, it sends an
	use them to construct the AUTHENTICATION attribute in subsequent		Allocate Request to the TURN server. Requests for TCP transport
	requests to the same TURN server (identified by the destination IP		addresses MUST be sent over a TCP connection, and requests for UDP
	address and port).		transport addresses MUST be sent over UDP.
	8.3 Allocate request		First, the client obtains a one-time username and password, using the
			mechanisms described in Section 8.2. The client then formulates an
			Allocate Request. The request MUST contain a transaction ID, unique
			for each request, and uniformly and randomly distributed between 0
			and 2**128 - 1. The message type of the request MUST be ``Allocate
			Request''. The length is set as described in Section 11.1 of STUN.
	An Allocate request has no mandatory attributes, and the only		The Allocate request MUST contain the MAGIC-COOKIE attribute as the
	optional attributes are AUTHENTICATION and CHALLENGE, whose usage is		first attribute. If the client wishes to allocate an odd or even
	described above.		port, it can do so by including the TRANSPORT-PREFERENCES attribute
			in the request. That attribute can also be used by the client if it
			wishes to pre-allocate the port one higher.
	If the response contains an ALTERNATE-SERVER attribute, the client		The client SHOULD include a BANDWIDTH attribute, which indicates the
	SHOULD formulate a new Allocate request, and send it to that server.		maximum bandwidth that will be used with this binding. If the maximum
	Otherwise, if there is no ALTERNATE-SERVER attribute, but no MAPPED-		is unknown, the attribute is not included in the request.
	ADDRESS attribute, the client SHOULD continue SRV procedures from the
	point it left off to find the next available server.
	Otherwise, the response will contain a MAPPED-ADDRESS attribute with		The client MAY request a particular lifetime for the binding by
	an IP address and port that the client can use within an application.		including it in the LIFETIME attribute in the request. If the no data
	The response will also contain a LIFETIME attribute, which indicates		is sent or received on the binding before expiration of the lifetime,
	amount of time until the mapping will be invalidated.		the binding will be deleted by the client.
	The TURN client should listen for data on the same socket used to		The client MUST include a USERNAME attribute, containing a username
	send the Allocate address. Any data sent to the MAPPED-ADDRESS will		obtained from a previous Shared Secret Response. The request MUST
	show up on this socket. Once it receives data, the client can send		include a MESSAGE-INTEGRITY attribute as the last attribute. The key
	data, and it will be delivered to the same host and port which sent		is equal to the password obtained from the PASSWORD attribute of the
	the data to the MAPPED-ADDRESS.		Shared Secret Response. The Allocate Request MUST be sent to the same
			IP address and port as the Shared Secret Request. This is because one
			time passwords are expected to be host-specific. Rules for
			retransmissions for Allocate Requests sent over UDP are identical to
			those for STUN Binding Requests. Allocate Requests sent over TCP are
			not retransmitted. Transaction timeouts are identical to those for
			STUN Binding Requests, independent of the transport protocol.
	9 Example Usage		8.4 Processing Allocate Responses
	9.1 UDP Allocation		If the response is an Allocate Error Response, the client checks the
			response code from the ERROR-CODE attribute of the response. For a
			400 response code, the client SHOULD display the reason phrase to the
			user. For a 420 response code, the client SHOULD retry the request,
			this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES
			attribute of the response. For a 430 response code, the client SHOULD
			obtain a new one-time username and password, and retry the Allocate
			Request with a new transaction. For 401 and 432 response codes, if
			the client had omitted the USERNAME or MESSAGE-INTEGRITY attribute as
			indicated by the error, it SHOULD try again with those attributes. A
			new one-time username and password is needed in that case. For a 431
			response code, the client SHOULD alert the user, and MAY try the
			request again after obtaining a new username and password. For a 300
			response code, the client SHOULD attempt a new TURN transaction to
			the server indicated in the ALTERNATE-SERVER attribute. For a 500
			response code, the client MAY wait several seconds and then retry the
			request with a new username and password. For a 600 response code,
			the client MUST NOT retry the request, and SHOULD display the reason
			phrase to the user. Unknown attributes between 400 and 499 are
			treated like a 400, unknown attributes between 500 and 599 are
			treated like a 500, and unknown attributes between 600 and 699 are
			treated like a 600. Unknown attributes between 300 and 399 are
			treated like 300. Any response between 100 and 299 MUST result in the
			cessation of any request retransmissions, but otherwise is discarded.
	Figure 2 shows the process of allocating a request for receipt of UDP		If a client receives a response with an attribute whose type is
	packets.		greater than 0x7fff, the attribute MUST be ignored. If the client
			receives a response with an attribute whose type is less than or
			equal to 0x7fff, any request retransmissions MUST cease, but the
			entire response is otherwise ignored.
	In message 1, the client sends a TURN Allocate request to the server.		If the response is an Allocate Response, the client MUST check the
	This passes through the NAT, which rewrites the source address		response for a MESSAGE-INTEGRITY attribute. If not present, the
	(message 2). The TURN server allocates a MAPPED-ADDRESS,		client MUST discard the response. If present, the client computes the
	9.8.7.6:1124, and returns it in the TURN response (message 3). This		HMAC over the response. The key MUST be same as used to compute the
	response has its destination rewritten by the NAT (message 4). The		MESSAGE-INTEGRITY attribute in the request. If the computed HMAC
	client can then use this information in an application, such as SIP		differs from the one in the response, the client MUST discard the
	[8], and the result is that the address is passed to some other		response, and SHOULD alert the user about a possible attack. If the
	element (message 5), called the peer. The peer then decides to send		computed HMAC matches the one from the response, processing
	data of some sort (perhaps RTP packets), to the client. It sends it		continues.
	to the mapped address, 9.8.7.6:1124, which will arrive at the TURN
	server and then is forwarded to the client. Any data the client sends
	is then forwarded back to the peer.
	9.2 Authentication		The MAPPED-ADDRESS in the Binding Response can be used by the client
	TURN NAT Turn		for receiving packets. The server will expire the binding after
	Client Server		LIFETIME seconds have passed with no activity. The server will allow
	| | |		the user to send and receive no more than the amount of data
	| Allocate |		indicated in the BANDWIDTH attribute.
	| with CHALLENGE |
	|-------->|--------->|
	| | |
	| Response with |
	| CHALLENGE |
	|<--------|<---------|
	| | |
	| Allocate with |
	| CHALLENGE and |
	| AUTHENTICATION |
	|-------->|--------->|
	| | | <-- TURN Server now waiting
	| Response with | on MAPPED-ADDRESS
	| AUTHENTICATION and |
	| MAPPED-ADDRESS |
	| | X <-----| Packet Loss
	| | |
	| .. client waits .. |
	| | |
	| Allocate with |
	| CHALLENGE and |
	| AUTHENTICATION |
	|-------->|--------->|
	| | |
	| Response with |
	| AUTHENTICATION and |
	| MAPPED-ADDRESS |
	|<--------|----------|
	| | |
	Figure 3: Flow for mutual authentication		8.5 Allocating a Pre-Allocated Binding
	Figure 3 shows the basic flow for mutual authentication. The client		If the initial Allocate Request included TRANSPORT-PREFERENCES that
	sends a request with a challenge. The server wishes to authenticate		indicated a desire to pre-allocate the port one-higher, the client
	the client, so it responds to the request with its own challenge, but		MAY allocate that port at a later time. It MUST do so within 4
	no authentication attribute. The client retries the request, once		minutes of receiving the Allocate Response, or the pre-allocated port
	again with a challenge attribute and also with an authentication		will expire.
	attribute. The server accepts this, and sends a response with its own
	authentication attribute, along with the mapped address. A retransmit
	Client NAT Turn Server Peer
	|(1) Allocate | | |
	| src=10.0.1.1:8898 | | |
	| dest=9.8.7.6:8765 |(2) Allocate | |
	|------------------>| src=1.2.3.4:6544 | |
	| | dest=9.8.7.6:8765 | |
	| |------------------>| |
	| |(3) Response | |
	|(4) Response | mapped=9.8.7.6:1124, src=9.8.7.6:8765 |
	| mapped=9.8.7.6:1123 dest=1.2.3.4:6544 | |
	| src=9.8.7.6:8765 |<------------------| |
	| dest=10.0.1.1:8898| | |
	|<------------------| | |
	| | | |
	|(5) Sends 9.8.7.6:1124 to peer | |
	|---------------------------------------------------------->|
	| | | |
	| | |(6) Data |
	| | | src=5.5.5.5:5555 |
	| |(7) Data | dest=9.8.7.6:1124 |
	| | src=9.8.7.6:8765 |<------------------|
	|(8) Data | dest=1.2.3.4:6544 | |
	| src=9.8.7.6:8765 |<------------------| |
	| dest=10.0.1.1:8898| | |
	|<------------------| | |
	| | | |
	|(9) Data Response | | |
	| src=10.0.1.1:8898 | | |
	| dest=9.8.7.6:8765 |(10) Data Response | |
	|------------------>| src=1.2.3.4:6544 |(11) Data Response |
	| | dest=9.8.7.6:8765 | src=9.8.7.6:1124 |
	| |------------------>| dest=5.5.5.5:5555 |
	| | |------------------>|
	| | | |
	Figure 2: Example flow		To allocate the port, the client generates an Allocate Request as
	of the request triggers the same response to be sent.		described in Section 8.3. A new username and password MUST be used
			for this allocation. The request MUST contain a TRANSPORT-PREFERENCES
			attribute. It MUST indicate an explicit interface and port, whose
			value is one higher than the port number returned in the prior
			Allocate Response.
	10 Protocol Details		Processing of the responses is identical to Section 8.4. However, the
			client SHOULD explicitly check that received packets are TURN
			responses, as opposed to data packets, using the techniques described
			in Section 7.2.4.
	This section presents the detailed encoding of the attributes which		8.6 Refreshing a Binding
	are new to TURN. The general message structure is identical to STUN
	[2].
	10.1 Message Header		If there has been no activity on a UDP binding for a period of time
			equalling 3/4 of the lifetime of the binding (as conveyed in the
			LIFETIME attribute of the Allocate Response), the client SHOULD
			refresh the binding with another Allocate Request if it wishes to
			keep it. Note that only UDP bindings can be refreshed. For TCP,
			application-specific keepalives are needed.
	TURN defines two new Message Types:		To perform a refresh, the client generates an Allocate Request as
			described in Section 8.3. However, the one-time username and password
			used MUST be the same as those used in the successful Allocate
			Request for that binding. The client will need to look for the TURN
			response amongst the data packets using the MAGIC-COOKIE, as
			described in Section 7.2.4. Processing of that response is as defined
			in Section 8.4. If the response was an Allocate Response, and the
			MAPPED-ADDRESS contains the same transport address as previously
			obtained, the binding has been refreshed. The LIFETIME attribute
			indicates the amount of additional time the binding will live without
			activity. If, however, the response was an Allocate Error Response
			with an ERROR-CODE indicating a 430 response, it means that the
			binding has expired at the server. The client MAY use the procedures
			in Section 8.3 to obtain a new binding (this will require a new
			one-time username and password. Other response codes do not imply
			that the binding has been expired, just that the refresh has failed.
	0x0002 : Allocate Request		8.7 Tearing Down a Binding
	0x0102 : Allocate Response
	10.2 Message Attributes		If a client no longer needs a binding, it SHOULD tear it down. For
			TCP, this is done by closing the connection. For UDP, this is done by
			performing a refresh, as described in Section 8.6, but with a
			LIFETIME attribute indicating a time of 0.
	The following additional attributes are defined:		8.8 Receiving and Sending Data
	0x0004: CHALLENGE		Once a binding has been allocated by an Allocate Response, the client
	0x0005: AUTHENTICATION		MUST be prepared to receive data from the socket on which the
	0x0006: LIFETIME		Allocate Request was sent. For UDP, the client MUST be prepared to
	0x0007: ALTERNATE-SERVER		disambiguate TURN messages from data for a period of 32 seconds
			following the first TURN response. This disambiguation is done using
			the MAGIC-COOKIE, as described in Section 7.2.4.
	10.2.1 CHALLENGE		Once data has been received, the client MAY send data to its peer by
			sending data on that same socket. Sending data on the socket before
			data is received will cause the data to be discarded by the server.
	The CHALLENGE attribute contains a challenge, either from the server,		9. Protocol Details
	for credentials in order to process the request, or from the client,
	for credentials in order to process the response.
	The CHALLENGE contains two strings: a realm, and a nonce. Both are		This section presents the detailed encoding of the message types,
	encoded using a 16 bit length followed by the string. The string MUST		attributes, and response codes which are new to TURN. The general
	NOT be null terminated. The 32 bit alignment of the lengths in the		message structure of TURN is identical to STUN [1].
	diagram below is for readability purposes only. No padding is
	required after the end of the string for the realm.		9.1 Message Types
			TURN defines three new Message Types:
			0x0003 : Allocate Request
			0x0103 : Allocate Response
			0x0113 : Allocate Error Response
			9.2 Message Attributes
			TURN defines the following message attributes:
			0x000c: TRANSPORT-PREFERENCES
			0x000d: LIFETIME
			0x000e: ALTERNATE-SERVER
			0x000f: MAGIC-COOKIE
			0x0010: BANDWIDTH
			9.2.1 TRANSPORT-PREFERENCES
			The TRANSPORT-PREFERENCES attribute indicates preferences for the
			ports allocated by the TURN server. It is either 32 or 96 bits long,
			depending on the value of the Typ bits. These bits indicate the
			preferences for the allocated port:
			0b00: no preferences
			0b01: odd port parity
			0b10: even port parity
			0b11: allocate a pre-allocated port
			When the Typ bits are 0b11, the following 64 bits encode the
			pre-allocated transport address. They are in the same format used for
			MAPPED-ADDRESS.
			The P bit indicates a desire for pre-allocating the port one-higher.
			If 1, it means pre-allocation is desired. This bit MUST NOT be set to
			1 if the Typ bits are 0b11. That is, pre-allocation cannot be done
			again when allocating a previously pre-allocated port.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Realm ...		| 0 |P|Typ|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Nonce ...		|x x x x x x x x| Family | Port |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The realm represents a domain over which the entity is to supply a
	username and password. It is defined in [7]. The nonce is a randomly
	chosen string that is fed into the signature computation. Nonce
	selection procedures can be found in [7] and [9].
	10.2.2 AUTHENTICATION		9.2.2 LIFETIME
	The authentication attribute provides credentials. It contains three		The lifetime attribute represents the duration for which the server
	strings: a realm, a nonce, a signature, and a username. They are		will maintain a binding in the absence of data traffic either from or
	encoded using a 16 bit length, followed by the string (the strings		to the client. It is a 32 bit value representing the number of
	MUST NOT be null terminated).		seconds remaining until expiration.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Realm ...		| Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Nonce ...
			9.2.3 ALTERNATE-SERVER
			The alternate server represents an alternate IP address and port for
			a different TURN server to try. It is encoded in the same way as
			MAPPED-ADDRESS.
			9.2.4 MAGIC-COOKIE
			The MAGIC-COOKIE is used by TURN clients and servers to disambiguate
			TURN traffic from data traffic. Its value ix 0x72c64bc6.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Signature ...		|0|1|1|1|0|0|1|0|1|1|0|0|0|1|1|0|0|1|0|0|1|0|1|1|1|1|0|0|0|1|1|0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Username ...
			9.2.5 BANDWIDTH
			The bandwidth attribute represents the peak bandwidth, measured in
			kbits per second, that the client expects to use on the binding. The
			value represents the sum in the receive and send directions.
			[[Editors note: Need to define leaky bucket parameters for this.]]
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Bandwidth |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The realm and nonce are described in [7]. The username is the user		9.3 Response Codes
	identity. The signature is computed as follows.
	The entire TURN request, including the TURN headers, up to the end of		TURN defines the following new response codes:
	the last attribute before the AUTHENTICATION attribute, is taken as
	string "S". String "S" is base64 encoded to become string "B". The
	signature is computed as the request-digest token, according to the
	rules of RFC 2617, as if A1 was equal to string "B", and qop was
	unspecified.
	10.2.3 LIFETIME		300 (Try Alternate): The client should contact an alternate server
			for this request.
	The lifetime attribute represents the duration that a mapping is		434 (Missing Realm): The REALM attribute was not present in the
	valid. It is a 32 bit value representing the number of seconds		request.
	remaining until expiration.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		435 (Missing Nonce): The NONCE attribute was not present in the
	| Lifetime |		request.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	10.2.4 ALTERNATE-SERVER		436 (Unknown Username): The USERNAME supplied in the Shared Secret
			Request is not known in the given REALM.
	The alternate server represents an alternate IP address and port for		10. Security Considerations
	a different allocation server to try. It is encoded in the same way
	as MAPPED-ADDRESS.
	11 Security Considerations		TURN servers allocate bandwidth and port resources to clients.
			Therefore, a TURN server requires authentication and authorization of
			TURN requests. This authentication is provided by a client digest
			over TLS, which results in the generation of a one-time password that
			is used in a single subsequent Allocate Request. This mechanism
			protects against eavesdropping attacks and man-in-the-middle attacks.
			The usage of one-time passwords ensures that the Allocate Requests,
			which do not run over TLS, are not susceptible to offline dictionary
			attacks that can be used to guess the long lived shared secret
			between the client and the server.
	TURN servers, unlike STUN servers, create state upon processing of		Because TURN servers allocate resources, they can be susceptible to
	requests. As a result, they SHOULD authenticate all requests before		denial-of-service attacks. All Allocate Requests are authenticated,
	allocating a mapping to the client. Furthermore, it is RECOMMENDED		so that an unknown attacker cannot launch an attack. An authenticated
	that authorization policies be used to prevent a single user from		attacker can generate multiple Allocate Requests, but each requires a
	allocating more than a configured number of mappings. This prevents		new one-time username and password. It is RECOMMENDED that servers
	hogging of resources by an attacker.		implement a cap on the number of one-time passwords that are
			allocated to any specific user at a time (around 5 or 10 should be
			sufficient). This will prevent floods of Allocate requests from a
			single user, in an attempt to use up the resources of the system. A
			single malicious user could generate a single Allocate Request,
			obtain a binding, and then flood the server with data over this
			binding, in an attempt to deny others service. However, this attack
			requires the attacker themselves to receive the data being sent at
			the server. To ameliorate these kinds of attacks, servers SHOULD
			implement a bandwidth cap on each binding (conveyed to the client in
			the BANDWIDTH attribute of the Allocate Response), and discard
			packets beyond the threshold.
			A client will use the transport address learned from the
			MAPPED-ADDRESS attribute of the Binding Response to tell other users
			how to reach them. Therefore, a client needs to be certain that this
			address is valid, and will actually route to them. Such validation
			occurs through the TLS and HMAC-based authentication and integrity
			checks provided in TURN. They can guarantee the authenticity and
			integrity of the mapped addressses. Note that TURN is not susceptible
			to the attacks described in Section 12.2.3, 12.2.4, 12.2.5 or 12.2.6
			of STUN. These attacks are based on the fact that a STUN server
			mirrors the source IP address, which cannot be authenticated. TURN
			does not use the source address of the Binding Request, and
			therefore, those attacks do not apply.
			Confidentiality of the transport addresses learned through TURN does
			not appear to be that important, and therefore, this capability is
			not provided.
	TURN servers are useful even for users not behind a NAT. They can		TURN servers are useful even for users not behind a NAT. They can
	provide a way for truly anonymous communications. A user can cause a		provide a way for truly anonymous communications. A user can cause a
	call to have its media routed through a TURN server, so that the		call to have its media routed through a TURN server, so that the
	user's IP addresses are never revealed.		user's IP addresses are never revealed.
	TURN has the important property that compromise of the TURN servers		TCP transport addresses allocated by TURN will properly work with TLS
	cannot cause security breaches when the client is within an		and SSL. However, any addresses allocated by TURN will not operate
	enterprise. The only thing that a compromised server can do is return		properly with IPSec Authentication Header (AH) [10] in transport
	false addresses, resulting in the inability of the client to receive		mode. IPSec ESP [11] and any tunnel-mode ESP or AH should still
	any data at all. The protocol is therefore fail safe.		operate.
	12 Authors Addresses		11. IAB Considerations
			The IAB has studied the problem of ``Unilateral Self Address
			Fixing'', which is the general process by which a client attempts to
			determine its address in another realm on the other side of a NAT
			through a collaborative protocol reflection mechanism RFC 3424 [12].
			TURN is an example of a protocol that performs this type of function.
			The IAB has mandated that any protocols developed for this purpose
			document a specific set of considerations. This section meets those
			requirements.
			11.1 Problem Definition
			From RFC 3424 [12], any UNSAF proposal must provide:
			Precise definition of a specific, limited-scope problem that is to
			be solved with the UNSAF proposal. A short term fix should not
			be generalized to solve other problems; this is why "short term
			fixes usually aren't".
			The specific problem being solved by TURN 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. TURN, by
			design, does not allow a client to run a server (such as a web or
			SMTP server) using a TURN address. TURN is useful even when NAT is
			not present, to provide anonymity services.
			11.2 Exit Strategy
			From [12], any UNSAF proposal must provide:
			Description of an exit strategy/transition plan. The better short
			term fixes are the ones that will naturally see less and less use
			as the appropriate technology is deployed.
			It is expected that TURN will be useful indefinitely, to provide
			anonymity services. When used to facilitate NAT traversal, TURN does
			not iself provide an exit strategy. That is provided by the
			Interactive Connectivity Establishment (ICE) [13] mechanism. ICE
			allows two cooperating clients to interactively determine the best
			addresses to use when communicating. ICE uses TURN-allocated
			addresses as a last resort, only when no other means of connectivity
			exists. As a result, as NATs phase out, and as IPv6 is deployed, ICE
			will increasingly use other addresses (host local addresses).
			Therefore, clients will allocate TURN addresses, but not use them,
			and therefore, de-allocate them. Servers will see a decrease in
			usage. Once a provider sees that its TURN servers are not being used
			at all (that is, no media flows through them), they can simply remove
			them. ICE will operate without TURN-allocated addresses.
			11.3 Brittleness Introduced by TURN
			From [12], any UNSAF proposal must provide:
			Discussion of specific issues that may render systems more
			"brittle". For example, approaches that involve using data at
			multiple network layers create more dependencies, increase
			debugging challenges, and make it harder to transition.
			TURN introduces brittleness in a few ways. First, it adds another
			server element to any system, which adds another point of failure.
			TURN requires clients to demultiplex TURN packets and data based on
			hunting for a MAGIC-COOKIE in the TURN messages. It is 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. TURN relies on any NAT bindings
			existing for the duration of the bindings held by the TURN server.
			Neither the client nor the TURN server have a way of reliably
			determining this lifetime (STUN can provide a means, but it is
			heuristic in nature and not reliable). Therefore, if there is no
			activity on an address learned from TURN for some period, the address
			might become useless spontaneously.
			TURN will result in potentially significant increases in packet
			latencies, and also increases in packet loss probabilities. That is
			because it introduces an intermediary on the path of a packet from
			point A to 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 TURN addresses. However, when used, this problem will
			exist.
			Note that TURN does not suffer from many of the points of brittleness
			introduced by STUN. TURN will work with all existing NAT types known
			at the time of writing, and for the forseeable future. TURN does not
			introduce any topological constraints. TURN does not rely on any
			heuristics for NAT type classification.
			11.4 Requirements for a Long Term Solution
			From [12]}, any UNSAF proposal must provide:
			Identify requirements for longer term, sound technical solutions
			-- contribute to the process of finding the right longer term
			solution.
			Our experience with TURN continues to validate our belief in the
			requirements outlined in Section 14.4 of STUN.
			11.5 Issues with Existing NAPT Boxes
			From [12], any UNSAF proposal must provide:
			Discussion of the impact of the noted practical issues with
			existing, deployed NA[P]Ts and experience reports.
			A number of NAT boxes are now being deployed into the market which
			try and provide "generic" ALG functionality. These generic ALGs hunt
			for IP addresses, either in text or binary form within a packet, and
			rewrite them if they match a binding. This will interfere with proper
			operation of any UNSAF mechanism, including TURN. However, if a NAT
			tries to modify a MAPPED-ADDRESS in a TURN Allocate Response, this
			will be detected by the client as an attack.
			12. Requirements Analysis
			TODO.
			13. Examples
			TODO.
			Normative References
			[1] Rosenberg, J., Huitema, C., Mahy, R. and J. Weinberger, "STUN -
			Simple Traversal of UDP Through Network Address Translators",
			draft-ietf-midcom-stun-05 (work in progress), December 2002.
			[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119, March 1997.
			[3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
			specifying the location of services (DNS SRV)", RFC 2782,
			February 2000.
			[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
			Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
			Basic and Digest Access Authentication", RFC 2617, June 1999.
			Informative References
			[5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
			"RTP: A Transport Protocol for Real-Time Applications", RFC
			1889, January 1996.
			[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
			Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
			Session Initiation Protocol", RFC 3261, June 2002.
			[7] Handley, M. and V. Jacobson, "SDP: Session Description
			Protocol", RFC 2327, April 1998.
			[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
			Protocol (RTSP)", RFC 2326, April 1998.
			[9] Senie, D., "Network Address Translator (NAT)-Friendly
			Application Design Guidelines", RFC 3235, January 2002.
			[10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
			November 1998.
			[11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
			(ESP)", RFC 2406, November 1998.
			[12] Daigle, L. and IAB, "IAB Considerations for UNilateral
			Self-Address Fixing (UNSAF) Across Network Address
			Translation", RFC 3424, November 2002.
			[13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
			Methodology for Nettwork Address Translator (NAT) Traversal
			for the Session Initiation Protocol (SIP)",
			draft-rosenberg-sipping-ice-00 (work in progress), February
			2003.
			Authors' Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		dynamicsoft
	72 Eagle Rock Avenue		72 Eagle Rock Avenue
	First Floor		East Hanover, NJ 07936
	East Hanover, NJ 07936		US
	email: jdrosen@dynamicsoft.com
			Phone: +1 973 952-5000
			EMail: jdrosen@dynamicsoft.com
			URI: http://www.jdrosen.net
	Joel Weinberger		Joel Weinberger
	dynamicsoft		dynamicsoft
	72 Eagle Rock Avenue		72 Eagle Rock Avenue
	First Floor		East Hanover, NJ 07936
	East Hanover, NJ 07936		US
	email: jweinberger@dynamicsoft.com
	Christian Huitema		Phone: +1 973 952-5000
	Microsoft Corporation		EMail: jweinberger@dynamicsoft.com
	One Microsoft Way
	Redmond, WA 98052-6399
	email: huitema@microsoft.com
	Rohan Mahy		Rohan Mahy
	Cisco Systems		Cisco Systems
	170 West Tasman Dr, MS: SJC-21/3		101 Cooper St
	Phone: +1 408 526 8570		Santa Cruz, CA 95060
	Email: rohan@cisco.com		US
	13 Bibliography		EMail: rohan@cisco.com
	[1] D. Senie, "NAT friendly application design guidelines," Internet		Christian Huitema
	Draft, Internet Engineering Task Force, Mar. 2001. Work in progress.		Microsoft
			One Microsoft Way
			Redmond, WA 98052-6399
			US
	[2] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN -		EMail: huitema@microsoft.com
	simple traversal of UDP through NATs," Internet Draft, Internet
	Engineering Task Force, Oct. 2001. Work in progress.
	[3] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm		Intellectual Property Statement
	specific IP: framework," Request for Comments 3102, Internet
	Engineering Task Force, Oct. 2001.
	[4] M. Borella, D. Grabelsky, J. Lo, and K. Taniguchi, "Realm		The IETF takes no position regarding the validity or scope of any
	specific IP: protocol specification," Request for Comments 3103,		intellectual property or other rights that might be claimed to
	Internet Engineering Task Force, Oct. 2001.		pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication and any assurances of
			licenses to be made available, or the result of an attempt made to
			obtain a general license or permission for the use of such
			proprietary rights by implementors or users of this specification can
			be obtained from the IETF Secretariat.
	[5] S. Bradner, "Key words for use in RFCs to indicate requirement		The IETF invites any interested party to bring to its attention any
	levels," Request for Comments 2119, Internet Engineering Task Force,		copyrights, patents or patent applications, or other proprietary
	Mar. 1997.		rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
	[6] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying		Full Copyright Statement
	the location of services (DNS SRV)," Request for Comments 2782,
	Internet Engineering Task Force, Feb. 2000.
	[7] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach,		Copyright (C) The Internet Society (2003). All Rights Reserved.
	A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest
	access authentication," Request for Comments 2617, Internet
	Engineering Task Force, June 1999.
	[8] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:		This document and translations of it may be copied and furnished to
	session initiation protocol," Request for Comments 2543, Internet		others, and derivative works that comment on or otherwise explain it
	Engineering Task Force, Mar. 1999.		or assist in its implementation may be prepared, copied, published
			and distributed, in whole or in part, without restriction of any
			kind, provided that the above copyright notice and this paragraph are
			included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
	[9] J. Rosenberg, "Request header integrity for SIP and HTTP digest		The limited permissions granted above are perpetual and will not be
	using predictive nonces," Internet Draft, Internet Engineering Task		revoked by the Internet Society or its successors or assignees.
	Force, June 2001. Work in progress.
	Table of Contents		This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
			BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
			HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
			MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	1 Introduction ........................................ 1		Acknowledgement
	2 Do we need this Protocol? .......................... 2
	3 Terminology ......................................... 3		Funding for the RFC Editor function is currently provided by the
	4 Definitions ......................................... 3		Internet Society.
	5 Overview of Operation ............................... 4
	6 Message Overview .................................... 5
	7 Server Behavior ..................................... 6
	7.1 Client Authentication ............................... 6
	7.2 Server Authentication ............................... 6
	7.3 Allocation .......................................... 6
	8 Client Behavior ..................................... 8
	8.1 Discovery ........................................... 8
	8.2 Authentication ...................................... 9
	8.3 Allocate request .................................... 10
	9 Example Usage ....................................... 10
	9.1 UDP Allocation ...................................... 10
	9.2 Authentication ...................................... 10
	10 Protocol Details .................................... 13
	10.1 Message Header ...................................... 13
	10.2 Message Attributes .................................. 13
	10.2.1 CHALLENGE ........................................... 13
	10.2.2 AUTHENTICATION ...................................... 14
	10.2.3 LIFETIME ............................................ 14
	10.2.4 ALTERNATE-SERVER .................................... 15
	11 Security Considerations ............................. 15
	12 Authors Addresses ................................... 15
	13 Bibliography ........................................ 16
End of changes. 128 change blocks.
	551 lines changed or deleted		1285 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/