idnits 2.17.1 draft-rosenberg-midcom-turn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 7, 2003) is 7506 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Unexpected draft version: The latest known version of draft-ietf-midcom-stun is -04, but you're referring to -05. ** Obsolete normative reference: RFC 2617 (ref. '4') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '5') (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '7') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '8') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '10') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '11') (Obsoleted by RFC 4303, RFC 4305) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIDCOM J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: April 6, 2004 R. Mahy 4 Cisco Systems 5 C. Huitema 6 Microsoft 7 October 7, 2003 9 Traversal Using Relay NAT (TURN) 10 draft-rosenberg-midcom-turn-02 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 6, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 Traversal Using Relay NAT (TURN) is a protocol that allows for an 41 element behind a NAT or firewall to receive incoming data over TCP or 42 UDP connections. It is most useful for elements behind symmetric NATs 43 or firewalls that wish to be on the receiving end of a connection to 44 a single peer. TURN does not allow for users to run servers on well 45 known ports if they are behind a nat; it supports the connection of a 46 user behind a nat to only a single peer. In that regard, its role is 47 to provide the same security functions provided by symmetric NATs and 48 firewalls, but to ``turn'' the tables so that the element on the 49 inside can be on the receiving end, rather than the sending end, of a 50 connection that is requested by the client. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Applicability Statement . . . . . . . . . . . . . . . . . . 7 58 5. Overview of Operation . . . . . . . . . . . . . . . . . . . 8 59 6. Message Overview . . . . . . . . . . . . . . . . . . . . . . 10 60 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . 11 61 7.1 Shared Secret Request . . . . . . . . . . . . . . . . . . . 11 62 7.2 Allocate Request . . . . . . . . . . . . . . . . . . . . . . 13 63 7.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 7.2.2 Initial Requests . . . . . . . . . . . . . . . . . . . . . . 13 65 7.2.3 Requests for Pre-Allocated Ports . . . . . . . . . . . . . . 17 66 7.2.4 Subsequent Requests . . . . . . . . . . . . . . . . . . . . 18 67 7.3 Receiving Packets and Connections . . . . . . . . . . . . . 19 68 7.4 Lifetime Expiration . . . . . . . . . . . . . . . . . . . . 21 69 8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . 22 70 8.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 8.2 Obtaining a One Time Password . . . . . . . . . . . . . . . 22 72 8.3 Allocating a Binding . . . . . . . . . . . . . . . . . . . . 23 73 8.4 Processing Allocate Responses . . . . . . . . . . . . . . . 24 74 8.5 Allocating a Pre-Allocated Binding . . . . . . . . . . . . . 25 75 8.6 Refreshing a Binding . . . . . . . . . . . . . . . . . . . . 26 76 8.7 Tearing Down a Binding . . . . . . . . . . . . . . . . . . . 26 77 8.8 Receiving and Sending Data . . . . . . . . . . . . . . . . . 26 78 9. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 27 79 9.1 Message Types . . . . . . . . . . . . . . . . . . . . . . . 27 80 9.2 Message Attributes . . . . . . . . . . . . . . . . . . . . . 27 81 9.2.1 TRANSPORT-PREFERENCES . . . . . . . . . . . . . . . . . . . 27 82 9.2.2 LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . . 28 83 9.2.3 ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . . . 28 84 9.2.4 MAGIC-COOKIE . . . . . . . . . . . . . . . . . . . . . . . . 28 85 9.2.5 BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . . 28 86 9.2.6 MORE-AVAILABLE . . . . . . . . . . . . . . . . . . . . . . . 29 87 9.3 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 29 88 10. Security Considerations . . . . . . . . . . . . . . . . . . 30 89 11. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 32 90 11.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . 32 91 11.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . 32 92 11.3 Brittleness Introduced by TURN . . . . . . . . . . . . . . . 33 93 11.4 Requirements for a Long Term Solution . . . . . . . . . . . 34 94 11.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . . 34 95 12. Requirements Analysis . . . . . . . . . . . . . . . . . . . 35 96 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 97 Normative References . . . . . . . . . . . . . . . . . . . . 37 98 Informative References . . . . . . . . . . . . . . . . . . . 38 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 100 Intellectual Property and Copyright Statements . . . . . . . 40 102 1. Introduction 104 Network Address Translators (NATs), while providing many benefits, 105 also come with many drawbacks. The most troublesome of those 106 drawbacks is the fact that they break many existing IP applications, 107 and make it difficult to deploy new ones. Guidelines [9] have been 108 developed that describe how to build "NAT friendly" protocols, but 109 many protocols simply cannot be constructed according to those 110 guidelines. Examples of such protocols include multimedia 111 applications and file sharing. 113 Simple Traversal of UDP Through NAT (STUN) [1] provides one means for 114 an application to traverse a NAT. STUN allows a client to obtain a 115 transport address (and IP address and port) which may be useful for 116 receiving packets from a peer. However, addresses obtained by STUN 117 may not be usable by all peers. Those addresses work depending on the 118 topological conditions of the network. Therefore, STUN by itself 119 cannot provide a complete solution for NAT traversal. 121 A complete solution requires a means by which a client can obtain a 122 transport address from which it can receive media from any peer which 123 can send packets to the public Internet. This can only be 124 accomplished by relaying data though a server that resides on the 125 public Internet. This specification describes Traversal Using Relay 126 NAT (TURN), a protocol that allows a client to obtain IP addresses 127 and ports from such a relay. 129 Although TURN will almost always provide connectivity to a client, it 130 comes at high cost to the provider of the TURN server. It is 131 therefore desirable to use TURN as a last resort only, preferring 132 other mechanisms (such as STUN or direct connectivity) when possible. 133 To accomplish that, the Interactive Connectivity Establishment (ICE) 134 [13] methodology can be used to discover the optimal means of 135 connectivity. 137 2. Terminology 139 In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, 140 SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to 141 be interpreted as described in RFC 2119 [2] and indicate requirement 142 levels for compliant TURN implementations. 144 3. Definitions 146 TURN Client: A TURN client (also just referred to as a client) is 147 an entity that generates TURN requests. A TURN client can be an 148 end system, such as a Session Initiation Protocol (SIP) [6] User 149 Agent, or can be a network element, such as a Back-to-Back User 150 Agent (B2BUA) SIP server. The TURN protocol will provide the STUN 151 client with IP addresses that route to it from the public 152 Internet. 154 TURN Server: A TURN Server (also just referred to as a server) is 155 an entity that receives TURN requests, and sends TURN responses. 156 The server is capable of acting as a data relay, receiving data on 157 the address it provides to clients, and forwarding them to the 158 clients. 160 Transport Address: An IP address and port. 162 4. Applicability Statement 164 TURN is useful for applications that require a client to place a 165 transport address into a protocol message, with the expectation that 166 the client will be able to receive packets from a single host that 167 will send to this address. Examples of such protocols include SIP, 168 which makes use of the Session Description Protocol (SDP) [7]. SDP 169 carries and IP address on which the client will receive media packets 170 from its peer. Another example of a protocol meeting this criteria is 171 the Real Time Streaming Protocol (RTSP) [8]. 173 When a client is behind a NAT, transport addresses obtained from the 174 local operating system will not be publically routable, and 175 therefore, not useful in these protocols. TURN allows a client to 176 obtain a transport address, from a server on the public Internet, 177 which can be used in protocols meeting the above criteria. However, 178 the transport addresses obtained from TURN servers are not generally 179 useful for receiving data from anywhere. They are only useful for 180 communicating with a single peer. Once a host sends packets to that 181 transport address, it is ``locked down'', meaning that packets from 182 other hosts will not be forwarded to the client. This is done 183 purposefully, so as to prevent TURN from being used to run servers 184 (such as a web server) on a client behind a NAT. In this way, 185 enterprises which deploy NATs and firewalls to prevent users from 186 running servers, can be confident that TURN will not cause any 187 violations in their enterprise security policies. 189 5. Overview of Operation 191 The typical TURN configuration is shown in Figure 1. A TURN client is 192 connected to private network 1. This network connects to private 193 network 2 through NAT 1. Private network 2 connects to the public 194 Internet through NAT 2. On the public Internet is a TURN server. 196 /-----\ 197 // TURN \\ 198 | Server | 199 \\ // 200 \-----/ 202 +--------------+ Public Internet 203 ................| NAT 2 |....................... 204 +--------------+ 206 +--------------+ Private NET 2 207 ................| NAT 1 |....................... 208 +--------------+ 210 /-----\ 211 // TURN \\ 212 | Client | 213 \\ // Private NET 1 214 \-----/ 216 Figure 1 218 TURN is a simple client-server protocol. It is identical in syntax 219 and general operation to STUN, in order to facilitate a joint 220 implementation of both. TURN defines a request message, called 221 Allocate, which asks for a public IP address and port. TURN can run 222 over UDP and TCP, as it allows for a client to request address/port 223 pairs for receiving both UDP and TCP. 225 A TURN client first discovers the address of a TURN server. This can 226 be preconfigured, or it can be discovered using SRV records [3] This 227 will allow for different TURN servers for UDP and TCP. Once a TURN 228 server is discovered, the client sends a TURN Allocate request to the 229 TURN server. TURN provides a mechanism for mutual authentication and 230 integrity checks for both requests and responses, based on a shared 231 secret. Assuming the request is authenticated and has not been 232 tampered with, the TURN server remembers the source transport address 233 that the request came from (call this SA), and returns a public 234 transport address, PA, in the TURN response. The TURN server is 235 responsible for guaranteeing that packets sent to PA route to the 236 TURN server. The TURN server then waits for data on PA. When data is 237 received (either a UDP packet or a TCP connection request), the TURN 238 server accepts the connection (in the case of TCP), and then stores 239 the remote address and port where the data came from (RA). The data 240 just received, if any, are then forwarded to SA. The TURN server then 241 acts as a relay. Any data received from SA are forwarded to RA. Any 242 data sent from RA to PA are sent to SA. 244 For TCP, the TURN server does not need to examine the data received; 245 it merely forwards all data between the socket pairs it has 246 associated together. In the case of UDP, the TURN server looks for a 247 magic cookie in the first 128 bytes of each UDP packet. If present, 248 it indicates that the packet is a TURN control packet, used for 249 keepalives and teardown of the binding. In the case of TCP, if either 250 side closes a connection, the TURN server closes the other 251 connection. For both UDP and TCP, the TURN server can also time out a 252 connection in the event data is not received after some configured 253 time out period. This period is sent to the client in the TURN 254 response to the Allocate request. 256 TURN also allows a client to request an odd or even port when one is 257 allocated, and for it to pre-allocate the next higher port. This is 258 useful for securing consecutive ports for usage with the Real Time 259 Transport Protocol (RTP) [5]. 261 6. Message Overview 263 TURN messages are identical to STUN messages in their syntax. TURN 264 defines three new messages - the Allocate Request, the Allocate 265 Response, and the Allocate Error Response. TURN also uses the Shared 266 Secret Request, Shared Secret Response, and Shared Secret Error 267 Response defined by STUN. TURN makes use of some of the STUN 268 attributes (MAPPED-ADDRESS, USERNAME, MESSAGE-INTEGRITY, ERROR-CODE, 269 and UNKNOWN-ATTRIBUTES) and also defines several of its own. 270 Specifically, TURN adds TRANSPORT-PREFERENCES attribute, which allows 271 a client to request an odd or even port, and to pre-allocate the next 272 higher port. It defines the LIFETIME attribute, which allows the TURN 273 server to tell the client when the binding will be released. It 274 defines the MAGIC-COOKIE attribute, which allows the TURN client to 275 find TURN messages in a stream of UDP packets. It defines the 276 BANDWIDTH attribute, which allows a client to inform the server of 277 the expected bandwidth usage on the connection. Finally, it defines 278 the ALTERNATE-SERVER attribute, which allows the server to redirect 279 the TURN client to connect to an alternate server. 281 7. Server Behavior 283 The server behavior depends on whether the request is a Shared Secret 284 Request or an Allocate Request. 286 7.1 Shared Secret Request 288 Unlike a STUN server, a TURN server provides resources to clients 289 that connect to it. Therefore, only authorized clients can gain 290 access to a TURN server. This requires that TURN requests be 291 authenticated. TURN assumes the existence of a long-lived shared 292 secret between the client and the TURN server in order to achieve 293 this authentication. The client uses this long-lived shared secret to 294 authenticate itself in a Shared Secret Request, sent over TLS. The 295 Shared Secret Response provides the client with a one-time username 296 and password. This one-time credential is then used by the server to 297 authenticate an Allocate Request. The usage of a separate long lived 298 and one-time credentials prevents dictionary attacks, whereby an 299 observer of a message and its HMAC could guess the password by an 300 offline dictionary search. 302 When a TURN server receives a Shared Secret Request, it first 303 executes the processing described in the first three paragraphs of 304 Section 8.2 of STUN. This processing will ensure that the Shared 305 Secret Request is received over TLS. 307 Assuming it was, the server checks the Shared Secret Request for a 308 MESSAGE-INTEGRITY attribute. If not present, the server generates a 309 Shared Secret Error Response with an ERROR-CODE attribute with 310 response code 401. That response MUST include a NONCE attribute, 311 containing a nonce that the server wishes the client to reflect back 312 in a subsequent Shared Secret Request (and therefore include the 313 message integrity computation). The response MUST include a REALM 314 attribute, containing a realm from which the username and password 315 are scoped [4]. 317 If the MESSAGE-INTEGRITY attribute was present, the server checks for 318 the existence of the REALM attribute. If the attribute is not 319 present, the server MUST generate a Shared Secret Error Response. 320 That response MUST include an ERROR-CODE attribute with response code 321 434. That response MUST include a NONCE and a REALM attribute. 323 If the REALM attribute was present, the server checks for the 324 existence of the NONCE attribute. If the NONCE attribute is not 325 present, the server MUST generate a Shared Secret Error Response. 326 That response MUST include an ERROR-CODE attribute with response code 327 435. That response MUST include a NONCE attribute and a REALM 328 attribute. 330 If the NONCE attribute was present, the server checks for the 331 existence of the USERNAME attribute. If it was not present, the 332 server MUST generate a Shared Secret Error Response. The Shared 333 Secret Error Response MUST include an ERROR-CODE attribute with 334 response code 432. It MUST include a NONCE attribute and a REALM 335 attribute. 337 If the USERNAME is present, the server computes the HMAC over the 338 request as described in Section 11.2.8 of STUN. The key is computed 339 as MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" passwd), where 340 the password is the password associated with the username and realm 341 provided in the request. If the server does not have a record for 342 that username within that realm, the server generates a Shared Secret 343 Error Response. That response MUST include an ERROR-CODE attribute 344 with response code 436. That response MUST include a NONCE attribute 345 and a REALM attribute. 347 This format for the key was chosen so as to enable a common 348 authentication database for SIP and for TURN, as it is expected 349 that credentials are usually stored in their hashed forms. [[OPEN 350 ISSUE: Is support of MD5-sess needed?]] 352 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 353 attribute in the request, the server MUST generate a Shared Secret 354 Error Response with an ERROR-CODE attribute with response code 431. 355 This response MUST include a NONCE attribute and a REALM attribute. 357 If the computed HMAC doesn't differ from the one in the request, but 358 the nonce is stale, the server MUST generate a Shared Secret Error 359 Response. That response MUST include an ERROR-CODE attribute with 360 response code 430. That response MUST include a NONCE attribute and a 361 REALM attribute. 363 In all cases, the Shared Secret Error Response is sent over the TLS 364 connection on which the Shared Secret Request was received. 366 The server proceeds to authorize the client. The means for 367 authorization are outside the scope of this specification. It is 368 anticipated that TURN servers will be run by providers that also 369 provide an application service, such as SIP or RTSP. In that case, a 370 user would be authorized to use TURN if they are authorized to use 371 the application service. 373 The server then generates a Shared Secret Response as in Section 8.2 374 of STUN. This response will contain a USERNAME and PASSWORD, which 375 are used by the client as a short-term shared secret in subsequent 376 Allocate requests. Note that STUN specifies that the server has to 377 invalidate this username and password after 30 minutes. This is not 378 the case in TURN. In TURN, the server MUST store the allocated 379 username and password for a duration of at least 30 minutes. Once an 380 Allocate request has been authenticated using that username and 381 password, if the result was an Allocate Error Response, the username 382 and password are discarded. If the result was an Allocate Response, 383 resulting in the creation of a new binding, the username and password 384 become associated with that binding. They can only be used to 385 authenticate Allocate requests sent from the same source transport 386 address in order to refresh or de-allocate that binding. Once the 387 binding is deleted, the username and password are discarded. 389 This policy avoids replay attacks, whereby a recorded Allocate 390 request is replayed in order to obtain a binding without proper 391 authentication. It also ensures that existing bindings can be 392 refreshed without needed to continuously obtain one-time passwords 393 from the TURN server. 395 7.2 Allocate Request 397 7.2.1 Overview 399 Allocate requests are used to obtain an IP address and port that the 400 client can use to receive UDP and TCP packets from any host on the 401 network, even when the client is behind a symmetric NAT. To do this, 402 a TURN server allocates a local transport address, and passes it to 403 the client in an Allocate Response. When the server receives packets 404 on this allocated address, it acts as a relay, and forwards them 405 towards the source of the Allocate request. The server remembers the 406 source transport address where that packet came from, and "locks 407 down". This means that packets sent from the client to the TURN 408 server are forwarded to that address. 410 As a result, the server maintains a set of bindings. These bindings 411 are associations between the five-tuple of received Allocate requests 412 (source IP address and port, destination IP address and port, and 413 protocol), called the allocate five-tuple, and another five tuple, 414 called the remote five-tuple. 416 The behavior of the server when receiving an Allocate Request depends 417 on whether the request is an initial one, or a subsequent one. An 418 initial request is one received with a source transport address which 419 is not associated with any existing bindings. A subsequent request is 420 one received that is associated with an existing binding. 422 7.2.2 Initial Requests 424 A TURN server MUST be prepared to receive Binding Requests over TCP 425 and UDP. The port on which to listen is based on the DNS SRV entries 426 provided by the server. Typically, this will be XXXX, the default 427 TURN port. [[OPEN ISSUE: Can we just use the STUN port?]]. 429 The server MUST check the Allocate Request for a MESSAGE-INTEGRITY 430 attribute. If not present, the server generates a Allocate Error 431 Response with an ERROR-CODE attribute with response code 401. 433 If the MESSAGE-INTEGRITY attribute was present, the server checks for 434 the existence of the USERNAME attribute. If it was not present, the 435 server MUST generate a Allocate Error Response. The Allocate Error 436 Response MUST include an ERROR-CODE attribute with response code 432. 438 If the USERNAME is present, the server computes the HMAC over the 439 request as described in Section 11.2.8 of STUN. The key is equal to 440 the password associated with the username in the request, where that 441 username is a short term username allocated by the TURN server. The 442 username MUST be one which has been allocated by the server in a 443 Shared Secret Response, but has not yet been used to authenticate an 444 Allocate request. If that username is not known by the server, or has 445 already been used, the server generates an Allocate Error Response. 446 That response MUST include an ERROR-CODE attribute with response code 447 430. 449 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 450 attribute in the request, the server MUST generate a Allocate Error 451 Response with an ERROR-CODE attribute with response code 431. 453 Assuming the message integrity check passed, processing continues. 454 The server MUST check for any attributes in the request with values 455 less than or equal to 0x7fff which it does not understand. If it 456 encounters any, the server MUST generate an Allocate Error Response, 457 and it MUST include an ERROR-CODE attribute with a 420 response code. 459 That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing 460 the attributes with values less than or equal to 0x7fff which were 461 not understood. 463 If the Allocate request arrived over TCP, the Allocate Error Response 464 is sent on the connection from which the request arrived. If the 465 Allocate request arrived over UDP, the Allocate Error Response is 466 sent to the transport address from which the request was received 467 (i.e., the source IP address and port), and sent from the transport 468 address on which the request was received (i.e., the destination IP 469 address and port). 471 Assuming the Allocate request was authenticated and was well-formed, 472 the server attempts to allocate transport addresses. It first looks 473 for the BANDWIDTH attribute for the request. If present, the server 474 determines whether or not it has sufficient capacity to handle a 475 binding that will generate the requested bandwidth. If so, the server 476 looks for the presence of the TRANSPORT-PREFERENCES attribute in the 477 request. If the attribute indicates that an even port is requested, 478 the server attempts to allocate a transport address with an even 479 port. If the attribute indicates that an odd port is requested, the 480 server attempts to allocate a transport address with an odd port. If 481 the attribute indicates that there is no preference for port parity, 482 or if the TRANSPORT-PREFERENCES attribute was absent, the server 483 attempts to allocate a port with either parity. The server MUST NOT 484 allocate ports from the well-known port range (0-1023) and MUST NOT 485 allocate ports from the user registered port range (1024 through 486 49151). 488 This aspect of the protocol helps guarantee that users cannot run 489 servers (such as a web server, SIP server, or SMTP server) using 490 TURN. 492 The TRANSPORT-PREFERENCES attribute can also indicate a preference 493 for a specific address and port, pre-allocated previously by a prior 494 Allocate request, or by the server itself through the MORE-AVAILABLE 495 attribute. This case is described in Section 7.2.3. 497 If a port meeting the constraints (including bandwidth) cannot be 498 allocated, the server MUST generate a Allocate Error Response that 499 includes an ERROR-CODE attribute with a response code of 300. That 500 response MAY include an ALTERNATE-SERVER attribute pointing to an 501 alternate server which can be used by the client. 503 Assuming a port was allocated according to the preferences (call this 504 the base port), the server checks to see if the TRANSPORT-PREFERENCES 505 attribute is present, and indicates a desire to pre-allocate the next 506 higher port (called the pre-allocated port). If so, the server 507 attempts to allocate that port from its local operating system. If it 508 cannot be allocated, the server can do one of two things. First, it 509 MAY try to allocate a different base port, in the hopes that the next 510 higher port is available. If the server believes that there are no 511 adjacent ports meeting the parity constraints present in the request, 512 the server MAY generate an Allocate Error Response that includes an 513 ERROR-CODE attribute with a response code of 300. That response MAY 514 include an ALTERNATE-SERVER attribute pointing to an alternate server 515 which can be used by the client. 517 Once a base port is allocated, the server creates a binding for it. 518 This binding is a mapping between two five-tuples - the allocate 519 five-tuple and the remote five-tuple. The allocate five-tuple is set 520 to the five-tuple of the Allocate Request (that is, the protocol of 521 the allocate five-tuple is set to the protocol of the Allocate 522 Request (TCP or UDP), the source IP address and port of the allocate 523 five-tuple are set to the source IP address and port in the Allocate 524 Request, and the destination IP address and port of the allocate 525 five-tuple are set to the destination IP address and port in the 526 Allocate Request). The protocol in the remote five-tuple is set to 527 the protocol from the Allocate Request. The source IP address of the 528 remote five-tuple is set to the interface from which the base port 529 was allocated. The source port of the remote five-tuple is set to the 530 base port. If the binding was allocated for TCP, the connection on 531 which the Allocate request was received is associated with the 532 allocate five-tuple in the binding. 534 The server MUST remember the one-time username and password used to 535 obtain the binding. 537 The server MAY choose to pre-allocate any number of additional 538 address/port combinations for the user, even though the user did not 539 explicitly request this. Typically, a server would do this when it 540 has interfaces on separate networks, and wants to give a client 541 bindings on each of those interfaces. 543 If an address and port was pre-allocated (either at the request or 544 the user, or the at the discretion of the server), a binding is also 545 created for it. The allocate five-tuple is left empty. The protocol 546 in the remote five-tuple is set to the protocol from the Allocate 547 Request. The source IP address of the remote five-tuple is set to the 548 interface from which the pre-allocated port was allocated. The source 549 port of the remote five-tuple is set to the pre-allocated port. The 550 identity of the user (defined as the username provided in the Shared 551 Secret Request used to obtain the one-time password used in the 552 Allocate Request) is associated with this pre-allocated tuple. Only 553 that user can perform an allocation for this tuple. Furthermore, a 554 timer is set. If no allocation is made against this pre-allocation 555 within 5 minutes, the port is released and the binding is deleted. 557 If the LIFETIME attribute was present in the request, and the value 558 is larger than the maximum duration the server is willing to use for 559 the lifetime of the binding, the server MAY lower it to that maximum. 560 However, the server MUST NOT increase the duration requested in the 561 LIFETIME attribute. If there was no LIFETIME attribute, the server 562 may choose a default duration at its discretion. In either cae, the 563 resulting duration is added to the current time, and a timer is set 564 to fire at or after that time. Section 7.4 discusses behavior when 565 the timer fires. 567 Once the base port has been obtained from the operating system, the 568 pre-allocated port obtained, and the activity timer started for the 569 base port binding, the server generates an Allocate Response. The 570 Allocate Response MUST contain the same transaction ID contained in 571 the Allocate Request. The length in the message header MUST contain 572 the total length of the message in bytes, excluding the header. The 573 Allocate Response MUST have a message type of "Allocate Response". 575 The server MUST add a MAPPED-ADDRESS attribute to the Allocate 576 Response. The IP address component of this attribute MUST be set to 577 the interface from which the base port was allocated. The port 578 component of this attribute MUST be set to the base port. 580 The server MUST add a LIFETIME attribute to the Allocate Response. 581 This attribute contains the duration, in seconds, of the activity 582 timer associated with this binding. 584 The server MUST add a BANDWIDTH attribute to the Allocate Response. 585 This MUST be equal to the attribute from the request, if one was 586 present. Otherwise, it indicates a per-binding cap that the server is 587 placing on the bandwidth usage on each binding. Such caps are needed 588 to prevent against denial-of-service attacks (See Section 10. 590 If the server pre-allocated an address and port at its own 591 discretion, the server MUST include a MORE-AVAILABLE attribute in the 592 response, one for each pre-allocated address and port. 594 The server MUST add, as the final attribute of the request, a 595 MESSAGE-INTEGRITY attribute. The key used in the HMAC MUST be the 596 same as that used to validate the request. 598 The TURN server then sends the response. If the Allocate request was 599 received over TCP, the response is sent over that TCP connection. 600 Once the response is sent, the TURN server begins acting as a relay 601 for that connection (see Section 7.3). If the Allocate request was 602 received over UDP, the response is sent to the transport address from 603 which the request was received (i.e., the source IP address and 604 port), and sent from the transport address on which the request was 605 received (i.e., the destination IP address and port). 607 Additionally, if the base port was for UDP, the server MUST be 608 prepared to receive UDP packets once the TURN response is sent. If 609 the base port was for TCP, the server MUST be prepared to receive a 610 TCP connection request on that port. Behavior when either occurs is 611 described in Section 7.3. 613 7.2.3 Requests for Pre-Allocated Ports 615 The TRANSPORT-PREFERENCES attribute of the Allocate Request can 616 indicate a desire to allocate a port that was previously 617 pre-allocated by a prior Allocate request. If such an indication is 618 present, the server checks that this address and port has been 619 pre-allocated by a previous Allocate Request. The only user 620 authorized to allocate a pre-allocated address is the same one that 621 generated the pre-allocation. Note that the one-time usernames for 622 both requests (the pre-allocation and the final allocation) will be 623 different. However, both MUST have been obtained through Shared 624 Secret Requests authenticated as being sent from the same user. 626 If the Allocate request arrives on a different protocol than was used 627 to make the pre-allocation, the server MUST send an Allocate Error 628 Response. That response MUST contain an ERROR-CODE attribute with a 629 response code of 400. 631 Assuming the requested port has been pre-allocated by the same user, 632 the server completes the allocation by setting the allocate 633 five-tuple for the binding to be equal to that of the Allocate 634 request. The server sets the activity timer for this binding, and 635 generates an Allocate Response. This response MUST contain a 636 MAPPED-ADDRESS attribute which contains the interface from which the 637 pre-allocated port was obtained, along with the pre-allocated port. 638 The response MUST contain a LIFETIME attribute and a 639 MESSAGE-INTEGRITY attribute as well. 641 7.2.4 Subsequent Requests 643 Once a binding has been created, packets received from the client are 644 generally forwarded to the remote client. However, if the binding is 645 UDP, the client can send subsequent Allocate requests to the TURN 646 server. To determine which packets are for the TURN server, and which 647 need to be relayed, the server looks at the packet. If the packet is 648 shorter than 28 bytes, it is not a TURN request. If it is longer than 649 28 bytes, the server checks bytes 25-28. If these bytes are equal to 650 the MAGIC-COOKIE, the request is a TURN request. Otherwise, it is a 651 data packet, and is to be relayed. 653 The server first authenticates the request. This is done as in 654 Section 7.2.2. The request MUST be authenticated using the same 655 one-time username and password used to allocate that binding 656 previously. That is, the five-tuple from the Allocate request is 657 compared to the allocate five-tuples in existing bindings. The 658 matching binding is selected. The one-time username and password 659 associated with that binding MUST match the ones used in the request. 661 Any TRANSPORT-PREFERENCE attribute in the request is ignored. An 662 Allocate Request sent to an existing binding is always a refresh or 663 deallocation. The server looks for the LIFETIME attribute in the 664 Allocate Request. If not found, it determines the default refresh 665 duration, in seconds, for this binding. If the LIFETIME attribute was 666 present in the request, and the value is larger than the maximum 667 duration the server is willing to extend the lifetime of the binding, 668 the server MAY lower it to that maximum. However, the server MUST NOT 669 increase the duration requested in the LIFETIME attribute. The 670 resulting duration is added to the current time, and the activity 671 timer for this binding is reset to fire at or after that time. 672 Section 7.4 discusses behavior when the timer fires. 674 Once the timer is set, the server MUST generate an Allocate Response. 675 The Allocate Response MUST contain the same transaction ID contained 676 in the Allocate Request. The length in the message header MUST 677 contain the total length of the message in bytes, excluding the 678 header. The Allocate Response MUST have a message type of "Allocate 679 Response". The response MUST contain a MAGIC-COOKIE as the first 680 attribute. It MUST contain a MAPPED-ADDRESS which contains the source 681 IP address and port from the remote five-tuple of the binding. It 682 MUST contain a LIFETIME attribute which contains the time from now 683 until the point at which the binding will be deleted. The final 684 attribute MUST be a MESSAGE-INTEGRITY attribute, which MUST use the 685 same one-time username and password used to authenticate the request. 687 The TURN server then sends the response. If the Allocate request was 688 received over TCP, the response is sent over that TCP connection. If 689 the Allocate request was received over UDP, the response is sent to 690 the transport address from which the request was received (i.e., the 691 source IP address and port), and sent from the transport address on 692 which the request was received (i.e., the destination IP address and 693 port). 695 7.3 Receiving Packets and Connections 697 If a TURN server receives a TCP connection request on a port it has 698 allocated, the server retrieves the binding whose remote five-tuple 699 has a source address and source port that match the IP address and 700 port to which the connection was made, and whose transport is TCP. If 701 the destination IP address and port of the remote five-tuple in the 702 binding are already filled in (which means that a connection was 703 already made to this tuple), the connection request is rejected. 704 Otherwise, it is accepted. If the connection is accepted, the server 705 MUST set the destination IP address and port of the remote five-tuple 706 to the source IP address and port in the SYN packet. It also 707 associates this connection with the remote five-tuple. 709 If a TURN server receives a UDP packet on a port it has allocated, 710 the server retrieves the binding whose remote five-tuple has a source 711 address and source port that match the IP address and port to which 712 the packet was sent, and whose transport is UDP. If the destination 713 IP address and port of the remote five-tuple in the binding are 714 already filled in, and do not match the source IP address and port of 715 the UDP packet, the server drops the packet and MAY generate a port 716 unreachable ICMP error. If the packet was not discarded, it is 717 forwarded. To forward, the packet is sent with a source IP address 718 and port equal to the destination IP address and port in the allocate 719 five-tuple, and with a destination address and port equal to the 720 source IP address and port in the allocate five-tuple. If the 721 destination address and port of the remote five-tuple were not filled 722 in, they are populated at this time. The server MUST set the 723 destination IP address and port of the remote five-tuple to the 724 source IP address and port in the UDP packet. 726 The process of filling in the destination IP address and port of the 727 remote five-tuple is called "locking down". Once done, the client can 728 only send and receive packets with the specific peer from which the 729 first packet or connection was received. 731 If a TURN server receives data on a TCP connection that was opened to 732 a port it had allocated, the server MUST forward this data onto the 733 connection associated with allocate-tuple in the binding. 735 If a TURN server receives data on a TCP connection that is associated 736 with an allocate five-tuple, the binding for that tuple is retrieved. 737 If the destination IP address and port of that tuple have not been 738 filled in yet, the data is discarded. If the destination address and 739 port have been filled in, the connection associated with the remote 740 five-tuple is obtained, and the data is forwarded on that connection. 742 Note that, because data is forwarded blindly across TCP bindings, TLS 743 will successfully operate over a TURN allocated TCP port. 745 Similarly, if a TURN server receives a UDP packet on one of its 746 public TURN ports, it checks to see if the source IP address and port 747 match those of the allocate five-tuples in an existing binding. If 748 there is a match, the the UDP packet is not a TURN request (see 749 Section 7.2.4 for details on how this determination is made), the 750 destination IP address and port in the remote five-tuple of the 751 binding are checked. If they are not filled in yet, the UDP packet is 752 discarded. If they are, the packet is forwarded. It is forwarded 753 using the source IP address and port from the remote five-tuple, and 754 a destination IP address and port from the remote five-tuple. 756 If a TCP connection associated with an allocate five-tuple is closed, 757 the connection associated with the corresponding remote five-tuple is 758 also closed. At that point, the binding is destroyed. Similarly, if 759 the TCP connection associated with a remote five-tuple is closed, the 760 connection associated with the corresponding allocate five-tuple is 761 closed, and the binding is destroyed. 763 7.4 Lifetime Expiration 765 When the activity timer for a binding fires, the server checks to see 766 if there has been any activity on the binding since its creation, or 767 since the last firing of the timer, whichever is more recent. 768 Activity is defined as connection establishment, or packet 769 transmission in either direction. If there has been activity, the 770 timer is set to fire once again in M seconds, where M is the value of 771 the LIFETIME attribute returned in the most recent Allocate Response 772 for this binding. 774 If there has been no activity, the server MUST destroy the binding, 775 along with its associated one-time password. If the binding was over 776 TCP, the server MUST close any connections it is holding to the 777 client and to the remote client. 779 8. Client Behavior 781 Client behavior is broken into several separate steps. First, the 782 client obtains a one-time username and password. Secondly, it 783 generates initial Allocate Requests, and processes the responses. It 784 manages those addresses (refreshing and tearing them down), and 785 processes data received on those addresses. 787 8.1 Discovery 789 Generally, the client will be configured with a domain name of the 790 provider of the TURN servers. This domain name is resolved to an IP 791 address and port of using the SRV procedures [3]. When sending a 792 Shared Secret request, the service name is "turn" and the protocol is 793 "tcp". RFC 2782 spells out the details of how a set of SRV records 794 are sorted and then tried. However, it only states that the client 795 should "try to connect to the (protocol, address, service)" without 796 giving any details on what happens in the event of failure. Those 797 details are described here for TURN. 799 For TURN requests, failure occurs if there is a transport failure of 800 some sort (generally, due to fatal ICMP errors in UDP or connection 801 failures in TCP). Failure also occurs if the the request does not 802 solicit a response after 9.5 seconds. If a failure occurs, the client 803 SHOULD create a new request, which is identical to the previous, but 804 has a different transaction ID and MESSAGE-INTEGRITY attribute. That 805 request is sent to the next element in the list as specified by 806 RFC~2782. 808 8.2 Obtaining a One Time Password 810 In order to allocate addresses, a client must obtain a one-time 811 username and password from the TURN server. A unique username and 812 password are required for each distinct address allocated from the 813 server. 815 To obtain a one-time username and password, the client generates and 816 sends a Shared Secret Request. This is done as described in Section 817 9.2 of STUN. This request will have no attributes, and therefore, 818 based on the processing in Section 7.1, the server will reject it 819 with a Shared Secret Error Response with a 401 response code. That 820 response will contain a NONCE and a REALM. The client SHOULD generate 821 a new Shared Secret Request (with a new transaction ID), which 822 contains the NONCE and REALM attributes copied from the 401 response. 823 The request MUST include the USERNAME attribute, which contains a 824 username supplied by the user for the specified realm. The request 825 MUST include a MESSAGE-INTEGRITY attribute as the last attribute. The 826 key for the HMAC is computed as described in Section 7.1. 828 If the response (either to the initial request or to the second 829 attempt with the credentials) is a Shared Secret Error Response, the 830 processing depends on the the value of the response code in the 831 ERROR-CODE attribute. If the response code was a 430, the client 832 SHOULD generate a new Shared Secret Request, using the username and 833 password provided by the user, and the REALM and NONCE provided in 834 the 430 response. For a 431 or 436 response code, the client SHOULD 835 alert the user. For a 432, 434 and 435 response codes, if the client 836 had omitted the USERNAME, REALM or NONCE attributes, respectively, 837 from the previous request, it SHOULD retry, this time including the 838 USERNAME, NONCE, REALM, and MESSAGE-INTEGRITY attributes. For a 500 839 response code, the client MAY wait several seconds and then retry the 840 request. For a 600 response code, the client MUST NOT retry the 841 request, and SHOULD display the reason phrase to the user. Unknown 842 attributes between 400 and 499 are treated like a 400, unknown 843 attributes between 500 and 599 are treated like a 500, and unknown 844 attributes between 600 and 699 are treated like a 600. Any response 845 between 100 and 399 MUST result in the cessation of request 846 retransmissions, but otherwise is discarded. 848 If a client receives a Shared Secret Response with an attribute whose 849 type is greater than 0x7fff, the attribute MUST be ignored. If the 850 client receives a Shared Secret Response with an attribute whose type 851 is less than or equal to 0x7fff, the response is ignored. 853 If the response is a Shared Secret Response, it will contain the 854 USERNAME and PASSWORD attributes. The client can use these to 855 authenticate an Allocate Request, as described below. 857 A client MAY send multiple Shared Secret Requests over the same TLS 858 connection, and MAY do so without waiting for responses to previous 859 requests. The client SHOULD close its connection when it has 860 completed allocating usernames and passwords. 862 8.3 Allocating a Binding 864 When a client wishes to obtain a transport address, it sends an 865 Allocate Request to the TURN server. Requests for TCP transport 866 addresses MUST be sent over a TCP connection, and requests for UDP 867 transport addresses MUST be sent over UDP. 869 First, the client obtains a one-time username and password, using the 870 mechanisms described in Section 8.2. The client then formulates an 871 Allocate Request. The request MUST contain a transaction ID, unique 872 for each request, and uniformly and randomly distributed between 0 873 and 2**128 - 1. The message type of the request MUST be ``Allocate 874 Request''. The length is set as described in Section 11.1 of STUN. 876 The Allocate request MUST contain the MAGIC-COOKIE attribute as the 877 first attribute. If the client wishes to allocate an odd or even 878 port, it can do so by including the TRANSPORT-PREFERENCES attribute 879 in the request. That attribute can also be used by the client if it 880 wishes to pre-allocate the port one higher. 882 The client SHOULD include a BANDWIDTH attribute, which indicates the 883 maximum bandwidth that will be used with this binding. If the maximum 884 is unknown, the attribute is not included in the request. 886 The client MAY request a particular lifetime for the binding by 887 including it in the LIFETIME attribute in the request. If the no data 888 is sent or received on the binding before expiration of the lifetime, 889 the binding will be deleted by the client. 891 The client MUST include a USERNAME attribute, containing a username 892 obtained from a previous Shared Secret Response. The request MUST 893 include a MESSAGE-INTEGRITY attribute as the last attribute. The key 894 is equal to the password obtained from the PASSWORD attribute of the 895 Shared Secret Response. The Allocate Request MUST be sent to the same 896 IP address and port as the Shared Secret Request. This is because one 897 time passwords are expected to be host-specific. Rules for 898 retransmissions for Allocate Requests sent over UDP are identical to 899 those for STUN Binding Requests. Allocate Requests sent over TCP are 900 not retransmitted. Transaction timeouts are identical to those for 901 STUN Binding Requests, independent of the transport protocol. 903 8.4 Processing Allocate Responses 905 If the response is an Allocate Error Response, the client checks the 906 response code from the ERROR-CODE attribute of the response. For a 907 400 response code, the client SHOULD display the reason phrase to the 908 user. For a 420 response code, the client SHOULD retry the request, 909 this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES 910 attribute of the response. For a 430 response code, the client SHOULD 911 obtain a new one-time username and password, and retry the Allocate 912 Request with a new transaction. For 401 and 432 response codes, if 913 the client had omitted the USERNAME or MESSAGE-INTEGRITY attribute as 914 indicated by the error, it SHOULD try again with those attributes. A 915 new one-time username and password is needed in that case. For a 431 916 response code, the client SHOULD alert the user, and MAY try the 917 request again after obtaining a new username and password. For a 300 918 response code, the client SHOULD attempt a new TURN transaction to 919 the server indicated in the ALTERNATE-SERVER attribute. For a 500 920 response code, the client MAY wait several seconds and then retry the 921 request with a new username and password. For a 600 response code, 922 the client MUST NOT retry the request, and SHOULD display the reason 923 phrase to the user. Unknown attributes between 400 and 499 are 924 treated like a 400, unknown attributes between 500 and 599 are 925 treated like a 500, and unknown attributes between 600 and 699 are 926 treated like a 600. Unknown attributes between 300 and 399 are 927 treated like 300. Any response between 100 and 299 MUST result in the 928 cessation of any request retransmissions, but otherwise is discarded. 930 If a client receives a response with an attribute whose type is 931 greater than 0x7fff, the attribute MUST be ignored. If the client 932 receives a response with an attribute whose type is less than or 933 equal to 0x7fff, any request retransmissions MUST cease, but the 934 entire response is otherwise ignored. 936 If the response is an Allocate Response, the client MUST check the 937 response for a MESSAGE-INTEGRITY attribute. If not present, the 938 client MUST discard the response. If present, the client computes the 939 HMAC over the response. The key MUST be same as used to compute the 940 MESSAGE-INTEGRITY attribute in the request. If the computed HMAC 941 differs from the one in the response, the client MUST discard the 942 response, and SHOULD alert the user about a possible attack. If the 943 computed HMAC matches the one from the response, processing 944 continues. 946 The MAPPED-ADDRESS in the Binding Response can be used by the client 947 for receiving packets. The server will expire the binding after 948 LIFETIME seconds have passed with no activity. The server will allow 949 the user to send and receive no more than the amount of data 950 indicated in the BANDWIDTH attribute. 952 8.5 Allocating a Pre-Allocated Binding 954 If the initial Allocate Request included TRANSPORT-PREFERENCES that 955 indicated a desire to pre-allocate the port one-higher, the client 956 MAY allocate that port at a later time. It MUST do so within 4 957 minutes of receiving the Allocate Response, or the pre-allocated port 958 will expire. 960 To allocate the port, the client generates an Allocate Request as 961 described in Section 8.3. A new username and password MUST be used 962 for this allocation. The request MUST contain a TRANSPORT-PREFERENCES 963 attribute. It MUST indicate an explicit interface and port, whose 964 value is one higher than the port number returned in the prior 965 Allocate Response. 967 Processing of the responses is identical to Section 8.4. However, the 968 client SHOULD explicitly check that received packets are TURN 969 responses, as opposed to data packets, using the techniques described 970 in Section 7.2.4. 972 8.6 Refreshing a Binding 974 If there has been no activity on a UDP binding for a period of time 975 equalling 3/4 of the lifetime of the binding (as conveyed in the 976 LIFETIME attribute of the Allocate Response), the client SHOULD 977 refresh the binding with another Allocate Request if it wishes to 978 keep it. Note that only UDP bindings can be refreshed. For TCP, 979 application-specific keepalives are needed. 981 To perform a refresh, the client generates an Allocate Request as 982 described in Section 8.3. However, the one-time username and password 983 used MUST be the same as those used in the successful Allocate 984 Request for that binding. The client will need to look for the TURN 985 response amongst the data packets using the MAGIC-COOKIE, as 986 described in Section 7.2.4. Processing of that response is as defined 987 in Section 8.4. If the response was an Allocate Response, and the 988 MAPPED-ADDRESS contains the same transport address as previously 989 obtained, the binding has been refreshed. The LIFETIME attribute 990 indicates the amount of additional time the binding will live without 991 activity. If, however, the response was an Allocate Error Response 992 with an ERROR-CODE indicating a 430 response, it means that the 993 binding has expired at the server. The client MAY use the procedures 994 in Section 8.3 to obtain a new binding (this will require a new 995 one-time username and password. Other response codes do not imply 996 that the binding has been expired, just that the refresh has failed. 998 8.7 Tearing Down a Binding 1000 If a client no longer needs a binding, it SHOULD tear it down. For 1001 TCP, this is done by closing the connection. For UDP, this is done by 1002 performing a refresh, as described in Section 8.6, but with a 1003 LIFETIME attribute indicating a time of 0. 1005 8.8 Receiving and Sending Data 1007 Once a binding has been allocated by an Allocate Response, the client 1008 MUST be prepared to receive data from the socket on which the 1009 Allocate Request was sent. For UDP, the client MUST be prepared to 1010 disambiguate TURN messages from data for a period of 32 seconds 1011 following the first TURN response. This disambiguation is done using 1012 the MAGIC-COOKIE, as described in Section 7.2.4. 1014 Once data has been received, the client MAY send data to its peer by 1015 sending data on that same socket. Sending data on the socket before 1016 data is received will cause the data to be discarded by the server. 1018 9. Protocol Details 1020 This section presents the detailed encoding of the message types, 1021 attributes, and response codes which are new to TURN. The general 1022 message structure of TURN is identical to STUN [1]. 1024 9.1 Message Types 1026 TURN defines three new Message Types: 1028 0x0003 : Allocate Request 1029 0x0103 : Allocate Response 1030 0x0113 : Allocate Error Response 1032 9.2 Message Attributes 1034 TURN defines the following message attributes: 1036 0x000c: TRANSPORT-PREFERENCES 1037 0x000d: LIFETIME 1038 0x000e: ALTERNATE-SERVER 1039 0x000f: MAGIC-COOKIE 1040 0x0010: BANDWIDTH 1041 0x0011: MORE-AVAILABLE 1043 9.2.1 TRANSPORT-PREFERENCES 1045 The TRANSPORT-PREFERENCES attribute indicates preferences for the 1046 ports allocated by the TURN server. It is either 32 or 96 bits long, 1047 depending on the value of the Typ bits. These bits indicate the 1048 preferences for the allocated port: 1050 0b00: no preferences 1051 0b01: odd port parity 1052 0b10: even port parity 1053 0b11: allocate a pre-allocated port 1055 When the Typ bits are 0b11, the following 64 bits encode the 1056 pre-allocated transport address. They are in the same format used for 1057 MAPPED-ADDRESS. 1059 The P bit indicates a desire for pre-allocating the port one-higher. 1060 If 1, it means pre-allocation is desired. This bit MUST NOT be set to 1061 1 if the Typ bits are 0b11. That is, pre-allocation cannot be done 1062 again when allocating a previously pre-allocated port. 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | 0 |P|Typ| 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 |x x x x x x x x| Family | Port | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Address | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 9.2.2 LIFETIME 1074 The lifetime attribute represents the duration for which the server 1075 will maintain a binding in the absence of data traffic either from or 1076 to the client. It is a 32 bit value representing the number of 1077 seconds remaining until expiration. 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Lifetime | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 9.2.3 ALTERNATE-SERVER 1085 The alternate server represents an alternate IP address and port for 1086 a different TURN server to try. It is encoded in the same way as 1087 MAPPED-ADDRESS. 1089 9.2.4 MAGIC-COOKIE 1091 The MAGIC-COOKIE is used by TURN clients and servers to disambiguate 1092 TURN traffic from data traffic. Its value ix 0x72c64bc6. 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 |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| 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 9.2.5 BANDWIDTH 1100 The bandwidth attribute represents the peak bandwidth, measured in 1101 kbits per second, that the client expects to use on the binding. The 1102 value represents the sum in the receive and send directions. 1104 [[Editors note: Need to define leaky bucket parameters for this.]] 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Bandwidth | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 9.2.6 MORE-AVAILABLE 1112 In some cases, the server may wish to allocate a user multiple 1113 addresses when a request is made. An example of this is when the TURN 1114 server has interfaces on multiple networks, and the client needs to 1115 obtain an address on each one. In that case, the server itself 1116 performs one or more pre-allocations when a TURN request is made. To 1117 inform the client that such a pre-allocation has been made, the 1118 MORE-AVAILABLE attribute is used. There MAY be more than one of these 1119 attributes per message. Each one has the same syntax as 1120 MAPPED-ADDRESS, and indicates the address and port that has been 1121 pre-allocated. 1123 A client would allocate one of these pre-allocated addresses by 1124 including it in a TRANSPORT-PREFERENCES attribute in a subsequence 1125 Allocate Request. 1127 The MORE-AVAILABLE attribute MUST only be used in Allocate Response 1128 messages. 1130 9.3 Response Codes 1132 TURN defines the following new response codes: 1134 300 (Try Alternate): The client should contact an alternate server 1135 for this request. 1137 434 (Missing Realm): The REALM attribute was not present in the 1138 request. 1140 435 (Missing Nonce): The NONCE attribute was not present in the 1141 request. 1143 436 (Unknown Username): The USERNAME supplied in the Shared Secret 1144 Request is not known in the given REALM. 1146 10. Security Considerations 1148 TURN servers allocate bandwidth and port resources to clients. 1149 Therefore, a TURN server requires authentication and authorization of 1150 TURN requests. This authentication is provided by a client digest 1151 over TLS, which results in the generation of a one-time password that 1152 is used in a single subsequent Allocate Request. This mechanism 1153 protects against eavesdropping attacks and man-in-the-middle attacks. 1154 The usage of one-time passwords ensures that the Allocate Requests, 1155 which do not run over TLS, are not susceptible to offline dictionary 1156 attacks that can be used to guess the long lived shared secret 1157 between the client and the server. 1159 Because TURN servers allocate resources, they can be susceptible to 1160 denial-of-service attacks. All Allocate Requests are authenticated, 1161 so that an unknown attacker cannot launch an attack. An authenticated 1162 attacker can generate multiple Allocate Requests, but each requires a 1163 new one-time username and password. It is RECOMMENDED that servers 1164 implement a cap on the number of one-time passwords that are 1165 allocated to any specific user at a time (around 5 or 10 should be 1166 sufficient). This will prevent floods of Allocate requests from a 1167 single user, in an attempt to use up the resources of the system. A 1168 single malicious user could generate a single Allocate Request, 1169 obtain a binding, and then flood the server with data over this 1170 binding, in an attempt to deny others service. However, this attack 1171 requires the attacker themselves to receive the data being sent at 1172 the server. To ameliorate these kinds of attacks, servers SHOULD 1173 implement a bandwidth cap on each binding (conveyed to the client in 1174 the BANDWIDTH attribute of the Allocate Response), and discard 1175 packets beyond the threshold. 1177 A client will use the transport address learned from the 1178 MAPPED-ADDRESS attribute of the Binding Response to tell other users 1179 how to reach them. Therefore, a client needs to be certain that this 1180 address is valid, and will actually route to them. Such validation 1181 occurs through the TLS and HMAC-based authentication and integrity 1182 checks provided in TURN. They can guarantee the authenticity and 1183 integrity of the mapped addressses. Note that TURN is not susceptible 1184 to the attacks described in Section 12.2.3, 12.2.4, 12.2.5 or 12.2.6 1185 of STUN. These attacks are based on the fact that a STUN server 1186 mirrors the source IP address, which cannot be authenticated. TURN 1187 does not use the source address of the Binding Request, and 1188 therefore, those attacks do not apply. 1190 Confidentiality of the transport addresses learned through TURN does 1191 not appear to be that important, and therefore, this capability is 1192 not provided. 1194 TURN servers are useful even for users not behind a NAT. They can 1195 provide a way for truly anonymous communications. A user can cause a 1196 call to have its media routed through a TURN server, so that the 1197 user's IP addresses are never revealed. 1199 TCP transport addresses allocated by TURN will properly work with TLS 1200 and SSL. However, any addresses allocated by TURN will not operate 1201 properly with IPSec Authentication Header (AH) [10] in transport 1202 mode. IPSec ESP [11] and any tunnel-mode ESP or AH should still 1203 operate. 1205 11. IAB Considerations 1207 The IAB has studied the problem of ``Unilateral Self Address 1208 Fixing'', which is the general process by which a client attempts to 1209 determine its address in another realm on the other side of a NAT 1210 through a collaborative protocol reflection mechanism RFC 3424 [12]. 1211 TURN is an example of a protocol that performs this type of function. 1212 The IAB has mandated that any protocols developed for this purpose 1213 document a specific set of considerations. This section meets those 1214 requirements. 1216 11.1 Problem Definition 1218 From RFC 3424 [12], any UNSAF proposal must provide: 1220 Precise definition of a specific, limited-scope problem that is to 1221 be solved with the UNSAF proposal. A short term fix should not 1222 be generalized to solve other problems; this is why "short term 1223 fixes usually aren't". 1225 The specific problem being solved by TURN is for a client, which may 1226 be located behind a NAT of any type, to obtain an IP address and port 1227 on the public Internet, useful for applications that require a client 1228 to place a transport address into a protocol message, with the 1229 expectation that the client will be able to receive packets from a 1230 single host that will send to this address. Both UDP and TCP are 1231 addressed. It is also possible to send packets so that the recipient 1232 sees a source address equal to the allocated address. TURN, by 1233 design, does not allow a client to run a server (such as a web or 1234 SMTP server) using a TURN address. TURN is useful even when NAT is 1235 not present, to provide anonymity services. 1237 11.2 Exit Strategy 1239 From [12], any UNSAF proposal must provide: 1241 Description of an exit strategy/transition plan. The better short 1242 term fixes are the ones that will naturally see less and less use 1243 as the appropriate technology is deployed. 1245 It is expected that TURN will be useful indefinitely, to provide 1246 anonymity services. When used to facilitate NAT traversal, TURN does 1247 not iself provide an exit strategy. That is provided by the 1248 Interactive Connectivity Establishment (ICE) [13] mechanism. ICE 1249 allows two cooperating clients to interactively determine the best 1250 addresses to use when communicating. ICE uses TURN-allocated 1251 addresses as a last resort, only when no other means of connectivity 1252 exists. As a result, as NATs phase out, and as IPv6 is deployed, ICE 1253 will increasingly use other addresses (host local addresses). 1254 Therefore, clients will allocate TURN addresses, but not use them, 1255 and therefore, de-allocate them. Servers will see a decrease in 1256 usage. Once a provider sees that its TURN servers are not being used 1257 at all (that is, no media flows through them), they can simply remove 1258 them. ICE will operate without TURN-allocated addresses. 1260 11.3 Brittleness Introduced by TURN 1262 From [12], any UNSAF proposal must provide: 1264 Discussion of specific issues that may render systems more 1265 "brittle". For example, approaches that involve using data at 1266 multiple network layers create more dependencies, increase 1267 debugging challenges, and make it harder to transition. 1269 TURN introduces brittleness in a few ways. First, it adds another 1270 server element to any system, which adds another point of failure. 1271 TURN requires clients to demultiplex TURN packets and data based on 1272 hunting for a MAGIC-COOKIE in the TURN messages. It is possible (with 1273 extremely small probabilities) that this cookie could appear within a 1274 data stream, resulting in mis-classification. That might introduce 1275 errors into the data stream (they would appear as lost packets), and 1276 also result in loss of a binding. TURN relies on any NAT bindings 1277 existing for the duration of the bindings held by the TURN server. 1278 Neither the client nor the TURN server have a way of reliably 1279 determining this lifetime (STUN can provide a means, but it is 1280 heuristic in nature and not reliable). Therefore, if there is no 1281 activity on an address learned from TURN for some period, the address 1282 might become useless spontaneously. 1284 TURN will result in potentially significant increases in packet 1285 latencies, and also increases in packet loss probabilities. That is 1286 because it introduces an intermediary on the path of a packet from 1287 point A to B, whose location is determined by application-layer 1288 processing, not underlying routing topologies. Therefore, a packet 1289 sent from one user on a LAN to another on the same LAN may do a trip 1290 around the world before arriving. When combined with ICE, some of the 1291 most problematic cases are avoided (such as this example) by avoiding 1292 the usage of TURN addresses. However, when used, this problem will 1293 exist. 1295 Note that TURN does not suffer from many of the points of brittleness 1296 introduced by STUN. TURN will work with all existing NAT types known 1297 at the time of writing, and for the forseeable future. TURN does not 1298 introduce any topological constraints. TURN does not rely on any 1299 heuristics for NAT type classification. 1301 11.4 Requirements for a Long Term Solution 1303 From [12]}, any UNSAF proposal must provide: 1305 Identify requirements for longer term, sound technical solutions 1306 -- contribute to the process of finding the right longer term 1307 solution. 1309 Our experience with TURN continues to validate our belief in the 1310 requirements outlined in Section 14.4 of STUN. 1312 11.5 Issues with Existing NAPT Boxes 1314 From [12], any UNSAF proposal must provide: 1316 Discussion of the impact of the noted practical issues with 1317 existing, deployed NA[P]Ts and experience reports. 1319 A number of NAT boxes are now being deployed into the market which 1320 try and provide "generic" ALG functionality. These generic ALGs hunt 1321 for IP addresses, either in text or binary form within a packet, and 1322 rewrite them if they match a binding. This will interfere with proper 1323 operation of any UNSAF mechanism, including TURN. However, if a NAT 1324 tries to modify a MAPPED-ADDRESS in a TURN Allocate Response, this 1325 will be detected by the client as an attack. 1327 12. Requirements Analysis 1329 TODO. 1331 13. Examples 1333 TODO. 1335 Normative References 1337 [1] Rosenberg, J., Huitema, C., Mahy, R. and J. Weinberger, "STUN - 1338 Simple Traversal of UDP Through Network Address Translators", 1339 draft-ietf-midcom-stun-05 (work in progress), December 2002. 1341 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1342 Levels", BCP 14, RFC 2119, March 1997. 1344 [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1345 specifying the location of services (DNS SRV)", RFC 2782, 1346 February 2000. 1348 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1349 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 1350 Basic and Digest Access Authentication", RFC 2617, June 1999. 1352 Informative References 1354 [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1355 "RTP: A Transport Protocol for Real-Time Applications", RFC 1356 1889, January 1996. 1358 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1359 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1360 Session Initiation Protocol", RFC 3261, June 2002. 1362 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1363 Protocol", RFC 2327, April 1998. 1365 [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1366 Protocol (RTSP)", RFC 2326, April 1998. 1368 [9] Senie, D., "Network Address Translator (NAT)-Friendly 1369 Application Design Guidelines", RFC 3235, January 2002. 1371 [10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1372 November 1998. 1374 [11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1375 (ESP)", RFC 2406, November 1998. 1377 [12] Daigle, L. and IAB, "IAB Considerations for UNilateral 1378 Self-Address Fixing (UNSAF) Across Network Address 1379 Translation", RFC 3424, November 2002. 1381 [13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1382 Methodology for Nettwork Address Translator (NAT) Traversal 1383 for the Session Initiation Protocol (SIP)", 1384 draft-rosenberg-sipping-ice-01 (work in progress), July 2003. 1386 Authors' Addresses 1388 Jonathan Rosenberg 1389 dynamicsoft 1390 600 Lanidex Plaza 1391 Parsippany, NJ 07054 1392 US 1394 Phone: +1 973 952-5000 1395 EMail: jdrosen@dynamicsoft.com 1396 URI: http://www.jdrosen.net 1397 Rohan Mahy 1398 Cisco Systems 1399 101 Cooper St 1400 Santa Cruz, CA 95060 1401 US 1403 EMail: rohan@cisco.com 1405 Christian Huitema 1406 Microsoft 1407 One Microsoft Way 1408 Redmond, WA 98052-6399 1409 US 1411 EMail: huitema@microsoft.com 1413 Intellectual Property Statement 1415 The IETF takes no position regarding the validity or scope of any 1416 intellectual property or other rights that might be claimed to 1417 pertain to the implementation or use of the technology described in 1418 this document or the extent to which any license under such rights 1419 might or might not be available; neither does it represent that it 1420 has made any effort to identify any such rights. Information on the 1421 IETF's procedures with respect to rights in standards-track and 1422 standards-related documentation can be found in BCP-11. Copies of 1423 claims of rights made available for publication and any assurances of 1424 licenses to be made available, or the result of an attempt made to 1425 obtain a general license or permission for the use of such 1426 proprietary rights by implementors or users of this specification can 1427 be obtained from the IETF Secretariat. 1429 The IETF invites any interested party to bring to its attention any 1430 copyrights, patents or patent applications, or other proprietary 1431 rights which may cover technology that may be required to practice 1432 this standard. Please address the information to the IETF Executive 1433 Director. 1435 Full Copyright Statement 1437 Copyright (C) The Internet Society (2003). All Rights Reserved. 1439 This document and translations of it may be copied and furnished to 1440 others, and derivative works that comment on or otherwise explain it 1441 or assist in its implementation may be prepared, copied, published 1442 and distributed, in whole or in part, without restriction of any 1443 kind, provided that the above copyright notice and this paragraph are 1444 included on all such copies and derivative works. However, this 1445 document itself may not be modified in any way, such as by removing 1446 the copyright notice or references to the Internet Society or other 1447 Internet organizations, except as needed for the purpose of 1448 developing Internet standards in which case the procedures for 1449 copyrights defined in the Internet Standards process must be 1450 followed, or as required to translate it into languages other than 1451 English. 1453 The limited permissions granted above are perpetual and will not be 1454 revoked by the Internet Society or its successors or assignees. 1456 This document and the information contained herein is provided on an 1457 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1458 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1459 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1460 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1461 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1463 Acknowledgement 1465 Funding for the RFC Editor function is currently provided by the 1466 Internet Society.