idnits 2.17.1 draft-rosenberg-midcom-turn-06.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1421. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1437), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2004) is 7115 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 1340, 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-02 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIDCOM J. Rosenberg 2 Internet-Draft R. Mahy 3 Expires: April 25, 2005 Cisco Systems 4 C. Huitema 5 Microsoft 6 October 25, 2004 8 Traversal Using Relay NAT (TURN) 9 draft-rosenberg-midcom-turn-06 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 25, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 Traversal Using Relay NAT (TURN) is a protocol that allows for an 43 element behind a NAT or firewall to receive incoming data over TCP or 44 UDP connections. It is most useful for elements behind symmetric 45 NATs or firewalls that wish to be on the receiving end of a 46 connection to a single peer. TURN does not allow for users to run 47 servers on well known ports if they are behind a nat; it supports the 48 connection of a user behind a nat to only a single peer. In that 49 regard, its role is to provide the same security functions provided 50 by symmetric NATs and firewalls, but to "turn" them into 51 port-restricted NATs. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 59 5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 60 6. Message Overview . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 62 7.1 Shared Secret Request . . . . . . . . . . . . . . . . . . 8 63 7.2 Allocate Request . . . . . . . . . . . . . . . . . . . . . 10 64 7.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 10 65 7.2.2 Initial Requests . . . . . . . . . . . . . . . . . . . 10 66 7.2.3 Subsequent Requests . . . . . . . . . . . . . . . . . 13 67 7.3 Send Request . . . . . . . . . . . . . . . . . . . . . . . 14 68 7.4 Receiving Packets and Connections . . . . . . . . . . . . 15 69 7.5 Lifetime Expiration . . . . . . . . . . . . . . . . . . . 17 70 8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 71 8.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 72 8.2 Obtaining a One Time Password . . . . . . . . . . . . . . 18 73 8.3 Allocating a Binding . . . . . . . . . . . . . . . . . . . 19 74 8.4 Processing Allocate Responses . . . . . . . . . . . . . . 20 75 8.5 Refreshing a Binding . . . . . . . . . . . . . . . . . . . 21 76 8.6 Sending Data . . . . . . . . . . . . . . . . . . . . . . . 21 77 8.7 Tearing Down a Binding . . . . . . . . . . . . . . . . . . 22 78 8.8 Receiving and Sending Data . . . . . . . . . . . . . . . . 22 79 9. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 23 80 9.1 Message Types . . . . . . . . . . . . . . . . . . . . . . 23 81 9.2 Message Attributes . . . . . . . . . . . . . . . . . . . . 23 82 9.2.1 LIFETIME . . . . . . . . . . . . . . . . . . . . . . . 23 83 9.2.2 ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . 24 84 9.2.3 MAGIC-COOKIE . . . . . . . . . . . . . . . . . . . . . 24 85 9.2.4 BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . 24 86 9.2.5 DESTINATION-ADDRESS . . . . . . . . . . . . . . . . . 24 87 9.2.6 SOURCE-ADDRESS . . . . . . . . . . . . . . . . . . . . 24 88 9.2.7 DATA . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 9.2.8 NONCE . . . . . . . . . . . . . . . . . . . . . . . . 25 90 9.2.9 Response Codes . . . . . . . . . . . . . . . . . . . . 25 91 10. Security Considerations . . . . . . . . . . . . . . . . . . 25 92 11. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 27 93 11.1 Problem Definition . . . . . . . . . . . . . . . . . . . . 27 94 11.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 27 95 11.3 Brittleness Introduced by TURN . . . . . . . . . . . . . . 28 96 11.4 Requirements for a Long Term Solution . . . . . . . . . . 29 97 11.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . 29 98 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 101 13.2 Informative References . . . . . . . . . . . . . . . . . . . 30 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 103 Intellectual Property and Copyright Statements . . . . . . . . 32 105 1. Introduction 107 Network Address Translators (NATs), while providing many benefits, 108 also come with many drawbacks. The most troublesome of those 109 drawbacks is the fact that they break many existing IP applications, 110 and make it difficult to deploy new ones. Guidelines [9] have been 111 developed that describe how to build "NAT friendly" protocols, but 112 many protocols simply cannot be constructed according to those 113 guidelines. Examples of such protocols include multimedia 114 applications and file sharing. 116 Simple Traversal of UDP Through NAT (STUN) [1] provides one means for 117 an application to traverse a NAT. STUN allows a client to obtain a 118 transport address (and IP address and port) which may be useful for 119 receiving packets from a peer. However, addresses obtained by STUN 120 may not be usable by all peers. Those addresses work depending on 121 the topological conditions of the network. Therefore, STUN by itself 122 cannot provide a complete solution for NAT traversal. 124 A complete solution requires a means by which a client can obtain a 125 transport address from which it can receive media from any peer which 126 can send packets to the public Internet. This can only be 127 accomplished by relaying data though a server that resides on the 128 public Internet. This specification describes Traversal Using Relay 129 NAT (TURN), a protocol that allows a client to obtain IP addresses 130 and ports from such a relay. 132 Although TURN will almost always provide connectivity to a client, it 133 comes at high cost to the provider of the TURN server. It is 134 therefore desirable to use TURN as a last resort only, preferring 135 other mechanisms (such as STUN or direct connectivity) when possible. 136 To accomplish that, the Interactive Connectivity Establishment (ICE) 137 [13] methodology can be used to discover the optimal means of 138 connectivity. 140 2. Terminology 142 In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, 143 SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to 144 be interpreted as described in RFC 2119 [2] and indicate requirement 145 levels for compliant TURN implementations. 147 3. Definitions 149 TURN Client: A TURN client (also just referred to as a client) is 150 an entity that generates TURN requests. A TURN client can be an 151 end system, such as a Session Initiation Protocol (SIP) [6] User 152 Agent, or can be a network element, such as a Back-to-Back User 153 Agent (B2BUA) SIP server. The TURN protocol will provide the TURN 154 client with IP addresses that route to it from the public 155 Internet. 157 TURN Server: A TURN Server (also just referred to as a server) is 158 an entity that receives TURN requests, and sends TURN responses. 159 The server is capable of acting as a data relay, receiving data on 160 the address it provides to clients, and forwarding them to the 161 clients. 163 Transport Address: An IP address and port. 165 4. Applicability Statement 167 TURN is useful for applications that require a client to place a 168 transport address into a protocol message, with the expectation that 169 the client will be able to receive packets from a single host that 170 will send to this address. Examples of such protocols include SIP, 171 which makes use of the Session Description Protocol (SDP) [7]. SDP 172 carries and IP address on which the client will receive media packets 173 from its peer. Another example of a protocol meeting this criteria 174 is the Real Time Streaming Protocol (RTSP) [8]. 176 When a client is behind a NAT, transport addresses obtained from the 177 local operating system will not be publically routable, and 178 therefore, not useful in these protocols. TURN allows a client to 179 obtain a transport address, from a server on the public Internet, 180 which can be used in protocols meeting the above criteria. However, 181 the transport addresses obtained from TURN servers are not generally 182 useful for receiving data from anywhere. They are only useful for 183 communicating with a single peer. This is accomplished by having the 184 TURN server emulate the behavior of a port-restricted NAT. In 185 particular, the TURN server will only relay packets from an external 186 IP address and port towards the client if the client had previously 187 sent a packet through the TURN server towards that IP address and 188 port. As a result of this, when a TURN server is placed in front of 189 a symmetric NAT, the resulting combined system has identical security 190 properties to a system that just had a port-restricted NAT. Since 191 clients behind such devices cannot run public servers, they cannot 192 run them behind TURN servers either. 194 5. Overview of Operation 196 The typical TURN configuration is shown in Figure 1. A TURN client 197 is connected to private network 1. This network connects to private 198 network 2 through NAT 1. Private network 2 connects to the public 199 Internet through NAT 2. On the public Internet is a TURN server. 201 /-----\ 202 // TURN \\ 203 | Server | 204 \\ // 205 \-----/ 207 +--------------+ Public Internet 208 ................| NAT 2 |....................... 209 +--------------+ 211 +--------------+ Private NET 2 212 ................| NAT 1 |....................... 213 +--------------+ 215 /-----\ 216 // TURN \\ 217 | Client | 218 \\ // Private NET 1 219 \-----/ 221 Figure 1 223 TURN is a simple client-server protocol. It is identical in syntax 224 and general operation to STUN, in order to facilitate a joint 225 implementation of both. TURN defines a request message, called 226 Allocate, which asks for a public IP address and port. TURN can run 227 over UDP and TCP, as it allows for a client to request address/port 228 pairs for receiving both UDP and TCP. 230 A TURN client first discovers the address of a TURN server. This can 231 be preconfigured, or it can be discovered using SRV records [3] This 232 will allow for different TURN servers for UDP and TCP. Once a TURN 233 server is discovered, the client sends a TURN Allocate request to the 234 TURN server. TURN provides a mechanism for mutual authentication and 235 integrity checks for both requests and responses, based on a shared 236 secret. Assuming the request is authenticated and has not been 237 tampered with, the TURN server remembers the source transport address 238 that the request came from (call this SA), and returns a public 239 transport address, PA, in the TURN response. The TURN server is 240 responsible for guaranteeing that packets sent to PA route to the 241 TURN server. However, the TURN server will not relay any packets 242 from PA to SA until the client sends a packet through the TURN server 243 towards a correspondent. To do that, a client sends a TURN SEND 244 command, which includes a data packet and a destination IP address 245 and port. The TURN server, upon receipt of this command, will 246 forward the packet to that IP address and port, add a "permission" 247 for that IP address and port, so that inbound packets from that 248 address and port are permitted, and set the default destination 249 address to that address and port. From that point forward, non-TURN 250 UDP packets sent from the client to the TURN server are relayed to 251 this default IP address and port. Packets received from this IP 252 address and port are relayed to the client. If a packet arrives from 253 an IP address and port for which there is a permission, but which is 254 not the current default destination IP address and port, the TURN 255 server forwards this packet to the client wrapped in a DATA command, 256 which informs the client of the source IP address and port. 258 For TCP, the TURN server does not need to examine the data received; 259 it merely forwards all data between the socket pairs it has 260 associated together. In the case of UDP, the TURN server looks for a 261 magic cookie in the first 128 bytes of each UDP packet. If present, 262 it indicates that the packet is a TURN control packet, used for 263 keepalives and teardown of the binding. In the case of TCP, if 264 either side closes a connection, the TURN server closes the other 265 connection. For both UDP and TCP, the TURN server can also time out 266 a connection in the event data is not received after some configured 267 time out period. This period is sent to the client in the TURN 268 response to the Allocate request. 270 6. Message Overview 272 TURN messages are identical to STUN messages in their syntax. TURN 273 defines several new messages - the Allocate Request, the Allocate 274 Response, the Allocate Error Response, the Send Request, the Send 275 Response, the Send Error Response and the Data Indication. TURN also 276 uses the Shared Secret Request, Shared Secret Response, and Shared 277 Secret Error Response defined by STUN. TURN makes use of some of the 278 STUN attributes (MAPPED-ADDRESS, USERNAME, MESSAGE-INTEGRITY, 279 ERROR-CODE, and UNKNOWN-ATTRIBUTES) and also defines several of its 280 own. Specifically, TURN adds the LIFETIME attribute, which allows 281 the TURN server to tell the client when the binding will be released. 282 It defines the MAGIC-COOKIE attribute, which allows the TURN client 283 to find TURN messages in a stream of UDP packets. It defines the 284 BANDWIDTH attribute, which allows a client to inform the server of 285 the expected bandwidth usage on the connection. Finally, it defines 286 the ALTERNATE-SERVER attribute, which allows the server to redirect 287 the TURN client to connect to an alternate server. 289 7. Server Behavior 291 The server behavior depends on whether the request is a Shared Secret 292 Request or an Allocate Request. 294 7.1 Shared Secret Request 296 Unlike a STUN server, a TURN server provides resources to clients 297 that connect to it. Therefore, only authorized clients can gain 298 access to a TURN server. This requires that TURN requests be 299 authenticated. TURN assumes the existence of a long-lived shared 300 secret between the client and the TURN server in order to achieve 301 this authentication. The client uses this long-lived shared secret 302 to authenticate itself in a Shared Secret Request, sent over TLS. 303 The Shared Secret Response provides the client with a one-time 304 username and password. This one-time credential is then used by the 305 server to authenticate an Allocate Request. The usage of a separate 306 long lived and one-time credentials prevents dictionary attacks, 307 whereby an observer of a message and its HMAC could guess the 308 password by an offline dictionary search. 310 When a TURN server receives a Shared Secret Request, it first 311 executes the processing described in the first three paragraphs of 312 Section 8.2 of STUN. This processing will ensure that the Shared 313 Secret Request is received over TLS. 315 Assuming it was, the server checks the Shared Secret Request for a 316 MESSAGE-INTEGRITY attribute. If not present, the server generates a 317 Shared Secret Error Response with an ERROR-CODE attribute with 318 response code 401. That response MUST include a NONCE attribute, 319 containing a nonce that the server wishes the client to reflect back 320 in a subsequent Shared Secret Request (and therefore include the 321 message integrity computation). The response MUST include a REALM 322 attribute, containing a realm from which the username and password 323 are scoped [4]. 325 If the MESSAGE-INTEGRITY attribute was present, the server checks for 326 the existence of the REALM attribute. If the attribute is not 327 present, the server MUST generate a Shared Secret Error Response. 328 That response MUST include an ERROR-CODE attribute with response code 329 434. That response MUST include a NONCE and a REALM attribute. 331 If the REALM attribute was present, the server checks for the 332 existence of the NONCE attribute. If the NONCE attribute is not 333 present, the server MUST generate a Shared Secret Error Response. 334 That response MUST include an ERROR-CODE attribute with response code 335 435. That response MUST include a NONCE attribute and a REALM 336 attribute. 338 If the NONCE attribute was present, the server checks for the 339 existence of the USERNAME attribute. If it was not present, the 340 server MUST generate a Shared Secret Error Response. The Shared 341 Secret Error Response MUST include an ERROR-CODE attribute with 342 response code 432. It MUST include a NONCE attribute and a REALM 343 attribute. 345 If the USERNAME is present, the server computes the HMAC over the 346 request as described in Section 11.2.8 of STUN. The key is computed 347 as MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" passwd), where 348 the password is the password associated with the username and realm 349 provided in the request. If the server does not have a record for 350 that username within that realm, the server generates a Shared Secret 351 Error Response. That response MUST include an ERROR-CODE attribute 352 with response code 436. That response MUST include a NONCE attribute 353 and a REALM attribute. 355 This format for the key was chosen so as to enable a common 356 authentication database for SIP and for TURN, as it is expected 357 that credentials are usually stored in their hashed forms. 359 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 360 attribute in the request, the server MUST generate a Shared Secret 361 Error Response with an ERROR-CODE attribute with response code 431. 362 This response MUST include a NONCE attribute and a REALM attribute. 364 If the computed HMAC doesn't differ from the one in the request, but 365 the nonce is stale, the server MUST generate a Shared Secret Error 366 Response. That response MUST include an ERROR-CODE attribute with 367 response code 430. That response MUST include a NONCE attribute and 368 a REALM attribute. 370 In all cases, the Shared Secret Error Response is sent over the TLS 371 connection on which the Shared Secret Request was received. 373 The server proceeds to authorize the client. The means for 374 authorization are outside the scope of this specification. It is 375 anticipated that TURN servers will be run by providers that also 376 provide an application service, such as SIP or RTSP. In that case, a 377 user would be authorized to use TURN if they are authorized to use 378 the application service. 380 The server then generates a Shared Secret Response as in Section 8.2 381 of STUN. This response will contain a USERNAME and PASSWORD, which 382 are used by the client as a short-term shared secret in subsequent 383 Allocate requests. Note that STUN specifies that the server has to 384 invalidate this username and password after 30 minutes. This is not 385 the case in TURN. In TURN, the server MUST store the allocated 386 username and password for a duration of at least 30 minutes. Once an 387 Allocate request has been authenticated using that username and 388 password, if the result was an Allocate Error Response, the username 389 and password are discarded. If the result was an Allocate Response, 390 resulting in the creation of a new binding, the username and password 391 become associated with that binding. They can only be used to 392 authenticate Allocate requests sent from the same source transport 393 address in order to refresh or de-allocate that binding. Once the 394 binding is deleted, the username and password are discarded. 396 This policy avoids replay attacks, whereby a recorded Allocate 397 request is replayed in order to obtain a binding without proper 398 authentication. It also ensures that existing bindings can be 399 refreshed without needed to continuously obtain one-time passwords 400 from the TURN server. 402 7.2 Allocate Request 404 7.2.1 Overview 406 Allocate requests are used to obtain an IP address and port that the 407 client can use to receive UDP and TCP packets from any host on the 408 network, even when the client is behind a symmetric NAT. To do this, 409 a TURN server allocates a local transport address, and passes it to 410 the client in an Allocate Response. The server also maintains, for 411 each local transport address, a list of permissions. These 412 permissions are IP address and port combinations that the client has 413 directed a request to, using the SEND primitive. The server 414 maintains an IP address and port called the default destination. 415 This is the default destination for non-TURN packets received from 416 the client. 418 The server maintains a set of bindings. These bindings are 419 associations between the five-tuple of received Allocate requests 420 (source IP address and port, destination IP address and port, and 421 protocol), called the allocate five-tuple, and another five tuple, 422 called the remote five-tuple. 424 The behavior of the server when receiving an Allocate Request depends 425 on whether the request is an initial one, or a subsequent one. An 426 initial request is one received with a source transport address which 427 is not associated with any existing bindings. A subsequent request 428 is one received that is associated with an existing binding. 430 7.2.2 Initial Requests 432 A TURN server MUST be prepared to receive Binding Requests over TCP 433 and UDP. The port on which to listen is based on the DNS SRV entries 434 provided by the server. Typically, this will be XXXX, the default 435 TURN port. 437 The server MUST check the Allocate Request for a MESSAGE-INTEGRITY 438 attribute. If not present, the server generates a Allocate Error 439 Response with an ERROR-CODE attribute with response code 401. 441 If the MESSAGE-INTEGRITY attribute was present, the server checks for 442 the existence of the USERNAME attribute. If it was not present, the 443 server MUST generate a Allocate Error Response. The Allocate Error 444 Response MUST include an ERROR-CODE attribute with response code 432. 446 If the USERNAME is present, the server computes the HMAC over the 447 request as described in Section 11.2.8 of STUN. The key is equal to 448 the password associated with the username in the request, where that 449 username is a short term username allocated by the TURN server. The 450 username MUST be one which has been allocated by the server in a 451 Shared Secret Response, but has not yet been used to authenticate an 452 Allocate request. If that username is not known by the server, or 453 has already been used, the server generates an Allocate Error 454 Response. That response MUST include an ERROR-CODE attribute with 455 response code 430. 457 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 458 attribute in the request, the server MUST generate a Allocate Error 459 Response with an ERROR-CODE attribute with response code 431. 461 Assuming the message integrity check passed, processing continues. 462 The server MUST check for any attributes in the request with values 463 less than or equal to 0x7fff which it does not understand. If it 464 encounters any, the server MUST generate an Allocate Error Response, 465 and it MUST include an ERROR-CODE attribute with a 420 response code. 467 That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing 468 the attributes with values less than or equal to 0x7fff which were 469 not understood. 471 If the Allocate request arrived over TCP, the Allocate Error Response 472 is sent on the connection from which the request arrived. If the 473 Allocate request arrived over UDP, the Allocate Error Response is 474 sent to the transport address from which the request was received 475 (i.e., the source IP address and port), and sent from the transport 476 address on which the request was received (i.e., the destination IP 477 address and port). 479 Assuming the Allocate request was authenticated and was well-formed, 480 the server attempts to allocate transport addresses. It first looks 481 for the BANDWIDTH attribute for the request. If present, the server 482 determines whether or not it has sufficient capacity to handle a 483 binding that will generate the requested bandwidth. If it does, the 484 server attempts to allocate a port for the client. The server MUST 485 NOT allocate ports from the well-known port range (0-1023) and MUST 486 NOT allocate ports from the user registered port range (1024 through 487 49151). 489 If a port meeting the bandwidth constraints cannot be allocated, the 490 server MUST generate a Allocate Error Response that includes an 491 ERROR-CODE attribute with a response code of 300. That response MAY 492 include an ALTERNATE-SERVER attribute pointing to an alternate server 493 which can be used by the client. 495 Once the port is allocated, the server creates a binding for it. 496 This binding is a mapping between two five-tuples - the allocate 497 five-tuple and the remote five-tuple. The allocate five-tuple is set 498 to the five-tuple of the Allocate Request (that is, the protocol of 499 the allocate five-tuple is set to the protocol of the Allocate 500 Request (TCP or UDP), the source IP address and port of the allocate 501 five-tuple are set to the source IP address and port in the Allocate 502 Request, and the destination IP address and port of the allocate 503 five-tuple are set to the destination IP address and port in the 504 Allocate Request). The protocol in the remote five-tuple is set to 505 the protocol from the Allocate Request. The source IP address of the 506 remote five-tuple is set to the interface from which the port was 507 allocated. The source port of the remote five-tuple is set to the 508 allocated port. If the binding was allocated for TCP, the connection 509 on which the Allocate request was received is associated with the 510 allocate five-tuple in the binding. 512 The server MUST remember the one-time username and password used to 513 obtain the binding. 515 If the LIFETIME attribute was present in the request, and the value 516 is larger than the maximum duration the server is willing to use for 517 the lifetime of the binding, the server MAY lower it to that maximum. 518 However, the server MUST NOT increase the duration requested in the 519 LIFETIME attribute. If there was no LIFETIME attribute, the server 520 may choose a default duration at its discretion. In either cae, the 521 resulting duration is added to the current time, and a timer is set 522 to fire at or after that time. Section 7.5 discusses behavior when 523 the timer fires. 525 Once the port has been obtained from the operating system and the 526 activity timer started for the port binding, the server generates an 527 Allocate Response. The Allocate Response MUST contain the same 528 transaction ID contained in the Allocate Request. The length in the 529 message header MUST contain the total length of the message in bytes, 530 excluding the header. The Allocate Response MUST have a message type 531 of "Allocate Response". 533 The server MUST add a MAPPED-ADDRESS attribute to the Allocate 534 Response. The IP address component of this attribute MUST be set to 535 the interface from which the base port was allocated. The port 536 component of this attribute MUST be set to the base port. 538 The server MUST add a LIFETIME attribute to the Allocate Response. 539 This attribute contains the duration, in seconds, of the activity 540 timer associated with this binding. 542 The server MUST add a BANDWIDTH attribute to the Allocate Response. 543 This MUST be equal to the attribute from the request, if one was 544 present. Otherwise, it indicates a per-binding cap that the server 545 is placing on the bandwidth usage on each binding. Such caps are 546 needed to prevent against denial-of-service attacks (See Section 10. 548 The server MUST add, as the final attribute of the request, a 549 MESSAGE-INTEGRITY attribute. The key used in the HMAC MUST be the 550 same as that used to validate the request. 552 The TURN server then sends the response. If the Allocate request was 553 received over TCP, the response is sent over that TCP connection. If 554 the Allocate request was received over UDP, the response is sent to 555 the transport address from which the request was received (i.e., the 556 source IP address and port), and sent from the transport address on 557 which the request was received (i.e., the destination IP address and 558 port). 560 If the port was for TCP, the server MUST be prepared to receive a TCP 561 connection request on that port. 563 7.2.3 Subsequent Requests 565 Once a binding has been created for UDP and permissions installed, 566 the client can send subsequent Allocate requests to the TURN server. 567 To determine which packets are for the TURN server, and which need to 568 be relayed, the server looks at the packet. If the packet is shorter 569 than 28 bytes, it is not a TURN request. If it is longer than 28 570 bytes, the server checks bytes 25-28. If these bytes are equal to 571 the MAGIC-COOKIE, the request is a TURN request. Otherwise, it is a 572 data packet, and is to be relayed. 574 The server first authenticates the request. This is done as in 575 Section 7.2.2. The request MUST be authenticated using the same 576 one-time username and password used to allocate that binding 577 previously. That is, the five-tuple from the Allocate request is 578 compared to the allocate five-tuples in existing bindings. The 579 matching binding is selected. The one-time username and password 580 associated with that binding MUST match the ones used in the request. 582 The server looks for the LIFETIME attribute in the Allocate Request. 583 If not found, it determines the default refresh duration, in seconds, 584 for this binding. If the LIFETIME attribute was present in the 585 request, and the value is larger than the maximum duration the server 586 is willing to extend the lifetime of the binding, the server MAY 587 lower it to that maximum. However, the server MUST NOT increase the 588 duration requested in the LIFETIME attribute. The resulting duration 589 is added to the current time, and the activity timer for this binding 590 is reset to fire at or after that time. Section 7.5 discusses 591 behavior when the timer fires. 593 Once the timer is set, the server MUST generate an Allocate Response. 594 The Allocate Response MUST contain the same transaction ID contained 595 in the Allocate Request. The length in the message header MUST 596 contain the total length of the message in bytes, excluding the 597 header. The Allocate Response MUST have a message type of "Allocate 598 Response". The response MUST contain a MAGIC-COOKIE as the first 599 attribute. It MUST contain a MAPPED-ADDRESS which contains the 600 source IP address and port from the remote five-tuple of the binding. 601 It MUST contain a LIFETIME attribute which contains the time from now 602 until the point at which the binding will be deleted. The final 603 attribute MUST be a MESSAGE-INTEGRITY attribute, which MUST use the 604 same one-time username and password used to authenticate the request. 606 The TURN server then sends the response. The response is sent to the 607 transport address from which the request was received (i.e., the 608 source IP address and port), and sent from the transport address on 609 which the request was received (i.e., the destination IP address and 610 port). 612 7.3 Send Request 614 In order for the TURN server to relay packets to and from the client, 615 it must be "primed" with one of more Send requests. These requests 616 are used with UDP, and carry a data payload. In addition, they 617 contain a destination IP address and port. A Send Request is like 618 any other TURN request. A server can disambiguate a Send Request 619 from a data packet by looking for the MAGIC-COOKIE attribute, as 620 described in Section 7.2.3. 622 Once the server has identified a request as a Send request, the 623 server verifies that it has arrived with a source five-tuple 624 corresponding to an existing allocation. If there is no matching 625 allocation, the server MUST generate a 437 (No Binding) Send Error 626 Response. 628 Next, the server authenticates the request. This is done as in 629 Section 7.2.2. The request MUST be authenticated using the same 630 one-time username and password used to allocate that binding 631 previously. That is, the five-tuple from the Send request is 632 compared to the allocate five-tuples in existing bindings. The 633 matching binding is selected. The one-time username and password 634 associated with that binding MUST match the ones used in the request. 636 Once the request has been authenticated, the server validates it. 637 The request should contain a DESTINATION-ADDRESS attribute and a DATA 638 attribute. If it doesn't, the server MUST reject the request with a 639 400 (Bad Request) Send Error Response. 641 Assuming the Send Request has been validated, the server then takes 642 the contents of the DATA attribute, and creates a UDP packet whose 643 payload equals that content. The server sets the source IP address 644 equal to the source IP from the remote five-tuple, and the source 645 port equal to the source port from the remote five-tuple. The 646 destination address and port are set to the contents of the 647 DESTINATION-ADDRESS. The server then sends the UDP packet. Note 648 that any retransmissions of this packet which might be needed are not 649 handled by the server. It is the clients responsibility to generate 650 another Send Request if needed. 652 The server then sets the default destination address to the IP 653 address and port in the DESTINATION-ADDRESS. It also adds the IP 654 address and port from DESTINATION-ADDRESS to the list of permissions 655 associated with this binding. 657 Once the UDP packet is sent, the server generates a Send Response. 658 The Send Response MUST have a message type of "Send Response". The 659 response MUST contain a MAGIC-COOKIE as the first attribute. If the 660 server needs to generate a Send Error Response, that message MUST 661 contain a message type of "Send Error Response", and MUST contain a 662 MAGIC-COOKIE as the first attribute. It MUST contain an ERROR-CODE 663 with the appropriate response code. For UDP, both the Send Response 664 and Send Error Response are sent back to the source IP and port where 665 the request came from, and sent from the same address and port where 666 the request was sent to. 668 7.4 Receiving Packets and Connections 670 If a TURN server receives a TCP connection request on a port it has 671 allocated, the server retrieves the binding whose remote five-tuple 672 has a source address and source port that match the IP address and 673 port to which the connection was made, and whose transport is TCP. 674 If there is not already a TCP connection made to the remote 675 five-tuple, the connection request is accepted. 677 If a TURN server receives a UDP packet on a port it has allocated, 678 the server retrieves the binding whose remote five-tuple has a source 679 address and source port that match the IP address and port to which 680 the packet was sent, and whose transport is UDP. If the source IP 681 address and port of the UDP packet are not listed amongst the set of 682 permissions for the binding, the UDP packet is discarded. Otherwise, 683 if the source IP address and port are listed, but are not equal to 684 the current default IP address and port, the server transmits the 685 packet to the client using a Data Indication message. This is a TURN 686 message that is not retransmitted by the server, and which does not 687 generate a response. As a result, like data packets which are 688 forwarded, there is no reliability guarantee provided by the TURN 689 server for this indication. The Data Indication message MUST contain 690 a DATA attribute whose contents are equal to the payload of the UDP 691 packet. The message MUST contain a SOURCE-ADDRESS attribute whose 692 content is equal to the source IP address and port of the UDP packet 693 received by the TURN server. This packet is sent to the client using 694 the allocate five-tuple. That is, its destination address is equal 695 to the source address from the allocate five-tuple, and its source 696 address is equal to the destination address from the allocate 697 five-tuple. 699 If the packet received on the allocated port has a source IP address 700 and port amongst the permissions for that binding, and that source IP 701 and port is equal to the default IP address and port, the UDP packet 702 is forwarded to the client and not encapsulated in a TURN packet. To 703 forward, the packet is sent with a source IP address and port equal 704 to the destination IP address and port in the allocate five-tuple, 705 and with a destination address and port equal to the source IP 706 address and port in the allocate five-tuple. 708 If a TURN server receives data on a TCP connection that was opened to 709 a port it had allocated, the server MUST forward this data onto the 710 connection associated with allocate-tuple in the binding. 712 If a TURN server receives data on a TCP connection that is associated 713 with an allocate five-tuple, the binding for that tuple is retrieved. 714 If the destination IP address and port of that tuple have not been 715 filled in yet, the data is discarded. If the destination address and 716 port have been filled in, the connection associated with the remote 717 five-tuple is obtained, and the data is forwarded on that connection. 719 Note that, because data is forwarded blindly across TCP bindings, TLS 720 will successfully operate over a TURN allocated TCP port. 722 Similarly, if a TURN server receives a UDP packet on one of its 723 public TURN ports, it checks to see if the source IP address and port 724 match those of the allocate five-tuples in an existing binding. If 725 there is a match, the the UDP packet is not a TURN request (see 726 Section 7.2.3 for details on how this determination is made), the 727 default IP address and port are checked. If they are not set, the 728 UDP packet is discarded. If they are set, the packet is forwarded. 729 It is forwarded using the source IP address and port from the remote 730 five-tuple, and a destination IP address and port equal to the 731 default IP address and port. 733 If a TCP connection associated with an allocate five-tuple is closed, 734 the connection associated with the corresponding remote five-tuple is 735 also closed. At that point, the binding is destroyed. Similarly, if 736 the TCP connection associated with a remote five-tuple is closed, the 737 connection associated with the corresponding allocate five-tuple is 738 closed, and the binding is destroyed. 740 7.5 Lifetime Expiration 742 When the activity timer for a binding fires, the server checks to see 743 if there has been any activity on the binding since its creation, or 744 since the last firing of the timer, whichever is more recent. 745 Activity is defined as connection establishment, or packet 746 transmission in either direction. If there has been activity, the 747 timer is set to fire once again in M seconds, where M is the value of 748 the LIFETIME attribute returned in the most recent Allocate Response 749 for this binding. 751 If there has been no activity, the server MUST destroy the binding, 752 along with its associated one-time password. If the binding was over 753 TCP, the server MUST close any connections it is holding to the 754 client and to the remote client. 756 8. Client Behavior 758 Client behavior is broken into several separate steps. First, the 759 client obtains a one-time username and password. Secondly, it 760 generates initial Allocate Requests, and processes the responses. It 761 manages those addresses (refreshing and tearing them down), issues 762 Send Requests, and processes TURN indications and data received on 763 those addresses. 765 8.1 Discovery 767 Generally, the client will be configured with a domain name of the 768 provider of the TURN servers. This domain name is resolved to an IP 769 address and port of using the SRV procedures [3]. When sending a 770 Shared Secret request, the service name is "turn" and the protocol is 771 "tcp". RFC 2782 spells out the details of how a set of SRV records 772 are sorted and then tried. However, it only states that the client 773 should "try to connect to the (protocol, address, service)" without 774 giving any details on what happens in the event of failure. Those 775 details are described here for TURN. 777 For TURN requests, failure occurs if there is a transport failure of 778 some sort (generally, due to fatal ICMP errors in UDP or connection 779 failures in TCP). Failure also occurs if the the request does not 780 solicit a response after 9.5 seconds. If a failure occurs, the 781 client SHOULD create a new request, which is identical to the 782 previous, but has a different transaction ID and MESSAGE-INTEGRITY 783 attribute. That request is sent to the next element in the list as 784 specified by RFC~2782. 786 8.2 Obtaining a One Time Password 788 In order to allocate addresses, a client must obtain a one-time 789 username and password from the TURN server. A unique username and 790 password are required for each distinct address allocated from the 791 server. 793 To obtain a one-time username and password, the client generates and 794 sends a Shared Secret Request. This is done as described in Section 795 9.2 of STUN. This request will have no attributes, and therefore, 796 based on the processing in Section 7.1, the server will reject it 797 with a Shared Secret Error Response with a 401 response code. That 798 response will contain a NONCE and a REALM. The client SHOULD 799 generate a new Shared Secret Request (with a new transaction ID), 800 which contains the NONCE and REALM attributes copied from the 401 801 response. The request MUST include the USERNAME attribute, which 802 contains a username supplied by the user for the specified realm. 803 The request MUST include a MESSAGE-INTEGRITY attribute as the last 804 attribute. The key for the HMAC is computed as described in Section 805 7.1. 807 If the response (either to the initial request or to the second 808 attempt with the credentials) is a Shared Secret Error Response, the 809 processing depends on the the value of the response code in the 810 ERROR-CODE attribute. If the response code was a 430, the client 811 SHOULD generate a new Shared Secret Request, using the username and 812 password provided by the user, and the REALM and NONCE provided in 813 the 430 response. For a 431 or 436 response code, the client SHOULD 814 alert the user. For a 432, 434 and 435 response codes, if the client 815 had omitted the USERNAME, REALM or NONCE attributes, respectively, 816 from the previous request, it SHOULD retry, this time including the 817 USERNAME, NONCE, REALM, and MESSAGE-INTEGRITY attributes. For a 500 818 response code, the client MAY wait several seconds and then retry the 819 request. For a 600 response code, the client MUST NOT retry the 820 request, and SHOULD display the reason phrase to the user. Unknown 821 attributes between 400 and 499 are treated like a 400, unknown 822 attributes between 500 and 599 are treated like a 500, and unknown 823 attributes between 600 and 699 are treated like a 600. Any response 824 between 100 and 399 MUST result in the cessation of request 825 retransmissions, but otherwise is discarded. 827 If a client receives a Shared Secret Response with an attribute whose 828 type is greater than 0x7fff, the attribute MUST be ignored. If the 829 client receives a Shared Secret Response with an attribute whose type 830 is less than or equal to 0x7fff, the response is ignored. 832 If the response is a Shared Secret Response, it will contain the 833 USERNAME and PASSWORD attributes. The client can use these to 834 authenticate an Allocate Request, as described below. 836 A client MAY send multiple Shared Secret Requests over the same TLS 837 connection, and MAY do so without waiting for responses to previous 838 requests. The client SHOULD close its connection when it has 839 completed allocating usernames and passwords. 841 8.3 Allocating a Binding 843 When a client wishes to obtain a transport address, it sends an 844 Allocate Request to the TURN server. Requests for TCP transport 845 addresses MUST be sent over a TCP connection, and requests for UDP 846 transport addresses MUST be sent over UDP. 848 First, the client obtains a one-time username and password, using the 849 mechanisms described in Section 8.2. The client then formulates an 850 Allocate Request. The request MUST contain a transaction ID, unique 851 for each request, and uniformly and randomly distributed between 0 852 and 2**128 - 1. The message type of the request MUST be "Allocate 853 Request". The length is set as described in Section 11.1 of STUN. 855 The Allocate request MUST contain the MAGIC-COOKIE attribute as the 856 first attribute. 858 The client SHOULD include a BANDWIDTH attribute, which indicates the 859 maximum bandwidth that will be used with this binding. If the 860 maximum is unknown, the attribute is not included in the request. 862 The client MAY request a particular lifetime for the binding by 863 including it in the LIFETIME attribute in the request. If the no 864 data is sent or received on the binding before expiration of the 865 lifetime, the binding will be deleted by the client. 867 The client MUST include a USERNAME attribute, containing a username 868 obtained from a previous Shared Secret Response. The request MUST 869 include a MESSAGE-INTEGRITY attribute as the last attribute. The key 870 is equal to the password obtained from the PASSWORD attribute of the 871 Shared Secret Response. The Allocate Request MUST be sent to the 872 same IP address and port as the Shared Secret Request. This is 873 because one time passwords are expected to be host-specific. Rules 874 for retransmissions for Allocate Requests sent over UDP are identical 875 to those for STUN Binding Requests. Allocate Requests sent over TCP 876 are not retransmitted. Transaction timeouts are identical to those 877 for STUN Binding Requests, independent of the transport protocol. 879 8.4 Processing Allocate Responses 881 If the response is an Allocate Error Response, the client checks the 882 response code from the ERROR-CODE attribute of the response. For a 883 400 response code, the client SHOULD display the reason phrase to the 884 user. For a 420 response code, the client SHOULD retry the request, 885 this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES 886 attribute of the response. For a 430 response code, the client 887 SHOULD obtain a new one-time username and password, and retry the 888 Allocate Request with a new transaction. For 401 and 432 response 889 codes, if the client had omitted the USERNAME or MESSAGE-INTEGRITY 890 attribute as indicated by the error, it SHOULD try again with those 891 attributes. A new one-time username and password is needed in that 892 case. For a 431 response code, the client SHOULD alert the user, and 893 MAY try the request again after obtaining a new username and 894 password. For a 300 response code, the client SHOULD attempt a new 895 TURN transaction to the server indicated in the ALTERNATE-SERVER 896 attribute. For a 500 response code, the client MAY wait several 897 seconds and then retry the request with a new username and password. 898 For a 600 response code, the client MUST NOT retry the request, and 899 SHOULD display the reason phrase to the user. Unknown attributes 900 between 400 and 499 are treated like a 400, unknown attributes 901 between 500 and 599 are treated like a 500, and unknown attributes 902 between 600 and 699 are treated like a 600. Unknown attributes 903 between 300 and 399 are treated like 300. Any response between 100 904 and 299 MUST result in the cessation of any request retransmissions, 905 but otherwise is discarded. 907 If a client receives a response with an attribute whose type is 908 greater than 0x7fff, the attribute MUST be ignored. If the client 909 receives a response with an attribute whose type is less than or 910 equal to 0x7fff, any request retransmissions MUST cease, but the 911 entire response is otherwise ignored. 913 If the response is an Allocate Response, the client MUST check the 914 response for a MESSAGE-INTEGRITY attribute. If not present, the 915 client MUST discard the response. If present, the client computes 916 the HMAC over the response. The key MUST be same as used to compute 917 the MESSAGE-INTEGRITY attribute in the request. If the computed HMAC 918 differs from the one in the response, the client MUST discard the 919 response, and SHOULD alert the user about a possible attack. If the 920 computed HMAC matches the one from the response, processing 921 continues. 923 The MAPPED-ADDRESS in the Binding Response can be used by the client 924 for receiving packets. The server will expire the binding after 925 LIFETIME seconds have passed with no activity. The server will allow 926 the user to send and receive no more than the amount of data 927 indicated in the BANDWIDTH attribute. 929 8.5 Refreshing a Binding 931 If there has been no activity on a UDP binding for a period of time 932 equalling 3/4 of the lifetime of the binding (as conveyed in the 933 LIFETIME attribute of the Allocate Response), the client SHOULD 934 refresh the binding with another Allocate Request if it wishes to 935 keep it. Note that only UDP bindings can be refreshed. For TCP, 936 application-specific keepalives are needed. 938 To perform a refresh, the client generates an Allocate Request as 939 described in Section 8.3. However, the one-time username and 940 password used MUST be the same as those used in the successful 941 Allocate Request for that binding. The client will need to look for 942 the TURN response amongst the data packets using the MAGIC-COOKIE, as 943 described in Section 7.2.3. Processing of that response is as 944 defined in Section 8.4. If the response was an Allocate Response, 945 and the MAPPED-ADDRESS contains the same transport address as 946 previously obtained, the binding has been refreshed. The LIFETIME 947 attribute indicates the amount of additional time the binding will 948 live without activity. If, however, the response was an Allocate 949 Error Response with an ERROR-CODE indicating a 430 response, it means 950 that the binding has expired at the server. The client MAY use the 951 procedures in Section 8.3 to obtain a new binding (this will require 952 a new one-time username and password. Other response codes do not 953 imply that the binding has been expired, just that the refresh has 954 failed. 956 8.6 Sending Data 958 Before receiving any UDP data, a client has to send first. To do 959 that, it uses the Send Request. This request MUST contain a 960 transaction ID, unique for each request, and uniformly and randomly 961 distributed between 0 and 2**128 - 1. The message type of the 962 request MUST be "Send Request". The length is set as described in 963 Section 11.1 of STUN. 965 The Send request MUST contain the MAGIC-COOKIE attribute as the first 966 attribute. The client MUST include a USERNAME attribute, containing 967 the same username used in the Allocate request for this binding. The 968 request MUST include a MESSAGE-INTEGRITY attribute as the last 969 attribute. The key is equal to the password used for the Allocate 970 request for this binding. The Send Request MUST be sent to the same 971 IP address and port as the Allocate Request, and MUST be sent from 972 the same source IP and port used to send the Allocate request for the 973 binding. Rules for retransmissions for Send Requests sent over UDP 974 are identical to those for STUN Binding Requests. There is currently 975 no support for Send Requests over TCP. Transaction timeouts are 976 identical to those for STUN Binding Requests, independent of the 977 transport protocol. 979 The Send Request MUST contain a DESTINATION-ADDRESS attribute, which 980 contains the IP address and port that the data is being sent to. 982 If the server successfully sends the data, the client will receive a 983 Send Response. Note that, as with responses to Allocate refreshes, 984 the client will need to pick the Send Response (or Send Error 985 Response) out of the packet stream by searching for the MAGIC-COOKIE 986 in each received UDP packet. If the response is a Send Error 987 Response, it is processed as described in the first two paragraphs of 988 Section 8.4. If the response code is 438, the client is forbidden 989 from using the Send Request, since lockdown has occurred. The client 990 can relay data to the peer by sending the data without a TURN message 991 wrapper. [[OPEN ISSUE: is there a need for the client to be told 992 what the locked-down address is?]] 994 8.7 Tearing Down a Binding 996 If a client no longer needs a binding, it SHOULD tear it down. For 997 TCP, this is done by closing the connection. For UDP, this is done 998 by performing a refresh, as described in Section 8.5, but with a 999 LIFETIME attribute indicating a time of 0. 1001 8.8 Receiving and Sending Data 1003 Once a binding has been allocated by an Allocate Response, the client 1004 MUST be prepared to receive data from the socket on which the 1005 Allocate Request was sent. For UDP, the client MUST be prepared to 1006 disambiguate TURN messages from data for the lifetime of the binding. 1007 This disambiguation is done using the MAGIC-COOKIE, as described in 1008 Section 7.2.3. 1010 Once a Send request has been issued, the client MAY send data to its 1011 peer by sending data on that same socket. Any UDP packets recieved 1012 by the server are forwarded to the default destination address until 1013 that address is changed by a subsequent Send command. 1015 The client may receive a Data Indication message from the TURN 1016 server. The client does not generate any kind of response to this 1017 message. Its receipt implies that the server received a packet from 1018 a source which is not equal to the current default address. 1020 9. Protocol Details 1022 This section presents the detailed encoding of the message types, 1023 attributes, and response codes which are new to TURN. The general 1024 message structure of TURN is identical to STUN [1]. 1026 9.1 Message Types 1028 TURN defines three new Message Types: 1030 0x0003 : Allocate Request 1031 0x0103 : Allocate Response 1032 0x0113 : Allocate Error Response 1033 0x0004 : Send Request 1034 0x0104 : Send Response 1035 0x0114 : Send Error Response 1036 0x0115 : Data Indication 1038 9.2 Message Attributes 1040 TURN defines the following message attributes: 1042 0x000d: LIFETIME 1043 0x000e: ALTERNATE-SERVER 1044 0x000f: MAGIC-COOKIE 1045 0x0010: BANDWIDTH 1046 0x0011: DESTINATION-ADDRESS 1047 0x0012: SOURCE-ADDRESS 1048 0x0013: DATA 1049 0x0014: NONCE 1051 9.2.1 LIFETIME 1053 The lifetime attribute represents the duration for which the server 1054 will maintain a binding in the absence of data traffic either from or 1055 to the client. It is a 32 bit value representing the number of 1056 seconds remaining until expiration. 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Lifetime | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 9.2.2 ALTERNATE-SERVER 1064 The alternate server represents an alternate IP address and port for 1065 a different TURN server to try. It is encoded in the same way as 1066 MAPPED-ADDRESS. 1068 9.2.3 MAGIC-COOKIE 1070 The MAGIC-COOKIE is used by TURN clients and servers to disambiguate 1071 TURN traffic from data traffic. Its value ix 0x72c64bc6. 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 |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| 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 9.2.4 BANDWIDTH 1079 The bandwidth attribute represents the peak bandwidth, measured in 1080 kbits per second, that the client expects to use on the binding. The 1081 value represents the sum in the receive and send directions. 1082 [[Editors note: Need to define leaky bucket parameters for this.]] 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Bandwidth | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 9.2.5 DESTINATION-ADDRESS 1090 The DESTINATION-ADDRESS is present in Send Requests. It specifies 1091 the address and port where the data is to be sent. It is encoded in 1092 the same way as MAPPED-ADDRESS. 1094 9.2.6 SOURCE-ADDRESS 1096 The SOURCE-ADDRESS is present in Data Indications. It specifies the 1097 address and port from which a packet was received. It is encoded in 1098 the same way as MAPPED-ADDRESS. 1100 9.2.7 DATA 1102 The DATA attribute is present in Send Requests and Data Indications. 1103 It contains raw payload data that is to be sent (in the case of a 1104 Send Request) or was received (in the case of a Data Indication). 1106 9.2.8 NONCE 1108 The NONCE attribute is present in Shared Secret Requests and Shared 1109 Secret Error responses. It contains a sequence of qdtext or 1110 quoted-pair, which are defined in [6]. 1112 9.2.9 Response Codes 1114 TURN defines the following new response codes: 1116 300 (Try Alternate): The client should contact an alternate server 1117 for this request. 1119 434 (Missing Realm): The REALM attribute was not present in the 1120 request. 1122 435 (Missing Nonce): The NONCE attribute was not present in the 1123 request. 1125 436 (Unknown Username): The USERNAME supplied in the Shared Secret 1126 Request is not known in the given REALM. 1128 437 (No Binding): A Send Request was received by the server, but 1129 there is no binding in place for the source 5-tuple. 1131 439 (Illegal Port): A Send Request was received by the server, but 1132 lock-down has already occurred, and sending is disallowed. 1134 10. Security Considerations 1136 TURN servers allocate bandwidth and port resources to clients. 1137 Therefore, a TURN server requires authentication and authorization of 1138 TURN requests. This authentication is provided by a client digest 1139 over TLS, which results in the generation of a one-time password that 1140 is used in a single subsequent Allocate Request. This mechanism 1141 protects against eavesdropping attacks and man-in-the-middle attacks. 1142 The usage of one-time passwords ensures that the Allocate Requests, 1143 which do not run over TLS, are not susceptible to offline dictionary 1144 attacks that can be used to guess the long lived shared secret 1145 between the client and the server. 1147 Because TURN servers allocate resources, they can be susceptible to 1148 denial-of-service attacks. All Allocate Requests are authenticated, 1149 so that an unknown attacker cannot launch an attack. An 1150 authenticated attacker can generate multiple Allocate Requests, but 1151 each requires a new one-time username and password. It is 1152 RECOMMENDED that servers implement a cap on the number of one-time 1153 passwords that are allocated to any specific user at a time (around 5 1154 or 10 should be sufficient). This will prevent floods of Allocate 1155 requests from a single user, in an attempt to use up the resources of 1156 the system. A single malicious user could generate a single Allocate 1157 Request, obtain a binding, and then flood the server with data over 1158 this binding, in an attempt to deny others service. However, this 1159 attack requires the attacker themselves to receive the data being 1160 sent at the server. To ameliorate these kinds of attacks, servers 1161 SHOULD implement a bandwidth cap on each binding (conveyed to the 1162 client in the BANDWIDTH attribute of the Allocate Response), and 1163 discard packets beyond the threshold. 1165 A client will use the transport address learned from the 1166 MAPPED-ADDRESS attribute of the Binding Response to tell other users 1167 how to reach them. Therefore, a client needs to be certain that this 1168 address is valid, and will actually route to them. Such validation 1169 occurs through the TLS and HMAC-based authentication and integrity 1170 checks provided in TURN. They can guarantee the authenticity and 1171 integrity of the mapped addressses. Note that TURN is not 1172 susceptible to the attacks described in Section 12.2.3, 12.2.4, 1173 12.2.5 or 12.2.6 of STUN. These attacks are based on the fact that a 1174 STUN server mirrors the source IP address, which cannot be 1175 authenticated. TURN does not use the source address of the Binding 1176 Request, and therefore, those attacks do not apply. 1178 Confidentiality of the transport addresses learned through TURN does 1179 not appear to be that important, and therefore, this capability is 1180 not provided. 1182 TURN servers are useful even for users not behind a NAT. They can 1183 provide a way for truly anonymous communications. A user can cause a 1184 call to have its media routed through a TURN server, so that the 1185 user's IP addresses are never revealed. 1187 TCP transport addresses allocated by TURN will properly work with TLS 1188 and SSL. However, any addresses allocated by TURN will not operate 1189 properly with IPSec Authentication Header (AH) [10] in transport 1190 mode. IPSec ESP [11] and any tunnel-mode ESP or AH should still 1191 operate. 1193 11. IAB Considerations 1195 The IAB has studied the problem of ``Unilateral Self Address 1196 Fixing'', which is the general process by which a client attempts to 1197 determine its address in another realm on the other side of a NAT 1198 through a collaborative protocol reflection mechanism RFC 3424 [12]. 1199 TURN is an example of a protocol that performs this type of function. 1200 The IAB has mandated that any protocols developed for this purpose 1201 document a specific set of considerations. This section meets those 1202 requirements. 1204 11.1 Problem Definition 1206 From RFC 3424 [12], any UNSAF proposal must provide: 1208 Precise definition of a specific, limited-scope problem that is to 1209 be solved with the UNSAF proposal. A short term fix should not be 1210 generalized to solve other problems; this is why "short term 1211 fixes usually aren't". 1213 The specific problem being solved by TURN is for a client, which may 1214 be located behind a NAT of any type, to obtain an IP address and port 1215 on the public Internet, useful for applications that require a client 1216 to place a transport address into a protocol message, with the 1217 expectation that the client will be able to receive packets from a 1218 single host that will send to this address. Both UDP and TCP are 1219 addressed. It is also possible to send packets so that the recipient 1220 sees a source address equal to the allocated address. TURN, by 1221 design, does not allow a client to run a server (such as a web or 1222 SMTP server) using a TURN address. TURN is useful even when NAT is 1223 not present, to provide anonymity services. 1225 11.2 Exit Strategy 1227 From [12], any UNSAF proposal must provide: 1229 Description of an exit strategy/transition plan. The better short 1230 term fixes are the ones that will naturally see less and less use 1231 as the appropriate technology is deployed. 1233 It is expected that TURN will be useful indefinitely, to provide 1234 anonymity services. When used to facilitate NAT traversal, TURN does 1235 not iself provide an exit strategy. That is provided by the 1236 Interactive Connectivity Establishment (ICE) [13] mechanism. ICE 1237 allows two cooperating clients to interactively determine the best 1238 addresses to use when communicating. ICE uses TURN-allocated 1239 addresses as a last resort, only when no other means of connectivity 1240 exists. As a result, as NATs phase out, and as IPv6 is deployed, ICE 1241 will increasingly use other addresses (host local addresses). 1242 Therefore, clients will allocate TURN addresses, but not use them, 1243 and therefore, de-allocate them. Servers will see a decrease in 1244 usage. Once a provider sees that its TURN servers are not being used 1245 at all (that is, no media flows through them), they can simply remove 1246 them. ICE will operate without TURN-allocated addresses. 1248 11.3 Brittleness Introduced by TURN 1250 From [12], any UNSAF proposal must provide: 1252 Discussion of specific issues that may render systems more 1253 "brittle". For example, approaches that involve using data at 1254 multiple network layers create more dependencies, increase 1255 debugging challenges, and make it harder to transition. 1257 TURN introduces brittleness in a few ways. First, it adds another 1258 server element to any system, which adds another point of failure. 1259 TURN requires clients to demultiplex TURN packets and data based on 1260 hunting for a MAGIC-COOKIE in the TURN messages. It is possible 1261 (with extremely small probabilities) that this cookie could appear 1262 within a data stream, resulting in mis-classification. That might 1263 introduce errors into the data stream (they would appear as lost 1264 packets), and also result in loss of a binding. TURN relies on any 1265 NAT bindings existing for the duration of the bindings held by the 1266 TURN server. Neither the client nor the TURN server have a way of 1267 reliably determining this lifetime (STUN can provide a means, but it 1268 is heuristic in nature and not reliable). Therefore, if there is no 1269 activity on an address learned from TURN for some period, the address 1270 might become useless spontaneously. 1272 TURN will result in potentially significant increases in packet 1273 latencies, and also increases in packet loss probabilities. That is 1274 because it introduces an intermediary on the path of a packet from 1275 point A to B, whose location is determined by application-layer 1276 processing, not underlying routing topologies. Therefore, a packet 1277 sent from one user on a LAN to another on the same LAN may do a trip 1278 around the world before arriving. When combined with ICE, some of 1279 the most problematic cases are avoided (such as this example) by 1280 avoiding the usage of TURN addresses. However, when used, this 1281 problem will exist. 1283 Note that TURN does not suffer from many of the points of brittleness 1284 introduced by STUN. TURN will work with all existing NAT types known 1285 at the time of writing, and for the forseeable future. TURN does not 1286 introduce any topological constraints. TURN does not rely on any 1287 heuristics for NAT type classification. 1289 11.4 Requirements for a Long Term Solution 1291 From [12]}, any UNSAF proposal must provide: 1293 Identify requirements for longer term, sound technical solutions 1294 -- contribute to the process of finding the right longer term 1295 solution. 1297 Our experience with TURN continues to validate our belief in the 1298 requirements outlined in Section 14.4 of STUN. 1300 11.5 Issues with Existing NAPT Boxes 1302 From [12], any UNSAF proposal must provide: 1304 Discussion of the impact of the noted practical issues with 1305 existing, deployed NA[P]Ts and experience reports. 1307 A number of NAT boxes are now being deployed into the market which 1308 try and provide "generic" ALG functionality. These generic ALGs hunt 1309 for IP addresses, either in text or binary form within a packet, and 1310 rewrite them if they match a binding. This will interfere with 1311 proper operation of any UNSAF mechanism, including TURN. However, if 1312 a NAT tries to modify a MAPPED-ADDRESS in a TURN Allocate Response, 1313 this will be detected by the client as an attack. 1315 12. Examples 1317 TODO. 1319 13. References 1321 13.1 Normative References 1323 [1] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 1324 Simple Traversal of User Datagram Protocol (UDP) Through Network 1325 Address Translators (NATs)", RFC 3489, March 2003. 1327 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1328 Levels", BCP 14, RFC 2119, March 1997. 1330 [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1331 specifying the location of services (DNS SRV)", RFC 2782, 1332 February 2000. 1334 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1335 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 1336 Basic and Digest Access Authentication", RFC 2617, June 1999. 1338 13.2 Informative References 1340 [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1341 "RTP: A Transport Protocol for Real-Time Applications", RFC 1342 3550, July 2003. 1344 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1345 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1346 Session Initiation Protocol", RFC 3261, June 2002. 1348 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1349 Protocol", RFC 2327, April 1998. 1351 [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1352 Protocol (RTSP)", RFC 2326, April 1998. 1354 [9] Senie, D., "Network Address Translator (NAT)-Friendly 1355 Application Design Guidelines", RFC 3235, January 2002. 1357 [10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1358 November 1998. 1360 [11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1361 (ESP)", RFC 2406, November 1998. 1363 [12] Daigle, L. and IAB, "IAB Considerations for UNilateral 1364 Self-Address Fixing (UNSAF) Across Network Address 1365 Translation", RFC 3424, November 2002. 1367 [13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1368 Methodology for Network Address Translator (NAT) Traversal for 1369 Multimedia Session Establishment Protocols", 1370 draft-ietf-mmusic-ice-02 (work in progress), July 2004. 1372 Authors' Addresses 1374 Jonathan Rosenberg 1375 Cisco Systems 1376 600 Lanidex Plaza 1377 Parsippany, NJ 07054 1378 US 1380 Phone: +1 973 952-5000 1381 EMail: jdrosen@dynamicsoft.com 1382 URI: http://www.jdrosen.net 1383 Rohan Mahy 1384 Cisco Systems 1385 101 Cooper St 1386 Santa Cruz, CA 95060 1387 US 1389 EMail: rohan@cisco.com 1391 Christian Huitema 1392 Microsoft 1393 One Microsoft Way 1394 Redmond, WA 98052-6399 1395 US 1397 EMail: huitema@microsoft.com 1399 Intellectual Property Statement 1401 The IETF takes no position regarding the validity or scope of any 1402 Intellectual Property Rights or other rights that might be claimed to 1403 pertain to the implementation or use of the technology described in 1404 this document or the extent to which any license under such rights 1405 might or might not be available; nor does it represent that it has 1406 made any independent effort to identify any such rights. Information 1407 on the procedures with respect to rights in RFC documents can be 1408 found in BCP 78 and BCP 79. 1410 Copies of IPR disclosures made to the IETF Secretariat and any 1411 assurances of licenses to be made available, or the result of an 1412 attempt made to obtain a general license or permission for the use of 1413 such proprietary rights by implementers or users of this 1414 specification can be obtained from the IETF on-line IPR repository at 1415 http://www.ietf.org/ipr. 1417 The IETF invites any interested party to bring to its attention any 1418 copyrights, patents or patent applications, or other proprietary 1419 rights that may cover technology that may be required to implement 1420 this standard. Please address the information to the IETF at 1421 ietf-ipr@ietf.org. 1423 Disclaimer of Validity 1425 This document and the information contained herein are provided on an 1426 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1427 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1428 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1429 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1430 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1431 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1433 Copyright Statement 1435 Copyright (C) The Internet Society (2004). This document is subject 1436 to the rights, licenses and restrictions contained in BCP 78, and 1437 except as set forth therein, the authors retain all their rights. 1439 Acknowledgment 1441 Funding for the RFC Editor function is currently provided by the 1442 Internet Society.