idnits 2.17.1 draft-rosenberg-midcom-turn-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1799. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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.) ** There are 14 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 723 has weird spacing: '...ed with an ex...' == 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 (September 9, 2005) is 6802 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) == Unused Reference: '5' is defined on line 1717, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3489 (ref. '1') (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 2617 (ref. '4') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- 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) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-04 == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-udp-02 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIDCOM J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: March 13, 2006 R. Mahy 5 Airspace 6 C. Huitema 7 Microsoft 8 September 9, 2005 10 Traversal Using Relay NAT (TURN) 11 draft-rosenberg-midcom-turn-08 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 13, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 Traversal Using Relay NAT (TURN) is a protocol that allows for an 45 element behind a NAT or firewall to receive incoming data over TCP or 46 UDP connections. It is most useful for elements behind symmetric 47 NATs or firewalls that wish to be on the receiving end of a 48 connection to a single peer. TURN does not allow for users to run 49 servers on well known ports if they are behind a nat; it supports the 50 connection of a user behind a nat to only a single peer. In that 51 regard, its role is to provide the same security functions provided 52 by symmetric NATs and firewalls, but to "turn" them into port- 53 restricted NATs. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Applicability Statement . . . . . . . . . . . . . . . . . . 5 61 5. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 62 6. Message Overview . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . 9 64 7.1 Shared Secret Request . . . . . . . . . . . . . . . . . . 9 65 7.2 Allocate Request . . . . . . . . . . . . . . . . . . . . . 12 66 7.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 12 67 7.2.2 Initial Requests . . . . . . . . . . . . . . . . . . . 12 68 7.2.3 Subsequent Requests . . . . . . . . . . . . . . . . . 15 69 7.3 Send Request . . . . . . . . . . . . . . . . . . . . . . . 16 70 7.4 Receiving Packets and Connections on the Allocated 71 Transport Address . . . . . . . . . . . . . . . . . . . . 18 72 7.5 Receiving a Set Active Destination Request . . . . . . . . 19 73 7.6 Receiving Data from the TURN Client . . . . . . . . . . . 21 74 7.7 Lifetime Expiration . . . . . . . . . . . . . . . . . . . 21 75 8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . 22 76 8.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 22 77 8.2 Obtaining a One Time Password . . . . . . . . . . . . . . 22 78 8.3 Allocating a Binding . . . . . . . . . . . . . . . . . . . 24 79 8.4 Processing Allocate Responses . . . . . . . . . . . . . . 24 80 8.5 Refreshing a Binding . . . . . . . . . . . . . . . . . . . 25 81 8.6 Sending Encapsulated Data . . . . . . . . . . . . . . . . 26 82 8.7 Receiving a Data Indication . . . . . . . . . . . . . . . 27 83 8.8 Setting the Active Destination . . . . . . . . . . . . . . 28 84 8.9 Tearing Down a Binding . . . . . . . . . . . . . . . . . . 29 85 8.10 Receiving and Sending Unencapsulated Data . . . . . . . 29 86 9. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 29 87 9.1 Message Types . . . . . . . . . . . . . . . . . . . . . . 30 88 9.2 Message Attributes . . . . . . . . . . . . . . . . . . . . 30 89 9.2.1 LIFETIME . . . . . . . . . . . . . . . . . . . . . . . 30 90 9.2.2 ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . 31 91 9.2.3 MAGIC-COOKIE . . . . . . . . . . . . . . . . . . . . . 31 92 9.2.4 BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . 31 93 9.2.5 DESTINATION-ADDRESS . . . . . . . . . . . . . . . . . 31 94 9.2.6 REMOTE-ADDRESS . . . . . . . . . . . . . . . . . . . . 31 95 9.2.7 DATA . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 9.2.8 NONCE . . . . . . . . . . . . . . . . . . . . . . . . 32 97 9.2.9 REALM . . . . . . . . . . . . . . . . . . . . . . . . 32 98 9.2.10 Response Codes . . . . . . . . . . . . . . . . . . . 32 99 10. Security Considerations . . . . . . . . . . . . . . . . . . 33 100 11. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 34 101 11.1 Problem Definition . . . . . . . . . . . . . . . . . . . 34 102 11.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . 35 103 11.3 Brittleness Introduced by TURN . . . . . . . . . . . . . 35 104 11.4 Requirements for a Long Term Solution . . . . . . . . . 36 105 11.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . 36 106 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37 107 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 108 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 109 14.1 Normative References . . . . . . . . . . . . . . . . . . 37 110 14.2 Informative References . . . . . . . . . . . . . . . . . 37 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 112 Intellectual Property and Copyright Statements . . . . . . . 40 114 1. Introduction 116 Network Address Translators (NATs), while providing many benefits, 117 also come with many drawbacks. The most troublesome of those 118 drawbacks is the fact that they break many existing IP applications, 119 and make it difficult to deploy new ones. Guidelines [9] have been 120 developed that describe how to build "NAT friendly" protocols, but 121 many protocols simply cannot be constructed according to those 122 guidelines. Examples of such protocols include multimedia 123 applications and file sharing. 125 Simple Traversal of UDP Through NAT (STUN) [1] provides one means for 126 an application to traverse a NAT. STUN allows a client to obtain a 127 transport address (and IP address and port) which may be useful for 128 receiving packets from a peer. However, addresses obtained by STUN 129 may not be usable by all peers. Those addresses work depending on 130 the topological conditions of the network. Therefore, STUN by itself 131 cannot provide a complete solution for NAT traversal. 133 A complete solution requires a means by which a client can obtain a 134 transport address from which it can receive media from any peer which 135 can send packets to the public Internet. This can only be 136 accomplished by relaying data though a server that resides on the 137 public Internet. This specification describes Traversal Using Relay 138 NAT (TURN), a protocol that allows a client to obtain IP addresses 139 and ports from such a relay. 141 Although TURN will almost always provide connectivity to a client, it 142 comes at high cost to the provider of the TURN server. It is 143 therefore desirable to use TURN as a last resort only, preferring 144 other mechanisms (such as STUN or direct connectivity) when possible. 145 To accomplish that, the Interactive Connectivity Establishment (ICE) 146 [13] methodology can be used to discover the optimal means of 147 connectivity. 149 2. Terminology 151 In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, 152 SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to 153 be interpreted as described in RFC 2119 [2] and indicate requirement 154 levels for compliant TURN implementations. 156 3. Definitions 158 TURN Client: A TURN client (also just referred to as a client) is 159 an entity that generates TURN requests. A TURN client can be an 160 end system, such as a Session Initiation Protocol (SIP) [6] User 161 Agent, or can be a network element, such as a Back-to-Back User 162 Agent (B2BUA) SIP server. The TURN protocol will provide the TURN 163 client with IP addresses that route to it from the public 164 Internet. 166 TURN Server: A TURN Server (also just referred to as a server) is 167 an entity that receives TURN requests, and sends TURN responses. 168 The server is capable of acting as a data relay, receiving data on 169 the address it provides to clients, and forwarding them to the 170 clients. 172 Transport Address: An IP address and port. 174 4. Applicability Statement 176 TURN is useful for applications that require a client to place a 177 transport address into a protocol message, with the expectation that 178 the client will be able to receive packets from a single host that 179 will send to this address. Examples of such protocols include SIP, 180 which makes use of the Session Description Protocol (SDP) [7]. SDP 181 carries and IP address on which the client will receive media packets 182 from its peer. Another example of a protocol meeting this criteria 183 is the Real Time Streaming Protocol (RTSP) [8]. 185 When a client is behind a NAT, transport addresses obtained from the 186 local operating system will not be publically routable, and 187 therefore, not useful in these protocols. TURN allows a client to 188 obtain a transport address, from a server on the public Internet, 189 which can be used in protocols meeting the above criteria. However, 190 the transport addresses obtained from TURN servers are not generally 191 useful for receiving data from anywhere. They are only useful for 192 communicating with a single peer. This is accomplished by having the 193 TURN server emulate the behavior of an address-restricted NAT. In 194 particular, the TURN server will only relay packets from an external 195 IP address towards the client if the client had previously sent a 196 packet through the TURN server towards that IP address. As a result 197 of this, when a TURN server is placed in front of a symmetric NAT, 198 the resulting combined system has identical security properties to a 199 system that just had an address restricted NAT. Since clients behind 200 such devices cannot run public servers, they cannot run them behind 201 TURN servers either. 203 5. Overview of Operation 205 The typical TURN configuration is shown in Figure 1. A TURN client 206 is connected to private network 1. This network connects to private 207 network 2 through NAT 1. Private network 2 connects to the public 208 Internet through NAT 2. On the public Internet is a TURN server. 210 /-----\ 211 // TURN \\ 212 | Server | 213 \\ // 214 \-----/ 216 +--------------+ Public Internet 217 ................| NAT 2 |....................... 218 +--------------+ 220 +--------------+ Private NET 2 221 ................| NAT 1 |....................... 222 +--------------+ 224 /-----\ 225 // TURN \\ 226 | Client | 227 \\ // Private NET 1 228 \-----/ 230 Figure 1 232 TURN is a simple client-server protocol. It is identical in syntax 233 and general operation to STUN, in order to facilitate a joint 234 implementation of both. TURN defines a request message, called 235 Allocate, which asks the TURN server to allocate a public IP address 236 and port. TURN can run over UDP and TCP, as it allows for a client 237 to request address/port pairs for receiving both UDP and TCP. 239 A TURN client first discovers the address of a TURN server. This can 240 be preconfigured, or it can be discovered using SRV records [3] This 241 will allow for different TURN servers for UDP and TCP. Once a TURN 242 server is discovered, the client sends a TURN Allocate request to the 243 TURN server. TURN provides a mechanism for mutual authentication and 244 integrity checks for both requests and responses, based on a shared 245 secret. Assuming the request is authenticated and has not been 246 tampered with, the TURN server allocates a transport address to the 247 TURN client, called the allocated transport address, and returns it 248 in the response to the Allocate Request. Normally, the allocated 249 transport address will be on one of the interfaces on the TURN server 250 itself. However, it is also allowed for the TURN server to be behind 251 a NAT, in which case the allocated transport address may correspond 252 to the NAT, which is then mapped to the private address of the TURN 253 server. Proper operation of the TURN server will require it to have 254 many bindings established in the NAT ahead of time; the means for 255 doing so are outside the scope of this specification. 257 However, the TURN server will not relay any packets from PA to SA 258 until the client sends a packet through the TURN server towards a 259 correspondent. To do that, a client sends a TURN Send command, which 260 includes a data packet and a destination IP address and port. The 261 TURN server, upon receipt of this command, will forward the packet to 262 that IP address and port, add a "permission" for that IP address, so 263 that inbound packets from that address and port are permitted. In 264 the case of TCP, the Send Request will cause the TURN server to open 265 a TCP connection towards the target if one is not already up. 267 Packets received from the TURN server via UDP or via the TCP 268 connections opened by a Send Request are then forwarded towards the 269 client, encapsulated in Data Indication messages. The usage of Send 270 Requests and Data Indication messages is inefficient. As a result, 271 once the client has concluded on a specific external client with 272 which it wishes to communicate, it can issue a Set Active Destination 273 Request. This request informs the server of a destination for which 274 unencapsulated packets are to be forwarded. As such, if a client 275 sends a packet to the TURN server which is not a TURN packet, it gets 276 sent to this destination. Similarly, packets from the external 277 client to the TURN server are forwarded to the client without 278 encapsulation in a Data Indication message. 280 Once an active destination is set, it cannot be changed for TCP. 281 Effectively, the TCP connection from the client to the TURN server 282 "switches" to the application's ownership once the Set Active 283 Destination Request has been received. 285 To do all of this, the TURN server will maintain a binding between an 286 internal 5-tuple and 1 or more external 5-tuples, as shown in 287 Figure 2. The internal 5-tuple represents the "connection" between 288 the TURN server and the TURN client. It is the actual connection in 289 the case of TCP, and in the case of UDP, it is the combination of the 290 IP address and port from which the TURN client sent its Allocate 291 Request, with the IP address and port to which that Allocate Request 292 was sent. The external local transport address is the IP address and 293 port allocated to the TURN client (the allocated transport address). 294 The external 5-tuple is the combination of the external local 295 transport address and the IP address and port of an external client 296 that the TURN client is communicating with through the TURN server. 297 Initially, there aren't any external 5-tuples, since the TURN client 298 hasn't communicated with any other hosts yet. As packets are 299 received on or sent from the allocated transport address, external 300 5-tuples are created. 302 +---------+ 303 | | 304 | External| 305 / | Client | 306 // | | 307 / | | 308 // +---------+ 309 / 310 // 311 +-+ / 312 | | / 313 | | // 314 +---------+ | | +---------+ / +---------+ 315 | | |N| | | // | | 316 | TURN | | | | |/ | External| 317 | Client |----|A|----------| TURN |------------------| Client | 318 | | | |^ ^| Server |^ ^| | 319 | | |T|| || || || | 320 +---------+ | || |+---------+| |+---------+ 321 ^ | || | | | 322 | | || | | | 323 | +-+| | | | 324 | | | | | 325 | 326 Internal Internal External External 327 Client Remote Local Local Remote 328 Performing Transport Transport Transport Transport 329 Allocations Address Address Address Address 331 | | | | 332 +-----+----+ +--------+-------+ 333 | | 334 | | 336 Internal External 337 5-Tuple 5-tuple 339 Figure 2 341 For TCP, the TURN server does not need to examine the data received; 342 it merely forwards all data between the socket pairs it has 343 associated together. In the case of UDP, the TURN server looks for a 344 magic cookie in the first 128 bytes of each UDP packet. If present, 345 it indicates that the packet is a TURN control packet, used for 346 keepalives and teardown of the binding. In the case of TCP, if 347 either side closes a connection, the TURN server closes the other 348 connection. For both UDP and TCP, the TURN server can also time out 349 a connection in the event data is not received after some configured 350 time out period. This period is sent to the client in the TURN 351 response to the Allocate request. 353 A TURN server will accept UDP packets and TCP connections from 354 external clients only when a permission for accepting it has been 355 created at the TURN server. The client creates this permission by 356 sending a packet to a specific transport address through the TURN 357 server. 359 6. Message Overview 361 TURN messages are identical to STUN messages in their syntax. TURN 362 defines several new messages - the Allocate Request, the Allocate 363 Response, the Allocate Error Response, the Send Request, the Send 364 Response, the Send Error Response, the Set Active Destination 365 Request, Set Active Destination Response, Set Actice Destination 366 Error Response and the Data Indication. TURN also uses the Shared 367 Secret Request, Shared Secret Response, and Shared Secret Error 368 Response defined by STUN. TURN makes use of some of the STUN 369 attributes (MAPPED-ADDRESS, USERNAME, MESSAGE-INTEGRITY, ERROR-CODE, 370 and UNKNOWN-ATTRIBUTES) and also defines several of its own. 371 Specifically, TURN adds the LIFETIME attribute, which allows the TURN 372 server to tell the client when the binding will be released. It 373 defines the ALTERNATE-SERVER attribute, which allows the server to 374 redirect the TURN client to connect to an alternate server. It 375 defines the MAGIC-COOKIE attribute, which allows the TURN client to 376 find TURN messages in a stream of UDP packets. It defines the 377 BANDWIDTH attribute, which allows a client to inform the server of 378 the expected bandwidth usage on the connection. It defines the 379 DESTINATION-ADDRESS attribute, which is used in the Send Request to 380 identify where the data should be sent to. It defines the REMOTE- 381 ADDRESS, which appears in a Data Indication, and tells the client 382 where the data came from. It defines the DATA attribute, which 383 contains the content in a Data Indication. Finally, it defines the 384 NONCE and REALM attributes, used for authentication. 386 7. Server Behavior 388 The server behavior depends on whether the request is a Shared Secret 389 Request, an Allocate Request or a Set Active Destination Request. 391 7.1 Shared Secret Request 393 Unlike a STUN server, a TURN server provides resources to clients 394 that connect to it. Therefore, only authorized clients can gain 395 access to a TURN server. This requires that TURN requests be 396 authenticated. TURN assumes the existence of a long-lived shared 397 secret between the client and the TURN server in order to achieve 398 this authentication. The client uses this long-lived shared secret 399 to authenticate itself in a Shared Secret Request, sent over TLS. 400 The Shared Secret Response provides the client with a one-time 401 username and password. This one-time credential is then used by the 402 server to authenticate an Allocate Request. The usage of a separate 403 long lived and one-time credentials prevents dictionary attacks, 404 whereby an observer of a message and its HMAC could guess the 405 password by an offline dictionary search. 407 When a TURN server receives a Shared Secret Request, it first 408 executes the processing described in the first three paragraphs of 409 Section 8.2 of STUN. This processing will ensure that the Shared 410 Secret Request is received over TLS. 412 Assuming it was, the server checks the Shared Secret Request for a 413 MESSAGE-INTEGRITY attribute. If not present, the server generates a 414 Shared Secret Error Response with an ERROR-CODE attribute with 415 response code 401. That response MUST include a NONCE attribute, 416 containing a nonce that the server wishes the client to reflect back 417 in a subsequent Shared Secret Request (and therefore include the 418 message integrity computation). The response MUST include a REALM 419 attribute, containing a realm from which the username and password 420 are scoped [4]. 422 If the MESSAGE-INTEGRITY attribute was present, the server checks for 423 the existence of the REALM attribute. If the attribute is not 424 present, the server MUST generate a Shared Secret Error Response. 425 That response MUST include an ERROR-CODE attribute with response code 426 434. That response MUST include a NONCE and a REALM attribute. 428 If the REALM attribute was present, the server checks for the 429 existence of the NONCE attribute. If the NONCE attribute is not 430 present, the server MUST generate a Shared Secret Error Response. 431 That response MUST include an ERROR-CODE attribute with response code 432 435. That response MUST include a NONCE attribute and a REALM 433 attribute. 435 If the NONCE attribute was present, the server checks for the 436 existence of the USERNAME attribute. If it was not present, the 437 server MUST generate a Shared Secret Error Response. The Shared 438 Secret Error Response MUST include an ERROR-CODE attribute with 439 response code 432. It MUST include a NONCE attribute and a REALM 440 attribute. 442 If the USERNAME is present, the server computes the HMAC over the 443 request as described in Section 11.2.8 of STUN. The key is computed 444 as MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" passwd), where 445 the password is the password associated with the username and realm 446 provided in the request. If the server does not have a record for 447 that username within that realm, the server generates a Shared Secret 448 Error Response. That response MUST include an ERROR-CODE attribute 449 with response code 436. That response MUST include a NONCE attribute 450 and a REALM attribute. 452 This format for the key was chosen so as to enable a common 453 authentication database for SIP and for TURN, as it is expected 454 that credentials are usually stored in their hashed forms. 456 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 457 attribute in the request, the server MUST generate a Shared Secret 458 Error Response with an ERROR-CODE attribute with response code 431. 459 This response MUST include a NONCE attribute and a REALM attribute. 461 If the computed HMAC doesn't differ from the one in the request, but 462 the nonce is stale, the server MUST generate a Shared Secret Error 463 Response. That response MUST include an ERROR-CODE attribute with 464 response code 430. That response MUST include a NONCE attribute and 465 a REALM attribute. 467 In all cases, the Shared Secret Error Response is sent over the TLS 468 connection on which the Shared Secret Request was received. 470 The server proceeds to authorize the client. The means for 471 authorization are outside the scope of this specification. It is 472 anticipated that TURN servers will be run by providers that also 473 provide an application service, such as SIP or RTSP. In that case, a 474 user would be authorized to use TURN if they are authorized to use 475 the application service. 477 The server then generates a Shared Secret Response as in Section 8.2 478 of STUN. This response will contain a USERNAME and PASSWORD, which 479 are used by the client as a short-term shared secret in subsequent 480 Allocate requests. Note that STUN specifies that the server has to 481 invalidate this username and password after 30 minutes. This is not 482 the case in TURN. In TURN, the server MUST store the allocated 483 username and password for a duration of at least 30 minutes. Once an 484 Allocate request has been authenticated using that username and 485 password, if the result was an Allocate Error Response, the username 486 and password are discarded. If the result was an Allocate Response, 487 resulting in the creation of a new binding, the username and password 488 become associated with that binding. They can only be used to 489 authenticate Allocate requests sent from the same source transport 490 address in order to refresh or de-allocate that binding. Once the 491 binding is deleted, the username and password are discarded. 493 This policy avoids replay attacks, whereby a recorded Allocate 494 request is replayed in order to obtain a binding without proper 495 authentication. It also ensures that existing bindings can be 496 refreshed without needed to continuously obtain one-time passwords 497 from the TURN server. 499 7.2 Allocate Request 501 7.2.1 Overview 503 Allocate requests are used to obtain an IP address and port that the 504 client can use to receive UDP and TCP packets from any host on the 505 network, even when the client is behind a symmetric NAT. To do this, 506 a TURN server allocates a local transport address, and passes it to 507 the client in an Allocate Response. The TURN server has a configured 508 policy that defines whether or not a packet received from an external 509 client will be passed to the TURN client. This is a set of IP 510 addresses and optionally ports that identify the permitted external 511 clients. This set of addresses is built up as a consequence of Send 512 requests from the TURN client. 514 The behavior of the server when receiving an Allocate Request depends 515 on whether the request is an initial one, or a subsequent one. An 516 initial request is one whose source and destination transport address 517 matches the internal remote and local transport addresses of an 518 existing internal 5-tuple. A subsequent request is one whose source 519 and destination transport address do not match the internal remote 520 and local transport address of an existing internal 5-tuple. 522 7.2.2 Initial Requests 524 A TURN server MUST be prepared to receive Allocate Requests over TCP 525 and UDP. The port on which to listen is based on the DNS SRV entries 526 provided by the server. Typically, this will be XXXX, the default 527 TURN port. 529 The server MUST check the Allocate Request for a MESSAGE-INTEGRITY 530 attribute. If not present, the server generates a Allocate Error 531 Response with an ERROR-CODE attribute with response code 401. 533 If the MESSAGE-INTEGRITY attribute was present, the server checks for 534 the existence of the USERNAME attribute. If it was not present, the 535 server MUST generate a Allocate Error Response. The Allocate Error 536 Response MUST include an ERROR-CODE attribute with response code 432. 538 If the USERNAME is present, the server computes the HMAC over the 539 request as described in Section 11.2.8 of STUN. The key is equal to 540 the password associated with the username in the request, where that 541 username is a short term username allocated by the TURN server. The 542 username MUST be one which has been allocated by the server in a 543 Shared Secret Response, but has not yet been used to authenticate an 544 Allocate request. If that username is not known by the server, or 545 has already been used, the server generates an Allocate Error 546 Response. That response MUST include an ERROR-CODE attribute with 547 response code 430. 549 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 550 attribute in the request, the server MUST generate a Allocate Error 551 Response with an ERROR-CODE attribute with response code 431. 553 Assuming the message integrity check passed, processing continues. 554 The server MUST check for any attributes in the request with values 555 less than or equal to 0x7fff which it does not understand. If it 556 encounters any, the server MUST generate an Allocate Error Response, 557 and it MUST include an ERROR-CODE attribute with a 420 response code. 559 That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing 560 the attributes with values less than or equal to 0x7fff which were 561 not understood. 563 If the Allocate request arrived over TCP, the Allocate Error Response 564 is sent on the connection from which the request arrived. If the 565 Allocate request arrived over UDP, the Allocate Error Response is 566 sent to the transport address from which the request was received 567 (i.e., the source IP address and port), and sent from the transport 568 address on which the request was received (i.e., the destination IP 569 address and port). 571 Assuming the Allocate request was authenticated and was well-formed, 572 the server attempts to allocate transport addresses. It first looks 573 for the BANDWIDTH attribute for the request. If present, the server 574 determines whether or not it has sufficient capacity to handle a 575 binding that will generate the requested bandwidth. If it does, the 576 server attempts to allocate a port for the client. If the clients 577 source port was in the range 1024-65535, it is RECOMMENDED that the 578 server allocate a port in that range. If the clients source port was 579 in the range of 1-1024, port selection is at the discrtion of the 580 administrator. It is RECOMMENDED that a port in the range of 1024- 581 65535 be allocated. This is one of several ways to prohibit TURN 582 from being used to attempt to run standard services. These 583 guidelines are meant to be consistent with [14], since the TURN relay 584 is effectively a NAT. 586 If a port meeting the bandwidth constraints cannot be allocated, the 587 server MUST generate a Allocate Error Response that includes an 588 ERROR-CODE attribute with a response code of 300. That response MAY 589 include an ALTERNATE-SERVER attribute pointing to an alternate server 590 which can be used by the client. 592 Once the port is allocated, the server associates it with the 593 internal 5-tuple and fills in that 5-tuple. The internal remote 594 transport address of the internal 5-tuple is set to the source 595 transport address of the Allocate Request. The internal local 596 transport address of the internal 5-tuple is set to the destination 597 transport address of the Allocate Request. For TCP, this amounts to 598 associating the TCP connection from the TURN client with the 599 allocated transport address. 601 The server MUST remember the one-time username and password used to 602 obtain the allocated transport address, and also associate it with 603 the internal 5-tuple. 605 If the LIFETIME attribute was present in the request, and the value 606 is larger than the maximum duration the server is willing to use for 607 the lifetime of the binding, the server MAY lower it to that maximum. 608 However, the server MUST NOT increase the duration requested in the 609 LIFETIME attribute. If there was no LIFETIME attribute, the server 610 may choose a default duration at its discretion. In either case, the 611 resulting duration is added to the current time, and a timer is set 612 to fire at or after that time. Section 7.7 discusses behavior when 613 the timer fires. 615 Once the port has been obtained from the operating system and the 616 activity timer started for the port binding, the server generates an 617 Allocate Response. The Allocate Response MUST contain the same 618 transaction ID contained in the Allocate Request. The length in the 619 message header MUST contain the total length of the message in bytes, 620 excluding the header. The Allocate Response MUST have a message type 621 of "Allocate Response". 623 The response MUST contain a MAGIC-COOKIE as the first attribute (this 624 is done so that endpoints can consistently use the presence of MAGIC- 625 COOKIE to discern TURN packets). The server MUST add a MAPPED- 626 ADDRESS attribute to the Allocate Response, and set it to the 627 allocated transport address. 629 The server MUST add a LIFETIME attribute to the Allocate Response. 630 This attribute contains the duration, in seconds, of the activity 631 timer associated with this binding. 633 The server MUST add a BANDWIDTH attribute to the Allocate Response. 634 This MUST be equal to the attribute from the request, if one was 635 present. Otherwise, it indicates a per-binding cap that the server 636 is placing on the bandwidth usage on each binding. Such caps are 637 needed to prevent against denial-of-service attacks (See Section 10. 639 The server MUST add, as the final attribute of the request, a 640 MESSAGE-INTEGRITY attribute. The key used in the HMAC MUST be the 641 same as that used to validate the request. 643 The TURN server then sends the response. If the Allocate request was 644 received over TCP, the response is sent over that TCP connection. If 645 the Allocate request was received over UDP, the response is sent to 646 the transport address from which the request was received (i.e., the 647 source IP address and port), and sent from the transport address on 648 which the request was received (i.e., the destination IP address and 649 port). 651 If the allocated port for TCP, the server MUST be prepared to receive 652 a TCP connection request on that port. 654 7.2.3 Subsequent Requests 656 Once a binding has been created for UDP and permissions installed, 657 the client can send subsequent Allocate requests to the TURN server. 658 To determine which packets are for the TURN server, and which need to 659 be relayed, the server looks at the packet. If the packet is shorter 660 than 28 bytes, it is not a TURN request. If it is longer than 28 661 bytes, the server checks bytes 25-28. If these bytes are equal to 662 the MAGIC-COOKIE, the request is a TURN request. Otherwise, it is a 663 data packet, and is to be relayed. 665 The server first authenticates the request. This is done as in 666 Section 7.2.2. The request MUST be authenticated using the same one- 667 time username and password used previously. That is, the source and 668 destination transport address of the Allocate Request are compared, 669 respectively, with the internal remote and local transport addresses 670 associated with existing allocations. If there is a match, the same 671 username and password used to obtain that allocation must match the 672 ones used in the request. If there is not a match, the server MUST 673 generate an Allocate Error Response with a 441 response code. 675 The server looks for the LIFETIME attribute in the Allocate Request. 676 If not found, it determines the default refresh duration, in seconds, 677 for this binding. If the LIFETIME attribute was present in the 678 request, and the value is larger than the maximum duration the server 679 is willing to extend the lifetime of the binding, the server MAY 680 lower it to that maximum. However, the server MUST NOT increase the 681 duration requested in the LIFETIME attribute. The resulting duration 682 is added to the current time, and the activity timer for this binding 683 is reset to fire at or after that time. Section 7.7 discusses 684 behavior when the timer fires. 686 Once the timer is set, the server MUST generate an Allocate Response. 687 The Allocate Response MUST contain the same transaction ID contained 688 in the Allocate Request. The length in the message header MUST 689 contain the total length of the message in bytes, excluding the 690 header. The Allocate Response MUST have a message type of "Allocate 691 Response". The response MUST contain a MAGIC-COOKIE as the first 692 attribute. It MUST contain a MAPPED-ADDRESS which contains the 693 allocated transport address. It MUST contain a LIFETIME attribute 694 which contains the time from now until the point at which the binding 695 will be deleted. The final attribute MUST be a MESSAGE-INTEGRITY 696 attribute, which MUST use the same one-time username and password 697 used to authenticate the request. 699 The TURN server then sends the response. The response is sent to the 700 transport address from which the request was received (i.e., the 701 source IP address and port), and sent from the transport address on 702 which the request was received (i.e., the destination IP address and 703 port). 705 Subsequent allocation requests cannot be sent for TCP, and as such, 706 the server should never receive them. Indeed, a server MUST NOT look 707 for them in the TCP data stream. 709 7.3 Send Request 711 A Send request is sent by a client after it has completed its 712 Allocate transaction, in order to create permissions in the server 713 and send data to an external client. Send requests are used with 714 both UDP and TCP. A server can disambiguate a UDP Send Request from 715 a data packet by looking for the MAGIC-COOKIE attribute, as described 716 in Section 7.2.3. Such disambiguation is not needed for TCP, since 717 the client cannot send this request after an external 5-tuple has 718 been activated. 720 Once the server has identified a request as a Send request, the 721 server verifies that it has arrived with a source and destination 722 transport address that matches the internal remote and local 723 transport address of an internal 5-tuple associated with an existing 724 allocation. If there is no matching allocation, the server MUST 725 generate a 437 (No Binding) Send Error Response. 727 Next, the server authenticates the request. This is done as in 728 Section 7.2.2. The request MUST be authenticated using the same one- 729 time username and password used previously. That is, the source and 730 destination transport address of the Allocate Request are compared, 731 respectively, with the internal remote and local transport addresses 732 associated with existing allocations. If there is a match, the same 733 username and password used to obtain that allocation must match the 734 ones used in the request. If there is not a match, the server MUST 735 generate a Send Error Response with a 441 response code. 737 Once the request has been authenticated, the server validates it. 738 The request should contain a DESTINATION-ADDRESS attribute and a DATA 739 attribute. If it doesn't, the server MUST reject the request with a 740 400 (Bad Request) Send Error Response. 742 Assuming the Send Request has been validated, the server then takes 743 the contents of the DATA attribute. In the case of UDP, it creates a 744 UDP packet whose payload equals that content. The server sets the 745 source IP address equal to the allocated transport address. The 746 destination transport address is set to the contents of the 747 DESTINATION-ADDRESS attribute. The server then sends the UDP packet. 748 Note that any retransmissions of this packet which might be needed 749 are not handled by the server. It is the clients responsibility to 750 generate another Send Request if needed. If the TURN client hasn't 751 previously sent to this destination IP address and port, an external 752 5-tuple is instantiated in the TURN server. Its local and remote 753 transport addresses, respectively, are set to the source and 754 destination transport addresses of the UDP packet. 756 In the case of TCP, the server checks if it has an existing TCP 757 connection open from the allocated transport address to the address 758 in the DESTINATION-ADDRESS attribute. If so, the server extracts the 759 content of the DATA attribute and sends it on matching TCP 760 connection. If the server doesn't have an existing TCP connection to 761 the destination, it MUST open one from an epheral port on the same 762 interface as the allocated transport address, and do so to the 763 transport address in the DESTINATION-ADDRESS attribute. Once the 764 connection is established, the server MUST send the contents of the 765 DATA attribute onto that connection. If the connection could not be 766 opened, or if the transmission of the data resulted in an error, the 767 TURN server MUST generate a Send Error Response with a 438 (Send 768 Failed) response code. 770 If the UDP packet or TCP data was sent without errors, the server 771 generates a Send Response. The Send Response MUST have a message 772 type of "Send Response". The response MUST contain a MAGIC-COOKIE as 773 the first attribute and a MESSAGE-INTEGRITY attribute as the last. 774 If the server needs to generate a Send Error Response, that message 775 MUST contain a message type of "Send Error Response", and MUST 776 contain a MAGIC-COOKIE as the first attribute. It MUST contain an 777 ERROR-CODE with the appropriate response code. For UDP, both the 778 Send Response and Send Error Response are sent back to the source IP 779 and port where the request came from, and sent from the same address 780 and port where the request was sent to. For TCP, the response is 781 sent on the TCP connection that the server received the request on. 783 The server then adds the IP address of the DESTINATION-ADDRESS 784 attribute to the permission list for this allocation. This happens 785 regardless of whether, in the case of TCP, the data was sent 786 successfully. 788 7.4 Receiving Packets and Connections on the Allocated Transport 789 Address 791 If a TURN server receives a TCP connection request on an allocated 792 transport address, it checks the permissions associated with that 793 allocation. If the source IP address of the TCP SYN packet match one 794 of the permissions, the TCP connection is accepted. Otherwise, it is 795 rejected. 797 If a TURN server receives a UDP packet on an allocated transport 798 address, it checks the permissions associated with that allocation. 799 If the source IP address of the UDP packet matches one of the 800 permissions, the UDP packet is accepted. Otherwise, it is discarded. 802 This emulates the address-restricted behavior of a NAT, as opposed 803 to the stricter port and address restricted behavior. This allows 804 for interoperation of TURN with clients that don't perform 805 symmetric RTP, and is needed to avoid double relays for sessions 806 between clients that are both behind symmetric NAT. 808 If the source and destination transport address of the UDP packet is 809 equal, respectively, to the remote and local transport addresses of 810 the active 5-tuple, the UDP packet is forwarded to the client and not 811 encapsulated in a TURN packet. To forward, the packet is sent with a 812 source IP address and port equal to the internal local transport 813 address, and with a destination address and port equal to the 814 internal remote transport address. 816 Similarly, if data is received on a TCP connection, and that 817 connection is the active connection, the data on that connection is 818 copied onto the connection to the TURN client. 820 If data is received from an external client on a TCP connection, and 821 that connection is not the active connection, the data are sent to 822 the client in a Data Indication message. The Data Indication message 823 MUST contain a MAGIC-COOKIE attribute as the first attribute. The 824 Data Indication message MUST contain a DATA attribute whose contents 825 are equal to the data just received on the TCP connection from the 826 external client. The message MUST contain a REMOTE-ADDRESS attribute 827 whose content is equal to the external remote transport address. 828 This packet is sent to the TURN client over the TCP connection to the 829 TURN client. 831 If a UDP packet is received from an external client, and the external 832 5-tuple don't match the active 5-tuple, the data is sent to the 833 client in a Data Indication message. This message is not 834 retransmitted by the server, and which does not generate a response. 835 As a result, like data packets which are forwarded, there is no 836 reliability guarantee provided by the TURN server for this 837 indication. The Data Indication message MUST contain a MAGIC-COOKIE 838 attribute as the first attribute. It MUST contain a DATA attribute 839 whose contents are equal to the payload of the UDP packet. The 840 message MUST contain a REMOTE-ADDRESS attribute whose content is 841 equal to the source IP address and port of the UDP packet received by 842 the TURN server. This packet is sent to the internal remote 843 transport address, and sent from the internal local transport 844 address. 846 Note that, because data is forwarded blindly across TCP bindings, TLS 847 will successfully operate over a TURN allocated TCP port. 849 7.5 Receiving a Set Active Destination Request 851 The Set Active Destination Request is used by a client to determine 852 an external 5-tuple that will be used as the forwarding destination 853 of all non-TURN data from the TURN client. Furthermore, all data 854 from that external client will be forwarded to the TURN client 855 without encapsulation in a Data Indication. 857 A server can disambiguate a UDP Set Active Destination Request from a 858 data packet by looking for the MAGIC-COOKIE attribute, as described 859 in Section 7.2.3. Such disambiguation is not needed for TCP, since 860 the client cannot send this request more than once. 862 The active destination is initially null. It is always explicitly 863 set by the Set Active Destination Request. 865 Once the server has identified a request as a Set Active Destination 866 request, the server verifies that it has arrived with a source and 867 destination transport address that matches the internal remote and 868 local transport address of an internal 5-tuple associated with an 869 existing allocation. If there is no matching allocation, the server 870 MUST generate a 437 (No Binding) Send Error Response. 872 Next, the server authenticates the request. This is done as in 873 Section 7.2.2. The request MUST be authenticated using the same one- 874 time username and password used previously. That is, the source and 875 destination transport address of the Allocate Request are compared, 876 respectively, with the internal remote and local transport addresses 877 associated with existing allocations. If there is a match, the same 878 username and password used to obtain that allocation must match the 879 ones used in the request. If there is not a match, the server MUST 880 generate a Set Active Destination Error Response with a 441 response 881 code. 883 Once the request has been authenticated, the server validates it. 884 The request should contain a DESTINATION-ADDRESS attribute. If it 885 doesn't, the server MUST reject the request with a 400 (Bad Request) 886 Set Active Destination Error Response. 888 If there is already an active 5-tuple, and the external remote 889 transport address of that 5-tuple matches the DESTINATION-ADDRESS, 890 the request is basically a no-op. The server MUST generate a Set 891 Active Destination Response. This response contains no attributes. 892 If there is an active 5-tuple but its external remote transport 893 address doesn't match, the request is asking for a change in the 894 destination. The server checks its existing external 5-tuples for 895 one whose external remote transport address matches the DESTINATION- 896 ADDRESS. If none is found, the request is rejected with a 440 (No 897 Destination) response. If one is found, the currently active one is 898 deactivated. A timer, Ta, is set to fire in 3 seconds. The server 899 sets its state to "transitioning". When Ta fires, the server returns 900 to normal operations, and then sets the external 5-tuple that matched 901 the DESTINATION-ADDRESS to the active one. While in the 902 transitioning state, the server behaves as described in this 903 specification, except for the processing of the Set Active 904 Destination Request as described below. 906 If there is no active 5-tuple, but the server is in the transitioning 907 state, it MUST reject the request with a Set Active Destination Error 908 Response that includes a 439 (Transitioning) response code. 910 If there is no active 5-tuple, and the server is not in the 911 transitioning state, the server checks its existing external 5-tuples 912 for one whose external remote transport address matches the 913 DESTINATION-ADDRESS. If one is found, that external 5-tuple is made 914 the active one, and a Set Active Destination Response is sent. If 915 none is found, the request is rejected with a 440 (No Destination) 916 response. 918 If the server needs to send a Set Active Destination Response, that 919 message MUST contain a message type of "Set Active Destination 920 Response", and MUST contain a MAGIC-COOKIE as the first attribute and 921 a MESSAGE-INTEGRITY as the last. If the server needs to send a Set 922 Active Destination Error Response, that message MUST contain a 923 message type of "Set Active Destination Error Response", and MUST 924 contain a MAGIC-COOKIE as the first attribute. It MUST contain an 925 ERROR-CODE with the appropriate response code. For UDP, both the 926 responses are sent back to the source IP and port where the request 927 came from, and sent from the same address and port where the request 928 was sent to. For TCP, the response is sent on the TCP connection 929 that the server received the request on. 931 7.6 Receiving Data from the TURN Client 933 If a TURN server receives a UDP packet from the TURN client on its 934 internal local transport address, and it is coming from an internal 935 remote transport address associated with an existing allocation, and 936 the UDP packet is not a TURN packet (known by the absence of the 937 MAGIC-COOKIE attribute), it represents UDP data that the client 938 wishes to forward. If there is an active 5-tuple, the TURN server 939 MUST forward the UDP packet on that 5-tuple. The destination address 940 and port of the UDP packet is set to the external remote transport 941 address of the active 5-tuple. The source IP address and port of the 942 UDP packet is set to the external local transport address of the 943 active 5-tuple. The TURN server SHOULD NOT retransmit the packet 944 once it has forwarded it. Such retransmissions are the 945 responsibility of the client. 947 If there is no active 5-tuple, the UDP packet is discarded. 949 If data is received on a TCP connection from the TURN client, and the 950 previous TURN message from the client was a Set Active Destination 951 Request, the data is forwarded to the active connection. Note that, 952 once a connection has been activated with a Set Active Destination 953 TURN Request, TURN messaging from the client over its TCP connection 954 to the server is not allowed. Thus, all subsequent data will be non- 955 TURN data by definition. 957 If a TCP connection associated with an allocated transport address is 958 closed, any connections to external clients MUST be closed. At that 959 point, the binding is destroyed. Similarly, if a connection from the 960 TURN server to an external client is closed, and that connection was 961 the active connection, the corresponding connection to the TURN 962 client MUST be closed, and the binding is destroyed. 964 7.7 Lifetime Expiration 966 When the activity timer for a binding fires, the server checks to see 967 if there has been any activity on the binding since its creation, or 968 since the last firing of the timer, whichever is more recent. 969 Activity is defined as connection establishment, or packet 970 transmission in either direction. If there has been activity, the 971 timer is set to fire once again in M seconds, where M is the value of 972 the LIFETIME attribute returned in the most recent Allocate Response 973 for this binding. Note that, with TCP connections, a client cannot 974 send TURN requests once a connection has been set to active. As 975 such, the value of M that is used will be the one from the first 976 Allocate Request; refreshes will not take place with TURN messages. 978 If there has been no activity, the server MUST destroy the binding, 979 along with its associated one-time password. If the binding was over 980 TCP, the server MUST close any connections it is holding to the 981 client and to the remote client. 983 8. Client Behavior 985 Client behavior is broken into several separate steps. First, the 986 client obtains a one-time username and password. Secondly, it 987 generates initial Allocate Requests, and processes the responses. It 988 manages those addresses (refreshing and tearing them down), issues 989 Send Requests and Set Active Destination Requests, and processes TURN 990 indications and data received on those addresses. 992 8.1 Discovery 994 Generally, the client will be configured with a domain name of the 995 provider of the TURN servers. This domain name is resolved to an IP 996 address and port of using the SRV procedures [3]. When sending a 997 Shared Secret request, the service name is "turn" and the protocol is 998 "tcp". RFC 2782 spells out the details of how a set of SRV records 999 are sorted and then tried. However, it only states that the client 1000 should "try to connect to the (protocol, address, service)" without 1001 giving any details on what happens in the event of failure. Those 1002 details are described here for TURN. 1004 For TURN requests, failure occurs if there is a transport failure of 1005 some sort (generally, due to fatal ICMP errors in UDP or connection 1006 failures in TCP). Failure also occurs if the request does not 1007 solicit a response after 9.5 seconds. If a failure occurs, the 1008 client SHOULD create a new request, which is identical to the 1009 previous, but has a different transaction ID and MESSAGE-INTEGRITY 1010 attribute. That request is sent to the next element in the list as 1011 specified by RFC~2782. 1013 8.2 Obtaining a One Time Password 1015 In order to allocate addresses, a client must obtain a one-time 1016 username and password from the TURN server. A unique username and 1017 password are required for each distinct address allocated from the 1018 server. 1020 To obtain a one-time username and password, the client generates and 1021 sends a Shared Secret Request. This is done as described in Section 1022 9.2 of STUN. This request will have no attributes, and therefore, 1023 based on the processing in Section 7.1, the server will reject it 1024 with a Shared Secret Error Response with a 401 response code. That 1025 response will contain a NONCE and a REALM. The client SHOULD 1026 generate a new Shared Secret Request (with a new transaction ID), 1027 which contains the NONCE and REALM attributes copied from the 401 1028 response. The request MUST include the USERNAME attribute, which 1029 contains a username supplied by the user for the specified realm. 1030 The request MUST include a MESSAGE-INTEGRITY attribute as the last 1031 attribute. The key for the HMAC is computed as described in 1032 Section 7.1. 1034 If the response (either to the initial request or to the second 1035 attempt with the credentials) is a Shared Secret Error Response, the 1036 processing depends on the value of the response code in the ERROR- 1037 CODE attribute. If the response code was a 430, the client SHOULD 1038 generate a new Shared Secret Request, using the username and password 1039 provided by the user, and the REALM and NONCE provided in the 430 1040 response. For a 431 or 436 response code, the client SHOULD alert 1041 the user. For a 432, 434 and 435 response codes, if the client had 1042 omitted the USERNAME, REALM or NONCE attributes, respectively, from 1043 the previous request, it SHOULD retry, this time including the 1044 USERNAME, NONCE, REALM, and MESSAGE-INTEGRITY attributes. For a 500 1045 response code, the client MAY wait several seconds and then retry the 1046 request. For a 600 response code, the client MUST NOT retry the 1047 request, and SHOULD display the reason phrase to the user. Unknown 1048 attributes between 400 and 499 are treated like a 400, unknown 1049 attributes between 500 and 599 are treated like a 500, and unknown 1050 attributes between 600 and 699 are treated like a 600. Any response 1051 between 100 and 399 MUST result in the cessation of request 1052 retransmissions, but otherwise is discarded. 1054 If a client receives a Shared Secret Response with an attribute whose 1055 type is unknown and greater than 0x7fff, the attribute MUST be 1056 ignored. If the client receives a Shared Secret Response with an 1057 attribute whose type is unknown and less than or equal to 0x7fff, the 1058 response is ignored. 1060 If the response is a Shared Secret Response, it will contain the 1061 USERNAME and PASSWORD attributes. The client can use these to 1062 authenticate an Allocate Request, as described below. 1064 A client MAY send multiple Shared Secret Requests over the same TLS 1065 connection, and MAY do so without waiting for responses to previous 1066 requests. The client SHOULD close its connection when it has 1067 completed allocating usernames and passwords. 1069 8.3 Allocating a Binding 1071 When a client wishes to obtain a transport address, it sends an 1072 Allocate Request to the TURN server. Requests for TCP transport 1073 addresses MUST be sent over a TCP connection, and requests for UDP 1074 transport addresses MUST be sent over UDP. 1076 First, the client obtains a one-time username and password, using the 1077 mechanisms described in Section 8.2. The client then formulates an 1078 Allocate Request. The request MUST contain a transaction ID, unique 1079 for each request, and uniformly and randomly distributed between 0 1080 and 2**128 - 1. The message type of the request MUST be "Allocate 1081 Request". The length is set as described in Section 11.1 of STUN. 1083 The Allocate request MUST contain the MAGIC-COOKIE attribute as the 1084 first attribute. 1086 The client SHOULD include a BANDWIDTH attribute, which indicates the 1087 maximum bandwidth that will be used with this binding. If the 1088 maximum is unknown, the attribute is not included in the request. 1090 The client MAY request a particular lifetime for the binding by 1091 including it in the LIFETIME attribute in the request. If the no 1092 data is sent or received on the binding before expiration of the 1093 lifetime, the binding will be deleted by the client. 1095 The client MUST include a USERNAME attribute, containing a username 1096 obtained from a previous Shared Secret Response. The request MUST 1097 include a MESSAGE-INTEGRITY attribute as the last attribute. The key 1098 is equal to the password obtained from the PASSWORD attribute of the 1099 Shared Secret Response. The Allocate Request MUST be sent to the 1100 same IP address and port as the Shared Secret Request, but from a 1101 different local ephemeral port (in other words, the TCP/TLS 1102 connection used to obtain the shared secret is not reused for 1103 allocations). This is because one time passwords are expected to be 1104 host-specific. Rules for retransmissions for Allocate Requests sent 1105 over UDP are identical to those for STUN Binding Requests. Allocate 1106 Requests sent over TCP are not retransmitted. Transaction timeouts 1107 are identical to those for STUN Binding Requests, independent of the 1108 transport protocol. 1110 8.4 Processing Allocate Responses 1112 If the response is an Allocate Error Response, the client checks the 1113 response code from the ERROR-CODE attribute of the response. For a 1114 400 response code, the client SHOULD display the reason phrase to the 1115 user. For a 420 response code, the client SHOULD retry the request, 1116 this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES 1117 attribute of the response. For a 430 response code, the client 1118 SHOULD obtain a new one-time username and password, and retry the 1119 Allocate Request with a new transaction. For 401 and 432 response 1120 codes, if the client had omitted the USERNAME or MESSAGE-INTEGRITY 1121 attribute as indicated by the error, it SHOULD try again with those 1122 attributes. A new one-time username and password is needed in that 1123 case. For a 431 response code, the client SHOULD alert the user, and 1124 MAY try the request again after obtaining a new username and 1125 password. For a 300 response code, the client SHOULD attempt a new 1126 TURN transaction to the server indicated in the ALTERNATE-SERVER 1127 attribute. For a 500 response code, the client MAY wait several 1128 seconds and then retry the request with a new username and password. 1129 For a 600 response code, the client MUST NOT retry the request, and 1130 SHOULD display the reason phrase to the user. Unknown attributes 1131 between 400 and 499 are treated like a 400, unknown attributes 1132 between 500 and 599 are treated like a 500, and unknown attributes 1133 between 600 and 699 are treated like a 600. Unknown attributes 1134 between 300 and 399 are treated like 300. Any response between 100 1135 and 299 MUST result in the cessation of any request retransmissions, 1136 but otherwise is discarded. 1138 If a client receives a response with an attribute whose type is 1139 unknown and greater than 0x7fff, the attribute MUST be ignored. If 1140 the client receives a response with an attribute whose type is 1141 unknown and less than or equal to 0x7fff, any request retransmissions 1142 MUST cease, but the entire response is otherwise ignored. 1144 If the response is an Allocate Response, the client MUST check the 1145 response for a MESSAGE-INTEGRITY attribute. If not present, the 1146 client MUST discard the response. If present, the client computes 1147 the HMAC over the response. The key MUST be same as used to compute 1148 the MESSAGE-INTEGRITY attribute in the request. If the computed HMAC 1149 differs from the one in the response, the client MUST discard the 1150 response, and SHOULD alert the user about a possible attack. If the 1151 computed HMAC matches the one from the response, processing 1152 continues. 1154 The MAPPED-ADDRESS in the Allocate Response can be used by the client 1155 for receiving packets. The server will expire the binding after 1156 LIFETIME seconds have passed with no activity. The server will allow 1157 the user to send and receive no more than the amount of data 1158 indicated in the BANDWIDTH attribute. 1160 8.5 Refreshing a Binding 1162 If there has been no activity on a UDP binding for a period of time 1163 equalling 3/4 of the lifetime of the binding (as conveyed in the 1164 LIFETIME attribute of the Allocate Response), the client SHOULD 1165 refresh the binding with another Allocate Request if it wishes to 1166 keep it. Note that only UDP bindings can be refreshed. For TCP, 1167 application-specific keepalives are needed. 1169 To perform a refresh, the client generates an Allocate Request as 1170 described in Section 8.3. However, the one-time username and 1171 password used MUST be the same as those used in the successful 1172 Allocate Request for that binding. The client will need to look for 1173 the TURN response amongst the data packets using the MAGIC-COOKIE, as 1174 described in Section 7.2.3. Processing of that response is as 1175 defined in Section 8.4. If the response was an Allocate Response, 1176 and the MAPPED-ADDRESS contains the same transport address as 1177 previously obtained, the binding has been refreshed. The LIFETIME 1178 attribute indicates the amount of additional time the binding will 1179 live without activity. If, however, the response was an Allocate 1180 Error Response with an ERROR-CODE indicating a 430 response, it means 1181 that the binding has expired at the server. The client MAY use the 1182 procedures in Section 8.3 to obtain a new binding (this will require 1183 a new one-time username and password. Other response codes do not 1184 imply that the binding has been expired, just that the refresh has 1185 failed. 1187 8.6 Sending Encapsulated Data 1189 Before receiving any UDP or TCP data, a client has to send first. To 1190 do that, it uses the Send Request. For UDP, a client MAY send this 1191 request at any time. For TCP, it MUST NOT send it after it has 1192 transmitted a Set Active Destination Request that yielded a 1193 successful result. 1195 The Send request MUST contain a transaction ID, unique for each 1196 request, and uniformly and randomly distributed between 0 and 2**128 1197 - 1. The message type of the request MUST be "Send Request". The 1198 length is set as described in Section 11.1 of STUN. 1200 The Send request MUST contain the MAGIC-COOKIE attribute as the first 1201 attribute. The client MUST include a USERNAME attribute, containing 1202 the same username used in the Allocate request for this binding. The 1203 request MUST include a MESSAGE-INTEGRITY attribute as the last 1204 attribute. The key is equal to the password used for the Allocate 1205 request for this binding. For UDP, the Send Request MUST be sent to 1206 the same IP address and port as the Allocate Request, and MUST be 1207 sent from the same source IP and port used to send the Allocate 1208 request for the binding. For TCP, it MUST be sent over the same 1209 connection used for the initial allocation. Rules for 1210 retransmissions for Send Requests sent over UDP are identical to 1211 those for STUN Binding Requests. Transaction timeouts are identical 1212 to those for STUN Binding Requests, independent of the transport 1213 protocol. 1215 The Send Request MUST contain a DESTINATION-ADDRESS attribute, which 1216 contains the IP address and port that the data is being sent to. 1218 If the server successfully sends the data, the client will receive a 1219 Send Response. Note that, as with responses to Allocate refreshes, 1220 the client will need to pick a UDP Send Response (or Send Error 1221 Response) out of the packet stream by searching for the MAGIC-COOKIE 1222 in each received UDP packet. 1224 If the response is an Send Response, the client MUST check the 1225 response for a MESSAGE-INTEGRITY attribute. If not present, the 1226 client MUST discard the response. If present, the client computes 1227 the HMAC over the response. The key MUST be same as used to compute 1228 the MESSAGE-INTEGRITY attribute in the request. If the computed HMAC 1229 differs from the one in the response, the client MUST discard the 1230 response, and SHOULD alert the user about a possible attack. If the 1231 computed HMAC matches the one from the response, processing 1232 continues. 1234 If the response is a Send Error Response, it is processed as 1235 described in the first two paragraphs of Section 8.4. TCP Send 1236 Responses are readily identifiable since application data and TURN 1237 cannot be used simultaneously on a connection. Thus, until the Set 1238 Active Destination Request is sent, the connection is used 1239 exclusively for TURN. 1241 8.7 Receiving a Data Indication 1243 Once a client has allocated a binding and used Send to send data on 1244 it, the TURN server will start to accept UDP data and incoming TCP 1245 connections from the IP addresses that the client sent or connected 1246 to. Prior to the establishment of an active destination, all such 1247 data received by the server is forwarded to the client using a DATA- 1248 INDICATION message. This message generates no response. It contains 1249 two attributes - DATA and REMOTE-ADDRESS. The REMOTE-ADDRESS 1250 attribute indicates the source transport address that the request 1251 came from. The DATA attribute contains the data from the UDP packet 1252 or TCP segment that was received. Note that the TURN server will not 1253 retransmit this indication over UDP. 1255 After an active destination is established, for TCP, no more DATA- 1256 INDICATION messages will arrive. For UDP, a DATA-INDICATION message 1257 will arrive when data comes from an external client that is not equal 1258 to the active destination. 1260 8.8 Setting the Active Destination 1262 Once the client has sent data on a binding, it can activate the 1263 5-tuple between the TURN server and a particular external client. By 1264 activating it, it means that non-TURN data sent by the client are 1265 forwarded on this 5-tuple, and data from the external client are 1266 forwarded to the TURN client without encapsulation in a DATA- 1267 INDICATION. For TCP, once a destination is activated, TURN signaling 1268 over the TCP connection is no longer possible. 1270 To activate a destination, the client constructs a Set Active 1271 Destination Request. This request MUST contain a transaction ID, 1272 unique for each request, and uniformly and randomly distributed 1273 between 0 and 2**128 - 1. The message type of the request MUST be 1274 "Set Active Destination Request". The length is set as described in 1275 Section 11.1 of STUN. 1277 The Set Active Destination request MUST contain the MAGIC-COOKIE 1278 attribute as the first attribute. The client MUST include a USERNAME 1279 attribute, containing the same username used in the Allocate request 1280 for this binding. The request MUST include a MESSAGE-INTEGRITY 1281 attribute as the last attribute. The key is equal to the password 1282 used for the Allocate request for this binding. For UDP, the Set 1283 Active Destination Request MUST be sent to the same IP address and 1284 port as the Allocate Request, and MUST be sent from the same source 1285 IP and port used to send the Allocate request for the binding. For 1286 TCP, it MUST be sent over the same connection used for the initial 1287 allocation. Rules for retransmissions for Set Active Destination 1288 Requests sent over UDP are identical to those for STUN Binding 1289 Requests. Transaction timeouts are identical to those for STUN 1290 Binding Requests, independent of the transport protocol. 1292 The Set Active Destination Request MUST contain a DESTINATION-ADDRESS 1293 attribute, which contains the IP address and port of the external 1294 client corresponding to the active 5-tuple. 1296 If the response is an Set Active Destination Response, the client 1297 MUST check the response for a MESSAGE-INTEGRITY attribute. If not 1298 present, the client MUST discard the response. If present, the 1299 client computes the HMAC over the response. The key MUST be same as 1300 used to compute the MESSAGE-INTEGRITY attribute in the request. If 1301 the computed HMAC differs from the one in the response, the client 1302 MUST discard the response, and SHOULD alert the user about a possible 1303 attack. If the computed HMAC matches the one from the response, 1304 processing continues. 1306 If the response is a Set Active Destination Response, the TURN client 1307 MUST start a timer, Ta, and set it to 3 seconds. It MUST set its 1308 state to "transitioning". When the timer fires, the client MUST 1309 return to normal state. While transitioning, the client MUST NOT 1310 send another Set Active Destination request. Furthermore, the client 1311 MUST NOT send data without TURN encapsulation (i.e., using a Send 1312 Request) while transitioning. 1314 If the response is a Set Active Destination Error Response, and the 1315 ERROR-CODE attribute in the response had a value of 439, it means 1316 that the client tried to set the active destination while the server 1317 was transitioning. The client SHOULD set a timer for 2 seconds, and 1318 when the timer fires, retry. If the client received a 440, it is 1319 because the client tried to set an active destination to an unknown 1320 external client. The TURN client MAY retry with a different 1321 destination. 1323 8.9 Tearing Down a Binding 1325 If a client no longer needs a binding, it SHOULD tear it down. For 1326 TCP, this is done by closing the connection. For UDP, this is done 1327 by performing a refresh, as described in Section 8.5, but with a 1328 LIFETIME attribute indicating a time of 0. 1330 8.10 Receiving and Sending Unencapsulated Data 1332 Once a client has set the active destination, it MUST be prepared to 1333 receive data from the socket on which the Allocate Request was sent. 1334 For UDP, the client MUST be prepared to disambiguate TURN messages 1335 from data for the lifetime of the binding. This disambiguation is 1336 done using the MAGIC-COOKIE, as described in Section 7.2.3. For TCP, 1337 all subsequent data from the server will be application data, and not 1338 TURN data. 1340 Once a destination has been activated, the client MAY send data to 1341 its peer by sending data on that same socket. Any UDP packets 1342 received by the server are forwarded to the default destination 1343 address until that address is changed by a subsequent Set Active 1344 Destination command. Similarly, any data sent over the TCP 1345 connection are forwarded to the TCP connection to the external 1346 client. 1348 9. Protocol Details 1350 This section presents the detailed encoding of the message types, 1351 attributes, and response codes which are new to TURN. The general 1352 message structure of TURN is identical to STUN [1]. 1354 9.1 Message Types 1356 TURN defines ten new Message Types: 1358 0x0003 : Allocate Request 1359 0x0103 : Allocate Response 1360 0x0113 : Allocate Error Response 1361 0x0004 : Send Request 1362 0x0104 : Send Response 1363 0x0114 : Send Error Response 1364 0x0115 : Data Indication 1365 0x0006 : Set Active Destination Request 1366 0x0106 : Set Active Destination Response 1367 0x0116 : Set Active Destination Error Response 1369 9.2 Message Attributes 1371 TURN defines the following message attributes: 1373 0x000d: LIFETIME 1374 0x000e: ALTERNATE-SERVER 1375 0x000f: MAGIC-COOKIE 1376 0x0010: BANDWIDTH 1377 0x0011: DESTINATION-ADDRESS 1378 0x0012: REMOTE-ADDRESS 1379 0x0013: DATA 1380 0x0014: NONCE 1381 0x0015: REALM 1383 9.2.1 LIFETIME 1385 The lifetime attribute represents the duration for which the server 1386 will maintain a binding in the absence of data traffic either from or 1387 to the client. It is a 32 bit value representing the number of 1388 seconds remaining until expiration. 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Lifetime | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 9.2.2 ALTERNATE-SERVER 1396 The alternate server represents an alternate IP address and port for 1397 a different TURN server to try. It is encoded in the same way as 1398 MAPPED-ADDRESS. 1400 9.2.3 MAGIC-COOKIE 1402 The MAGIC-COOKIE is used by TURN clients and servers to disambiguate 1403 TURN traffic from data traffic. Its value ix 0x72c64bc6. 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 |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| 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 9.2.4 BANDWIDTH 1411 The bandwidth attribute represents the peak bandwidth, measured in 1412 kbits per second, that the client expects to use on the binding. The 1413 value represents the sum in the receive and send directions. 1414 [[Editors note: Need to define leaky bucket parameters for this.]] 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Bandwidth | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 9.2.5 DESTINATION-ADDRESS 1422 The DESTINATION-ADDRESS is present in Send Requests and Set Active 1423 Destination Requests. It specifies the address and port where the 1424 data is to be sent. It is encoded in the same way as MAPPED-ADDRESS. 1426 9.2.6 REMOTE-ADDRESS 1428 The REMOTE-ADDRESS is present in Data Indications. It specifies the 1429 address and port from which a packet was received. It is encoded in 1430 the same way as MAPPED-ADDRESS. 1432 9.2.7 DATA 1434 The DATA attribute is present in Send Requests and Data Indications. 1435 It contains raw payload data that is to be sent (in the case of a 1436 Send Request) or was received (in the case of a Data Indication). 1438 9.2.8 NONCE 1440 The NONCE attribute is present in Shared Secret Requests and Shared 1441 Secret Error responses. It contains a sequence of qdtext or quoted- 1442 pair, which are defined in [6]. 1444 9.2.9 REALM 1446 The REALM attribute is present in Shared Secret Requests and Shared 1447 Secret Responses. It contains text which meets the grammar for 1448 "realm" as described in RFC 3261, and will thus contain a quoted 1449 string (including the quotes). 1451 9.2.10 Response Codes 1453 TURN defines the following new response codes: 1455 300 (Try Alternate): The client should contact an alternate server 1456 for this request. 1458 434 (Missing Realm): The REALM attribute was not present in the 1459 request. 1461 435 (Missing Nonce): The NONCE attribute was not present in the 1462 request. 1464 436 (Unknown Username): The USERNAME supplied in the Shared Secret 1465 Request is not known in the given REALM. 1467 437 (No Binding): A Send Request was received by the server, but 1468 there is no binding in place for the source 5-tuple. 1470 438 (Send Failed): A Send Request was received by the server over 1471 TCP, but the server wasn't able to transmit the data to the 1472 requested destination. 1474 439 (Transitioning): A Set Active Destination request was received 1475 by the server. However, a previous request was sent within the 1476 last three seconds, and the server is still transitioning to that 1477 active destination. Please repeat the request once three seconds 1478 have elapsed. 1480 440 (No Destination): A Set Active Destination request was 1481 received by the server. However, the requested destination has 1482 not been one corresponding to the destination of a Send Request, 1483 and has not been one for which packets or a connection attempt 1484 have been received. 1486 441 (Wrong Username): A TURN request was received for an allocated 1487 binding, but it did not use the same username and password that 1488 were used in the allocation. The client must supply the proper 1489 credentials, and if it cannot, it should teardown its binding, 1490 allocate a new one time password, and try again. 1492 10. Security Considerations 1494 TURN servers allocate bandwidth and port resources to clients. 1495 Therefore, a TURN server requires authentication and authorization of 1496 TURN requests. This authentication is provided by a client digest 1497 over TLS, which results in the generation of a one-time password that 1498 is used in a single subsequent Allocate Request. This mechanism 1499 protects against eavesdropping attacks and man-in-the-middle attacks. 1500 The usage of one-time passwords ensures that the Allocate Requests, 1501 which do not run over TLS, are not susceptible to offline dictionary 1502 attacks that can be used to guess the long lived shared secret 1503 between the client and the server. 1505 Because TURN servers allocate resources, they can be susceptible to 1506 denial-of-service attacks. All Allocate Requests are authenticated, 1507 so that an unknown attacker cannot launch an attack. An 1508 authenticated attacker can generate multiple Allocate Requests, but 1509 each requires a new one-time username and password. It is 1510 RECOMMENDED that servers implement a cap on the number of one-time 1511 passwords that are allocated to any specific user at a time (around 5 1512 or 10 should be sufficient). This will prevent floods of Allocate 1513 requests from a single user, in an attempt to use up the resources of 1514 the system. A single malicious user could generate a single Allocate 1515 Request, obtain a binding, and then flood the server with data over 1516 this binding, in an attempt to deny others service. However, this 1517 attack requires the attacker themselves to receive the data being 1518 sent at the server. To ameliorate these kinds of attacks, servers 1519 SHOULD implement a bandwidth cap on each binding (conveyed to the 1520 client in the BANDWIDTH attribute of the Allocate Response), and 1521 discard packets beyond the threshold. 1523 A client will use the transport address learned from the MAPPED- 1524 ADDRESS attribute of the Allocate Response to tell other users how to 1525 reach them. Therefore, a client needs to be certain that this 1526 address is valid, and will actually route to them. Such validation 1527 occurs through the TLS and HMAC-based authentication and integrity 1528 checks provided in TURN. They can guarantee the authenticity and 1529 integrity of the mapped addressses. Note that TURN is not 1530 susceptible to the attacks described in Section 12.2.3, 12.2.4, 1531 12.2.5 or 12.2.6 of STUN. These attacks are based on the fact that a 1532 STUN server mirrors the source IP address, which cannot be 1533 authenticated. TURN does not use the source address of the Allocate 1534 Request, and therefore, those attacks do not apply. 1536 TURN cannot be used by clients for subverting firewall policies. 1537 TURN has fairly limited applicability, requiring a user to send a 1538 packet to a peer before being able to receive a packet from that 1539 peer. This applies to both TCP and UDP. Thus, it does not provide a 1540 general technique for externalizing TCP and UDP sockets. Rather, it 1541 has similar security properties to the placement of an address- 1542 restricted NAT in the network, allowing messaging in from a peer only 1543 if the internal client has sent a packet out towards the IP address 1544 of that peer. This limitation means TURN cannot be used to run web 1545 servers, email servers, SIP servers, or other network servers that 1546 service a large number of clients. Rather, it facilitates rendezvous 1547 of NATted clients that use some other protocol, such as SIP, to 1548 communicate IP addresses and ports for communications. 1550 Confidentiality of the transport addresses learned through TURN does 1551 not appear to be that important, and therefore, this capability is 1552 not provided. 1554 TURN servers are useful even for users not behind a NAT. They can 1555 provide a way for truly anonymous communications. A user can cause a 1556 call to have its media routed through a TURN server, so that the 1557 user's IP addresses are never revealed. 1559 TCP transport addresses allocated by TURN will properly work with TLS 1560 and SSL. However, any addresses allocated by TURN will not operate 1561 properly with IPSec Authentication Header (AH) [10] in transport 1562 mode. IPSec ESP [11] and any tunnel-mode ESP or AH should still 1563 operate. 1565 11. IAB Considerations 1567 The IAB has studied the problem of ``Unilateral Self Address 1568 Fixing'', which is the general process by which a client attempts to 1569 determine its address in another realm on the other side of a NAT 1570 through a collaborative protocol reflection mechanism RFC 3424 [12]. 1571 TURN is an example of a protocol that performs this type of function. 1572 The IAB has mandated that any protocols developed for this purpose 1573 document a specific set of considerations. This section meets those 1574 requirements. 1576 11.1 Problem Definition 1578 From RFC 3424 [12], any UNSAF proposal must provide: 1580 Precise definition of a specific, limited-scope problem that is to 1581 be solved with the UNSAF proposal. A short term fix should not be 1582 generalized to solve other problems; this is why "short term 1583 fixes usually aren't". 1585 The specific problem being solved by TURN is for a client, which may 1586 be located behind a NAT of any type, to obtain an IP address and port 1587 on the public Internet, useful for applications that require a client 1588 to place a transport address into a protocol message, with the 1589 expectation that the client will be able to receive packets from a 1590 single host that will send to this address. Both UDP and TCP are 1591 addressed. It is also possible to send packets so that the recipient 1592 sees a source address equal to the allocated address. TURN, by 1593 design, does not allow a client to run a server (such as a web or 1594 SMTP server) using a TURN address. TURN is useful even when NAT is 1595 not present, to provide anonymity services. 1597 11.2 Exit Strategy 1599 From [12], any UNSAF proposal must provide: 1601 Description of an exit strategy/transition plan. The better short 1602 term fixes are the ones that will naturally see less and less use 1603 as the appropriate technology is deployed. 1605 It is expected that TURN will be useful indefinitely, to provide 1606 anonymity services. When used to facilitate NAT traversal, TURN does 1607 not iself provide an exit strategy. That is provided by the 1608 Interactive Connectivity Establishment (ICE) [13] mechanism. ICE 1609 allows two cooperating clients to interactively determine the best 1610 addresses to use when communicating. ICE uses TURN-allocated 1611 addresses as a last resort, only when no other means of connectivity 1612 exists. As a result, as NATs phase out, and as IPv6 is deployed, ICE 1613 will increasingly use other addresses (host local addresses). 1614 Therefore, clients will allocate TURN addresses, but not use them, 1615 and therefore, de-allocate them. Servers will see a decrease in 1616 usage. Once a provider sees that its TURN servers are not being used 1617 at all (that is, no media flows through them), they can simply remove 1618 them. ICE will operate without TURN-allocated addresses. 1620 11.3 Brittleness Introduced by TURN 1622 From [12], any UNSAF proposal must provide: 1624 Discussion of specific issues that may render systems more 1625 "brittle". For example, approaches that involve using data at 1626 multiple network layers create more dependencies, increase 1627 debugging challenges, and make it harder to transition. 1629 TURN introduces brittleness in a few ways. First, it adds another 1630 server element to any system, which adds another point of failure. 1631 TURN requires clients to demultiplex TURN packets and data based on 1632 hunting for a MAGIC-COOKIE in the TURN messages. It is possible 1633 (with extremely small probabilities) that this cookie could appear 1634 within a data stream, resulting in mis-classification. That might 1635 introduce errors into the data stream (they would appear as lost 1636 packets), and also result in loss of a binding. TURN relies on any 1637 NAT bindings existing for the duration of the bindings held by the 1638 TURN server. Neither the client nor the TURN server have a way of 1639 reliably determining this lifetime (STUN can provide a means, but it 1640 is heuristic in nature and not reliable). Therefore, if there is no 1641 activity on an address learned from TURN for some period, the address 1642 might become useless spontaneously. 1644 TURN will result in potentially significant increases in packet 1645 latencies, and also increases in packet loss probabilities. That is 1646 because it introduces an intermediary on the path of a packet from 1647 point A to B, whose location is determined by application-layer 1648 processing, not underlying routing topologies. Therefore, a packet 1649 sent from one user on a LAN to another on the same LAN may do a trip 1650 around the world before arriving. When combined with ICE, some of 1651 the most problematic cases are avoided (such as this example) by 1652 avoiding the usage of TURN addresses. However, when used, this 1653 problem will exist. 1655 Note that TURN does not suffer from many of the points of brittleness 1656 introduced by STUN. TURN will work with all existing NAT types known 1657 at the time of writing, and for the forseeable future. TURN does not 1658 introduce any topological constraints. TURN does not rely on any 1659 heuristics for NAT type classification. 1661 11.4 Requirements for a Long Term Solution 1663 From [12]}, any UNSAF proposal must provide: 1665 Identify requirements for longer term, sound technical solutions 1666 -- contribute to the process of finding the right longer term 1667 solution. 1669 Our experience with TURN continues to validate our belief in the 1670 requirements outlined in Section 14.4 of STUN. 1672 11.5 Issues with Existing NAPT Boxes 1674 From [12], any UNSAF proposal must provide: 1676 Discussion of the impact of the noted practical issues with 1677 existing, deployed NA[P]Ts and experience reports. 1679 A number of NAT boxes are now being deployed into the market which 1680 try and provide "generic" ALG functionality. These generic ALGs hunt 1681 for IP addresses, either in text or binary form within a packet, and 1682 rewrite them if they match a binding. This will interfere with 1683 proper operation of any UNSAF mechanism, including TURN. However, if 1684 a NAT tries to modify a MAPPED-ADDRESS in a TURN Allocate Response, 1685 this will be detected by the client as an attack. 1687 12. Examples 1689 TODO. 1691 13. Acknowledgements 1693 The authors would like to thank Marc Petit-Huguenin for his comments 1694 and suggestions. 1696 14. References 1698 14.1 Normative References 1700 [1] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - 1701 Simple Traversal of User Datagram Protocol (UDP) Through Network 1702 Address Translators (NATs)", RFC 3489, March 2003. 1704 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1705 Levels", BCP 14, RFC 2119, March 1997. 1707 [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1708 specifying the location of services (DNS SRV)", RFC 2782, 1709 February 2000. 1711 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1712 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 1713 Basic and Digest Access Authentication", RFC 2617, June 1999. 1715 14.2 Informative References 1717 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1718 "RTP: A Transport Protocol for Real-Time Applications", 1719 RFC 3550, July 2003. 1721 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1722 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1723 Session Initiation Protocol", RFC 3261, June 2002. 1725 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1726 Protocol", RFC 2327, April 1998. 1728 [8] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 1729 Protocol (RTSP)", RFC 2326, April 1998. 1731 [9] Senie, D., "Network Address Translator (NAT)-Friendly 1732 Application Design Guidelines", RFC 3235, January 2002. 1734 [10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1735 November 1998. 1737 [11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1738 (ESP)", RFC 2406, November 1998. 1740 [12] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1741 Address Fixing (UNSAF) Across Network Address Translation", 1742 RFC 3424, November 2002. 1744 [13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1745 Methodology for Network Address Translator (NAT) Traversal for 1746 Multimedia Session Establishment Protocols", 1747 draft-ietf-mmusic-ice-04 (work in progress), February 2005. 1749 [14] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 1750 Unicast UDP", draft-ietf-behave-nat-udp-02 (work in progress), 1751 June 2005. 1753 Authors' Addresses 1755 Jonathan Rosenberg 1756 Cisco Systems 1757 600 Lanidex Plaza 1758 Parsippany, NJ 07054 1759 US 1761 Phone: +1 973 952-5000 1762 Email: jdrosen@cisco.com 1763 URI: http://www.jdrosen.net 1765 Rohan Mahy 1766 Airspace 1768 Email: rohan@ekabal.com 1769 Christian Huitema 1770 Microsoft 1771 One Microsoft Way 1772 Redmond, WA 98052-6399 1773 US 1775 Email: huitema@microsoft.com 1777 Intellectual Property Statement 1779 The IETF takes no position regarding the validity or scope of any 1780 Intellectual Property Rights or other rights that might be claimed to 1781 pertain to the implementation or use of the technology described in 1782 this document or the extent to which any license under such rights 1783 might or might not be available; nor does it represent that it has 1784 made any independent effort to identify any such rights. Information 1785 on the procedures with respect to rights in RFC documents can be 1786 found in BCP 78 and BCP 79. 1788 Copies of IPR disclosures made to the IETF Secretariat and any 1789 assurances of licenses to be made available, or the result of an 1790 attempt made to obtain a general license or permission for the use of 1791 such proprietary rights by implementers or users of this 1792 specification can be obtained from the IETF on-line IPR repository at 1793 http://www.ietf.org/ipr. 1795 The IETF invites any interested party to bring to its attention any 1796 copyrights, patents or patent applications, or other proprietary 1797 rights that may cover technology that may be required to implement 1798 this standard. Please address the information to the IETF at 1799 ietf-ipr@ietf.org. 1801 Disclaimer of Validity 1803 This document and the information contained herein are provided on an 1804 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1805 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1806 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1807 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1808 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1809 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1811 Copyright Statement 1813 Copyright (C) The Internet Society (2005). This document is subject 1814 to the rights, licenses and restrictions contained in BCP 78, and 1815 except as set forth therein, the authors retain all their rights. 1817 Acknowledgment 1819 Funding for the RFC Editor function is currently provided by the 1820 Internet Society.