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