idnits 2.17.1 draft-rosenberg-midcom-turn-05.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1609. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1625), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** 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 (July 19, 2004) is 7221 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) ** 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) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIDCOM J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: January 17, 2005 R. Mahy 4 Cisco Systems 5 C. Huitema 6 Microsoft 7 July 19, 2004 9 Traversal Using Relay NAT (TURN) 10 draft-rosenberg-midcom-turn-05 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 17, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 Traversal Using Relay NAT (TURN) is a protocol that allows for an 44 element behind a NAT or firewall to receive incoming data over TCP or 45 UDP connections. It is most useful for elements behind symmetric 46 NATs or firewalls that wish to be on the receiving end of a 47 connection to a single peer. TURN does not allow for users to run 48 servers on well known ports if they are behind a nat; it supports the 49 connection of a user behind a nat to only a single peer. In that 50 regard, its role is to provide the same security functions provided 51 by symmetric NATs and firewalls, but to ``turn'' the tables so that 52 the element on the inside can be on the receiving end, rather than 53 the sending end, of a connection that is requested by the client. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Applicability Statement . . . . . . . . . . . . . . . . . . 7 61 5. Overview of Operation . . . . . . . . . . . . . . . . . . . 8 62 6. Message Overview . . . . . . . . . . . . . . . . . . . . . . 10 63 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . 11 64 7.1 Shared Secret Request . . . . . . . . . . . . . . . . . . 11 65 7.2 Allocate Request . . . . . . . . . . . . . . . . . . . . . 13 66 7.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 13 67 7.2.2 Initial Requests . . . . . . . . . . . . . . . . . . . 13 68 7.2.3 Requests for Pre-Allocated Ports . . . . . . . . . . . 17 69 7.2.4 Subsequent Requests . . . . . . . . . . . . . . . . . 18 70 7.3 Send Request . . . . . . . . . . . . . . . . . . . . . . . 19 71 7.4 Receiving Packets and Connections . . . . . . . . . . . . 20 72 7.5 Lifetime Expiration . . . . . . . . . . . . . . . . . . . 22 73 8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . 23 74 8.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 23 75 8.2 Obtaining a One Time Password . . . . . . . . . . . . . . 23 76 8.3 Allocating a Binding . . . . . . . . . . . . . . . . . . . 24 77 8.4 Processing Allocate Responses . . . . . . . . . . . . . . 25 78 8.5 Allocating a Pre-Allocated Binding . . . . . . . . . . . . 26 79 8.6 Refreshing a Binding . . . . . . . . . . . . . . . . . . . 27 80 8.7 Sending Data . . . . . . . . . . . . . . . . . . . . . . . 27 81 8.8 Tearing Down a Binding . . . . . . . . . . . . . . . . . . 28 82 8.9 Receiving and Sending Data . . . . . . . . . . . . . . . . 28 83 9. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 30 84 9.1 Message Types . . . . . . . . . . . . . . . . . . . . . . 30 85 9.2 Message Attributes . . . . . . . . . . . . . . . . . . . . 30 86 9.2.1 TRANSPORT-PREFERENCES . . . . . . . . . . . . . . . . 30 87 9.2.2 LIFETIME . . . . . . . . . . . . . . . . . . . . . . . 31 88 9.2.3 ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . 31 89 9.2.4 MAGIC-COOKIE . . . . . . . . . . . . . . . . . . . . . 31 90 9.2.5 BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . 32 91 9.2.6 DESTINATION-ADDRESS . . . . . . . . . . . . . . . . . 32 92 9.2.7 SOURCE-ADDRESS . . . . . . . . . . . . . . . . . . . . 32 93 9.2.8 DATA . . . . . . . . . . . . . . . . . . . . . . . . . 32 94 9.2.9 NONCE . . . . . . . . . . . . . . . . . . . . . . . . 32 95 9.2.10 Response Codes . . . . . . . . . . . . . . . . . . . 32 96 10. Security Considerations . . . . . . . . . . . . . . . . . . 34 97 11. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 36 98 11.1 Problem Definition . . . . . . . . . . . . . . . . . . . 36 99 11.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . 36 100 11.3 Brittleness Introduced by TURN . . . . . . . . . . . . . 37 101 11.4 Requirements for a Long Term Solution . . . . . . . . . 37 102 11.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . 38 103 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 104 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 105 13.1 Normative References . . . . . . . . . . . . . . . . . . . 40 106 13.2 Informative References . . . . . . . . . . . . . . . . . . 40 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 108 Intellectual Property and Copyright Statements . . . . . . . 42 110 1. Introduction 112 Network Address Translators (NATs), while providing many benefits, 113 also come with many drawbacks. The most troublesome of those 114 drawbacks is the fact that they break many existing IP applications, 115 and make it difficult to deploy new ones. Guidelines [9] have been 116 developed that describe how to build "NAT friendly" protocols, but 117 many protocols simply cannot be constructed according to those 118 guidelines. Examples of such protocols include multimedia 119 applications and file sharing. 121 Simple Traversal of UDP Through NAT (STUN) [1] provides one means for 122 an application to traverse a NAT. STUN allows a client to obtain a 123 transport address (and IP address and port) which may be useful for 124 receiving packets from a peer. However, addresses obtained by STUN 125 may not be usable by all peers. Those addresses work depending on 126 the topological conditions of the network. Therefore, STUN by itself 127 cannot provide a complete solution for NAT traversal. 129 A complete solution requires a means by which a client can obtain a 130 transport address from which it can receive media from any peer which 131 can send packets to the public Internet. This can only be 132 accomplished by relaying data though a server that resides on the 133 public Internet. This specification describes Traversal Using Relay 134 NAT (TURN), a protocol that allows a client to obtain IP addresses 135 and ports from such a relay. 137 Although TURN will almost always provide connectivity to a client, it 138 comes at high cost to the provider of the TURN server. It is 139 therefore desirable to use TURN as a last resort only, preferring 140 other mechanisms (such as STUN or direct connectivity) when possible. 141 To accomplish that, the Interactive Connectivity Establishment (ICE) 142 [13] methodology can be used to discover the optimal means of 143 connectivity. 145 2. Terminology 147 In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, 148 SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to 149 be interpreted as described in RFC 2119 [2] and indicate requirement 150 levels for compliant TURN implementations. 152 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 STUN 158 client with IP addresses that route to it from the public 159 Internet. 160 TURN Server: A TURN Server (also just referred to as a server) is 161 an entity that receives TURN requests, and sends TURN responses. 162 The server is capable of acting as a data relay, receiving data on 163 the address it provides to clients, and forwarding them to the 164 clients. 165 Transport Address: An IP address and port. 167 4. Applicability Statement 169 TURN is useful for applications that require a client to place a 170 transport address into a protocol message, with the expectation that 171 the client will be able to receive packets from a single host that 172 will send to this address. Examples of such protocols include SIP, 173 which makes use of the Session Description Protocol (SDP) [7]. SDP 174 carries and IP address on which the client will receive media packets 175 from its peer. Another example of a protocol meeting this criteria 176 is the Real Time Streaming Protocol (RTSP) [8]. 178 When a client is behind a NAT, transport addresses obtained from the 179 local operating system will not be publically routable, and 180 therefore, not useful in these protocols. TURN allows a client to 181 obtain a transport address, from a server on the public Internet, 182 which can be used in protocols meeting the above criteria. However, 183 the transport addresses obtained from TURN servers are not generally 184 useful for receiving data from anywhere. They are only useful for 185 communicating with a single peer. Once a host sends packets to that 186 transport address, it is ``locked down'', meaning that the client 187 cannot cause packets to be sent to that host through the relay. The 188 client will still receive packets sent from different peers to that 189 transport address, but these are wrapped in TURN protocol headers, 190 reducing their efficiency. This is done purposefully, so as to 191 prevent TURN from being used to run servers (such as a web server or 192 DNS server) on a client behind a NAT. In this way, enterprises which 193 deploy NATs and firewalls to prevent users from running servers, can 194 be confident that TURN will not cause any violations in their 195 enterprise security policies. 197 5. Overview of Operation 199 The typical TURN configuration is shown in Figure 1. A TURN client 200 is connected to private network 1. This network connects to private 201 network 2 through NAT 1. Private network 2 connects to the public 202 Internet through NAT 2. On the public Internet is a TURN server. 204 /-----\ 205 // TURN \\ 206 | Server | 207 \\ // 208 \-----/ 210 +--------------+ Public Internet 211 ................| NAT 2 |....................... 212 +--------------+ 214 +--------------+ Private NET 2 215 ................| NAT 1 |....................... 216 +--------------+ 218 /-----\ 219 // TURN \\ 220 | Client | 221 \\ // Private NET 1 222 \-----/ 224 Figure 1 226 TURN is a simple client-server protocol. It is identical in syntax 227 and general operation to STUN, in order to facilitate a joint 228 implementation of both. TURN defines a request message, called 229 Allocate, which asks for a public IP address and port. TURN can run 230 over UDP and TCP, as it allows for a client to request address/port 231 pairs for receiving both UDP and TCP. 233 A TURN client first discovers the address of a TURN server. This can 234 be preconfigured, or it can be discovered using SRV records [3] This 235 will allow for different TURN servers for UDP and TCP. Once a TURN 236 server is discovered, the client sends a TURN Allocate request to the 237 TURN server. TURN provides a mechanism for mutual authentication and 238 integrity checks for both requests and responses, based on a shared 239 secret. Assuming the request is authenticated and has not been 240 tampered with, the TURN server remembers the source transport address 241 that the request came from (call this SA), and returns a public 242 transport address, PA, in the TURN response. The TURN server is 243 responsible for guaranteeing that packets sent to PA route to the 244 TURN server. The TURN server then waits for data on PA. When data 245 is received (either a UDP packet or a TCP connection request), the 246 TURN server accepts the connection (in the case of TCP), and then 247 stores the remote address and port where the data came from (RA). 248 The data just received, if any, are then forwarded to SA. The TURN 249 server then acts as a relay. Any data received from SA are forwarded 250 to RA. Any data sent from RA to PA are sent to SA. If some other 251 host sends packets to PA, those packets are forwarded to PA as well, 252 but they are sent as a TURN message from the server to the client. 253 This affords some protection against denial of service attacks that 254 would otherwise be possible. TURN also allows a client to send 255 packets through the TURN server before lockdown has occurred, by 256 using the SEND command. 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 TURN also allows a client to request an odd or even port when one is 271 allocated, and for it to pre-allocate the next higher port. This is 272 useful for securing consecutive ports for usage with the Real Time 273 Transport Protocol (RTP) [5]. 275 6. Message Overview 277 TURN messages are identical to STUN messages in their syntax. TURN 278 defines several new messages - the Allocate Request, the Allocate 279 Response, the Allocate Error Response, the Send Request, the Send 280 Response, the Send Error Response and the Data Indication. TURN also 281 uses the Shared Secret Request, Shared Secret Response, and Shared 282 Secret Error Response defined by STUN. TURN makes use of some of the 283 STUN attributes (MAPPED-ADDRESS, USERNAME, MESSAGE-INTEGRITY, 284 ERROR-CODE, and UNKNOWN-ATTRIBUTES) and also defines several of its 285 own. Specifically, TURN adds TRANSPORT-PREFERENCES attribute, which 286 allows a client to request an odd or even port, and to pre-allocate 287 the next higher port. It defines the LIFETIME attribute, which 288 allows the TURN server to tell the client when the binding will be 289 released. It defines the MAGIC-COOKIE attribute, which allows the 290 TURN client to find TURN messages in a stream of UDP packets. It 291 defines the BANDWIDTH attribute, which allows a client to inform the 292 server of the expected bandwidth usage on the connection. Finally, 293 it defines the ALTERNATE-SERVER attribute, which allows the server to 294 redirect the TURN client to connect to an alternate server. 296 7. Server Behavior 298 The server behavior depends on whether the request is a Shared Secret 299 Request or an Allocate Request. 301 7.1 Shared Secret Request 303 Unlike a STUN server, a TURN server provides resources to clients 304 that connect to it. Therefore, only authorized clients can gain 305 access to a TURN server. This requires that TURN requests be 306 authenticated. TURN assumes the existence of a long-lived shared 307 secret between the client and the TURN server in order to achieve 308 this authentication. The client uses this long-lived shared secret 309 to authenticate itself in a Shared Secret Request, sent over TLS. 310 The Shared Secret Response provides the client with a one-time 311 username and password. This one-time credential is then used by the 312 server to authenticate an Allocate Request. The usage of a separate 313 long lived and one-time credentials prevents dictionary attacks, 314 whereby an observer of a message and its HMAC could guess the 315 password by an offline dictionary search. 317 When a TURN server receives a Shared Secret Request, it first 318 executes the processing described in the first three paragraphs of 319 Section 8.2 of STUN. This processing will ensure that the Shared 320 Secret Request is received over TLS. 322 Assuming it was, the server checks the Shared Secret Request for a 323 MESSAGE-INTEGRITY attribute. If not present, the server generates a 324 Shared Secret Error Response with an ERROR-CODE attribute with 325 response code 401. That response MUST include a NONCE attribute, 326 containing a nonce that the server wishes the client to reflect back 327 in a subsequent Shared Secret Request (and therefore include the 328 message integrity computation). The response MUST include a REALM 329 attribute, containing a realm from which the username and password 330 are scoped [4]. 332 If the MESSAGE-INTEGRITY attribute was present, the server checks for 333 the existence of the REALM attribute. If the attribute is not 334 present, the server MUST generate a Shared Secret Error Response. 335 That response MUST include an ERROR-CODE attribute with response code 336 434. That response MUST include a NONCE and a REALM attribute. 338 If the REALM attribute was present, the server checks for the 339 existence of the NONCE attribute. If the NONCE attribute is not 340 present, the server MUST generate a Shared Secret Error Response. 341 That response MUST include an ERROR-CODE attribute with response code 342 435. That response MUST include a NONCE attribute and a REALM 343 attribute. 345 If the NONCE attribute was present, the server checks for the 346 existence of the USERNAME attribute. If it was not present, the 347 server MUST generate a Shared Secret Error Response. The Shared 348 Secret Error Response MUST include an ERROR-CODE attribute with 349 response code 432. It MUST include a NONCE attribute and a REALM 350 attribute. 352 If the USERNAME is present, the server computes the HMAC over the 353 request as described in Section 11.2.8 of STUN. The key is computed 354 as MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" passwd), where 355 the password is the password associated with the username and realm 356 provided in the request. If the server does not have a record for 357 that username within that realm, the server generates a Shared Secret 358 Error Response. That response MUST include an ERROR-CODE attribute 359 with response code 436. That response MUST include a NONCE attribute 360 and a REALM attribute. 361 This format for the key was chosen so as to enable a common 362 authentication database for SIP and for TURN, as it is expected 363 that credentials are usually stored in their hashed forms. 365 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 366 attribute in the request, the server MUST generate a Shared Secret 367 Error Response with an ERROR-CODE attribute with response code 431. 368 This response MUST include a NONCE attribute and a REALM attribute. 370 If the computed HMAC doesn't differ from the one in the request, but 371 the nonce is stale, the server MUST generate a Shared Secret Error 372 Response. That response MUST include an ERROR-CODE attribute with 373 response code 430. That response MUST include a NONCE attribute and 374 a REALM attribute. 376 In all cases, the Shared Secret Error Response is sent over the TLS 377 connection on which the Shared Secret Request was received. 379 The server proceeds to authorize the client. The means for 380 authorization are outside the scope of this specification. It is 381 anticipated that TURN servers will be run by providers that also 382 provide an application service, such as SIP or RTSP. In that case, a 383 user would be authorized to use TURN if they are authorized to use 384 the application service. 386 The server then generates a Shared Secret Response as in Section 8.2 387 of STUN. This response will contain a USERNAME and PASSWORD, which 388 are used by the client as a short-term shared secret in subsequent 389 Allocate requests. Note that STUN specifies that the server has to 390 invalidate this username and password after 30 minutes. This is not 391 the case in TURN. In TURN, the server MUST store the allocated 392 username and password for a duration of at least 30 minutes. Once an 393 Allocate request has been authenticated using that username and 394 password, if the result was an Allocate Error Response, the username 395 and password are discarded. If the result was an Allocate Response, 396 resulting in the creation of a new binding, the username and password 397 become associated with that binding. They can only be used to 398 authenticate Allocate requests sent from the same source transport 399 address in order to refresh or de-allocate that binding. Once the 400 binding is deleted, the username and password are discarded. 402 This policy avoids replay attacks, whereby a recorded Allocate 403 request is replayed in order to obtain a binding without proper 404 authentication. It also ensures that existing bindings can be 405 refreshed without needed to continuously obtain one-time passwords 406 from the TURN server. 408 7.2 Allocate Request 410 7.2.1 Overview 412 Allocate requests are used to obtain an IP address and port that the 413 client can use to receive UDP and TCP packets from any host on the 414 network, even when the client is behind a symmetric NAT. To do this, 415 a TURN server allocates a local transport address, and passes it to 416 the client in an Allocate Response. When the server receives packets 417 on this allocated address, it acts as a relay, and forwards them 418 towards the source of the Allocate request. The server remembers the 419 source transport address where that packet came from, and "locks 420 down". This means that packets sent from the client to the TURN 421 server are forwarded to that address. 423 As a result, the server maintains a set of bindings. These bindings 424 are associations between the five-tuple of received Allocate requests 425 (source IP address and port, destination IP address and port, and 426 protocol), called the allocate five-tuple, and another five tuple, 427 called the remote five-tuple. 429 The behavior of the server when receiving an Allocate Request depends 430 on whether the request is an initial one, or a subsequent one. An 431 initial request is one received with a source transport address which 432 is not associated with any existing bindings. A subsequent request 433 is one received that is associated with an existing binding. 435 7.2.2 Initial Requests 437 A TURN server MUST be prepared to receive Binding Requests over TCP 438 and UDP. The port on which to listen is based on the DNS SRV entries 439 provided by the server. Typically, this will be XXXX, the default 440 TURN port. 442 The server MUST check the Allocate Request for a MESSAGE-INTEGRITY 443 attribute. If not present, the server generates a Allocate Error 444 Response with an ERROR-CODE attribute with response code 401. 446 If the MESSAGE-INTEGRITY attribute was present, the server checks for 447 the existence of the USERNAME attribute. If it was not present, the 448 server MUST generate a Allocate Error Response. The Allocate Error 449 Response MUST include an ERROR-CODE attribute with response code 432. 451 If the USERNAME is present, the server computes the HMAC over the 452 request as described in Section 11.2.8 of STUN. The key is equal to 453 the password associated with the username in the request, where that 454 username is a short term username allocated by the TURN server. The 455 username MUST be one which has been allocated by the server in a 456 Shared Secret Response, but has not yet been used to authenticate an 457 Allocate request. If that username is not known by the server, or 458 has already been used, the server generates an Allocate Error 459 Response. That response MUST include an ERROR-CODE attribute with 460 response code 430. 462 If the computed HMAC differs from the one from the MESSAGE-INTEGRITY 463 attribute in the request, the server MUST generate a Allocate Error 464 Response with an ERROR-CODE attribute with response code 431. 466 Assuming the message integrity check passed, processing continues. 467 The server MUST check for any attributes in the request with values 468 less than or equal to 0x7fff which it does not understand. If it 469 encounters any, the server MUST generate an Allocate Error Response, 470 and it MUST include an ERROR-CODE attribute with a 420 response code. 472 That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing 473 the attributes with values less than or equal to 0x7fff which were 474 not understood. 476 If the Allocate request arrived over TCP, the Allocate Error Response 477 is sent on the connection from which the request arrived. If the 478 Allocate request arrived over UDP, the Allocate Error Response is 479 sent to the transport address from which the request was received 480 (i.e., the source IP address and port), and sent from the transport 481 address on which the request was received (i.e., the destination IP 482 address and port). 484 Assuming the Allocate request was authenticated and was well-formed, 485 the server attempts to allocate transport addresses. It first looks 486 for the BANDWIDTH attribute for the request. If present, the server 487 determines whether or not it has sufficient capacity to handle a 488 binding that will generate the requested bandwidth. If so, the 489 server looks for the presence of the TRANSPORT-PREFERENCES attribute 490 in the request. If the attribute indicates that an even port is 491 requested, the server attempts to allocate a transport address with 492 an even port. If the attribute indicates that an odd port is 493 requested, the server attempts to allocate a transport address with 494 an odd port. If the attribute indicates that there is no preference 495 for port parity, or if the TRANSPORT-PREFERENCES attribute was 496 absent, the server attempts to allocate a port with either parity. 497 The server MUST NOT allocate ports from the well-known port range 498 (0-1023) and MUST NOT allocate ports from the user registered port 499 range (1024 through 49151). 500 This aspect of the protocol helps guarantee that users cannot run 501 servers (such as a web server, SIP server, or SMTP server) using 502 TURN. 504 The TRANSPORT-PREFERENCES attribute can also indicate a preference 505 for a specific address and port, pre-allocated previously by a prior 506 Allocate request. This case is described in Section 7.2.3. 508 If a port meeting the constraints (including bandwidth) cannot be 509 allocated, the server MUST generate a Allocate Error Response that 510 includes an ERROR-CODE attribute with a response code of 300. That 511 response MAY include an ALTERNATE-SERVER attribute pointing to an 512 alternate server which can be used by the client. 514 Assuming a port was allocated according to the preferences (call this 515 the base port), the server checks to see if the TRANSPORT-PREFERENCES 516 attribute is present, and indicates a desire to pre-allocate the next 517 higher port (called the pre-allocated port). If so, the server 518 attempts to allocate that port from its local operating system. If 519 it cannot be allocated, the server can do one of two things. First, 520 it MAY try to allocate a different base port, in the hopes that the 521 next higher port is available. If the server believes that there are 522 no adjacent ports meeting the parity constraints present in the 523 request, the server MAY generate an Allocate Error Response that 524 includes an ERROR-CODE attribute with a response code of 300. That 525 response MAY include an ALTERNATE-SERVER attribute pointing to an 526 alternate server which can be used by the client. 528 Once a base port is allocated, the server creates a binding for it. 529 This binding is a mapping between two five-tuples - the allocate 530 five-tuple and the remote five-tuple. The allocate five-tuple is set 531 to the five-tuple of the Allocate Request (that is, the protocol of 532 the allocate five-tuple is set to the protocol of the Allocate 533 Request (TCP or UDP), the source IP address and port of the allocate 534 five-tuple are set to the source IP address and port in the Allocate 535 Request, and the destination IP address and port of the allocate 536 five-tuple are set to the destination IP address and port in the 537 Allocate Request). The protocol in the remote five-tuple is set to 538 the protocol from the Allocate Request. The source IP address of the 539 remote five-tuple is set to the interface from which the base port 540 was allocated. The source port of the remote five-tuple is set to 541 the base port. If the binding was allocated for TCP, the connection 542 on which the Allocate request was received is associated with the 543 allocate five-tuple in the binding. 545 The server MUST remember the one-time username and password used to 546 obtain the binding. 548 If an address and port was pre-allocated (either at the request or 549 the user, or the at the discretion of the server), a binding is also 550 created for it. The allocate five-tuple is left empty. The protocol 551 in the remote five-tuple is set to the protocol from the Allocate 552 Request. The source IP address of the remote five-tuple is set to 553 the interface from which the pre-allocated port was allocated. The 554 source port of the remote five-tuple is set to the pre-allocated 555 port. The identity of the user (defined as the username provided in 556 the Shared Secret Request used to obtain the one-time password used 557 in the Allocate Request) is associated with this pre-allocated tuple. 558 Only that user can perform an allocation for this tuple. 559 Furthermore, a timer is set. If no allocation is made against this 560 pre-allocation within 5 minutes, the port is released and the binding 561 is deleted. 563 If the LIFETIME attribute was present in the request, and the value 564 is larger than the maximum duration the server is willing to use for 565 the lifetime of the binding, the server MAY lower it to that maximum. 566 However, the server MUST NOT increase the duration requested in the 567 LIFETIME attribute. If there was no LIFETIME attribute, the server 568 may choose a default duration at its discretion. In either cae, the 569 resulting duration is added to the current time, and a timer is set 570 to fire at or after that time. Section 7.5 discusses behavior when 571 the timer fires. 573 Once the base port has been obtained from the operating system, the 574 pre-allocated port obtained, and the activity timer started for the 575 base port binding, the server generates an Allocate Response. The 576 Allocate Response MUST contain the same transaction ID contained in 577 the Allocate Request. The length in the message header MUST contain 578 the total length of the message in bytes, excluding the header. The 579 Allocate Response MUST have a message type of "Allocate Response". 581 The server MUST add a MAPPED-ADDRESS attribute to the Allocate 582 Response. The IP address component of this attribute MUST be set to 583 the interface from which the base port was allocated. The port 584 component of this attribute MUST be set to the base port. 586 The server MUST add a LIFETIME attribute to the Allocate Response. 587 This attribute contains the duration, in seconds, of the activity 588 timer associated with this binding. 590 The server MUST add a BANDWIDTH attribute to the Allocate Response. 591 This MUST be equal to the attribute from the request, if one was 592 present. Otherwise, it indicates a per-binding cap that the server 593 is placing on the bandwidth usage on each binding. Such caps are 594 needed to prevent against denial-of-service attacks (See Section 10. 596 The server MUST add, as the final attribute of the request, a 597 MESSAGE-INTEGRITY attribute. The key used in the HMAC MUST be the 598 same as that used to validate the request. 600 The TURN server then sends the response. If the Allocate request was 601 received over TCP, the response is sent over that TCP connection. 602 Once the response is sent, the TURN server begins acting as a relay 603 for that connection (see Section 7.4). If the Allocate request was 604 received over UDP, the response is sent to the transport address from 605 which the request was received (i.e., the source IP address and 606 port), and sent from the transport address on which the request was 607 received (i.e., the destination IP address and port). 609 Additionally, if the base port was for UDP, the server MUST be 610 prepared to receive UDP packets once the TURN response is sent. If 611 the base port was for TCP, the server MUST be prepared to receive a 612 TCP connection request on that port. Behavior when either occurs is 613 described in Section 7.4. 615 7.2.3 Requests for Pre-Allocated Ports 617 The TRANSPORT-PREFERENCES attribute of the Allocate Request can 618 indicate a desire to allocate a port that was previously 619 pre-allocated by a prior Allocate request. If such an indication is 620 present, the server checks that this address and port has been 621 pre-allocated by a previous Allocate Request. The only user 622 authorized to allocate a pre-allocated address is the same one that 623 generated the pre-allocation. Note that the one-time usernames for 624 both requests (the pre-allocation and the final allocation) will be 625 different. However, both MUST have been obtained through Shared 626 Secret Requests authenticated as being sent from the same user. 628 If the Allocate request arrives on a different protocol than was used 629 to make the pre-allocation, the server MUST send an Allocate Error 630 Response. That response MUST contain an ERROR-CODE attribute with a 631 response code of 400. 633 Assuming the requested port has been pre-allocated by the same user, 634 the server completes the allocation by setting the allocate 635 five-tuple for the binding to be equal to that of the Allocate 636 request. The server sets the activity timer for this binding, and 637 generates an Allocate Response. This response MUST contain a 638 MAPPED-ADDRESS attribute which contains the interface from which the 639 pre-allocated port was obtained, along with the pre-allocated port. 640 The response MUST contain a LIFETIME attribute and a 641 MESSAGE-INTEGRITY attribute as well. 643 7.2.4 Subsequent Requests 645 Once a binding has been created, non-TURN packets received from the 646 client are generally forwarded to the remote client. However, if the 647 binding is UDP, the client can send subsequent Allocate requests to 648 the TURN server. To determine which packets are for the TURN server, 649 and which need to be relayed, the server looks at the packet. If the 650 packet is shorter than 28 bytes, it is not a TURN request. If it is 651 longer than 28 bytes, the server checks bytes 25-28. If these bytes 652 are equal to the MAGIC-COOKIE, the request is a TURN request. 653 Otherwise, it is a data packet, and is to be relayed. 655 The server first authenticates the request. This is done as in 656 Section 7.2.2. The request MUST be authenticated using the same 657 one-time username and password used to allocate that binding 658 previously. That is, the five-tuple from the Allocate request is 659 compared to the allocate five-tuples in existing bindings. The 660 matching binding is selected. The one-time username and password 661 associated with that binding MUST match the ones used in the request. 663 Any TRANSPORT-PREFERENCE attribute in the request is ignored. An 664 Allocate Request sent to an existing binding is always a refresh or 665 deallocation. The server looks for the LIFETIME attribute in the 666 Allocate Request. If not found, it determines the default refresh 667 duration, in seconds, for this binding. If the LIFETIME attribute 668 was present in the request, and the value is larger than the maximum 669 duration the server is willing to extend the lifetime of the binding, 670 the server MAY lower it to that maximum. However, the server MUST 671 NOT increase the duration requested in the LIFETIME attribute. The 672 resulting duration is added to the current time, and the activity 673 timer for this binding is reset to fire at or after that time. 674 Section 7.5 discusses behavior when the timer fires. 676 Once the timer is set, the server MUST generate an Allocate Response. 677 The Allocate Response MUST contain the same transaction ID contained 678 in the Allocate Request. The length in the message header MUST 679 contain the total length of the message in bytes, excluding the 680 header. The Allocate Response MUST have a message type of "Allocate 681 Response". The response MUST contain a MAGIC-COOKIE as the first 682 attribute. It MUST contain a MAPPED-ADDRESS which contains the 683 source IP address and port from the remote five-tuple of the binding. 684 It MUST contain a LIFETIME attribute which contains the time from now 685 until the point at which the binding will be deleted. The final 686 attribute MUST be a MESSAGE-INTEGRITY attribute, which MUST use the 687 same one-time username and password used to authenticate the request. 689 The TURN server then sends the response. If the Allocate request was 690 received over TCP, the response is sent over that TCP connection. If 691 the Allocate request was received over UDP, the response is sent to 692 the transport address from which the request was received (i.e., the 693 source IP address and port), and sent from the transport address on 694 which the request was received (i.e., the destination IP address and 695 port). 697 7.3 Send Request 699 In some networks, enterprise firewall policies prevent users from 700 sending packets directly out to the public Internet. A TURN server 701 can act as a relay for packets sent by a client in such a network. 702 However, the TURN server can only relay packets once the remote 703 five-tuple has been fully filled in with an incoming packet, a 704 process called "locking down". Many applications will require a user 705 to send a packet first in order to trigger such an incoming packet. 706 These initial packets must also be relayed. To provide this 707 capability, TURN supports the Send Request. 709 The Send request asks the TURN server to forward a data packet to a 710 specified IP address and port. A Send Request is like any other TURN 711 request. A server can disambiguate a Send Request from a data packet 712 by looking for the MAGIC-COOKIE attribute, as described in Section 713 7.2.4. 715 Once the server has identified a request as a Send request, the 716 server verifies that it has arrived with a source five-tuple 717 corresponding to an existing allocation. If there is no matching 718 allocation, the server MUST generate a 437 (No Binding) Send Error 719 Response. If there is a matching allocation, the server checks if 720 the remote 5-tuple for the binding has been filled in (i.e., 721 lock-down has occurred). If it has, the server MUST generate a 438 722 (Sending Disallowed) Send Error Response. 724 Next, the server authenticates the request. This is done as in 725 Section 7.2.2. The request MUST be authenticated using the same 726 one-time username and password used to allocate that binding 727 previously. That is, the five-tuple from the Send request is 728 compared to the allocate five-tuples in existing bindings. The 729 matching binding is selected. The one-time username and password 730 associated with that binding MUST match the ones used in the request. 732 Once the request has been authenticated, the server validates it. 733 The request should contain a DESTINATION-ADDRESS attribute and a DATA 734 attribute. If it doesn't, the server MUST reject the request with a 735 400 (Bad Request) Send Error Response. If the value of the port from 736 the DESTINATION-ADDRESS is between 0 and 1023 inclusive, the server 737 MUST reject the request with a 439 (Illegal Port) Send Error 738 Response. 740 Assuming the Send Request has been validated, the server then takes 741 the contents of the DATA attribute, and creates a UDP packet whose 742 payload equals that content. The server sets the source IP address 743 equal to the source IP from the remote five-tuple, and the source 744 port equal to the source port from the remote five-tuple. The 745 destination address and port are set to the contents of the 746 DESTINATION-ADDRESS. The server then sends the UDP packet. Note 747 that any retransmissions of this packet which might be needed are not 748 handled by the server. It is the clients responsibility to generate 749 another Send Request if needed. 751 Once the UDP packet is sent, the server generates a Send Response. 752 The Send Response MUST have a message type of "Send Response". The 753 response MUST contain a MAGIC-COOKIE as the first attribute. If the 754 server needs to generate a Send Error Response, that message MUST 755 contain a message type of "Send Error Response", and MUST contain a 756 MAGIC-COOKIE as the first attribute. It MUST contain an ERROR-CODE 757 with the appropriate response code. For UDP, both the Send Response 758 and Send Error Response are sent back to the source IP and port where 759 the request came from, and sent from the same address and port where 760 the request was sent to. 762 7.4 Receiving Packets and Connections 764 If a TURN server receives a TCP connection request on a port it has 765 allocated, the server retrieves the binding whose remote five-tuple 766 has a source address and source port that match the IP address and 767 port to which the connection was made, and whose transport is TCP. 768 If the destination IP address and port of the remote five-tuple in 769 the binding are already filled in (which means that a connection was 770 already made to this tuple), the connection request is rejected. 771 Otherwise, it is accepted. If the connection is accepted, the server 772 MUST set the destination IP address and port of the remote five-tuple 773 to the source IP address and port in the SYN packet. It also 774 associates this connection with the remote five-tuple. 776 If a TURN server receives a UDP packet on a port it has allocated, 777 the server retrieves the binding whose remote five-tuple has a source 778 address and source port that match the IP address and port to which 779 the packet was sent, and whose transport is UDP. If the destination 780 IP address and port of the remote five-tuple in the binding are 781 already filled in, and do not match the source IP address and port of 782 the UDP packet, the server transmits the packet to the client using a 783 Data Indication message. This is a TURN message that is not 784 retransmitted by the server, and which does not generate a response. 785 As a result, like data packets which are forwarded, there is no 786 reliability guarantee provided by the TURN server for this 787 indication. The Data Indication message MUST contain a DATA 788 attribute whose contents are equal to the payload of the UDP packet. 789 The message MUST contain a SOURCE-ADDRESS attribute whose content is 790 equal to the source IP address and port of the UDP packet received by 791 the TURN server. This packet is sent to the client using the 792 allocate five-tuple. That is, its destination address is equal to 793 the source address from the allocate five-tuple, and its source 794 address is equal to the destination address from the allocate 795 five-tuple. 797 If the packet was not sent as a Data Indication message, it is 798 forwarded. To forward, the packet is sent with a source IP address 799 and port equal to the destination IP address and port in the allocate 800 five-tuple, and with a destination address and port equal to the 801 source IP address and port in the allocate five-tuple. If the 802 destination address and port of the remote five-tuple were not filled 803 in, they are populated at this time. The server MUST set the 804 destination IP address and port of the remote five-tuple to the 805 source IP address and port in the UDP packet. Note that, unlike a 806 Data Indication message, when the packet is forwarded, the payload of 807 the transmitted packet is identical to the one received. No headers 808 are added to the packet. 810 The process of filling in the destination IP address and port of the 811 remote five-tuple is called "locking down". Once done, the client 812 can only send and receive packets with the specific peer from which 813 the first packet or connection was received. 815 If a TURN server receives data on a TCP connection that was opened to 816 a port it had allocated, the server MUST forward this data onto the 817 connection associated with allocate-tuple in the binding. 819 If a TURN server receives data on a TCP connection that is associated 820 with an allocate five-tuple, the binding for that tuple is retrieved. 821 If the destination IP address and port of that tuple have not been 822 filled in yet, the data is discarded. If the destination address and 823 port have been filled in, the connection associated with the remote 824 five-tuple is obtained, and the data is forwarded on that connection. 826 Note that, because data is forwarded blindly across TCP bindings, TLS 827 will successfully operate over a TURN allocated TCP port. 829 Similarly, if a TURN server receives a UDP packet on one of its 830 public TURN ports, it checks to see if the source IP address and port 831 match those of the allocate five-tuples in an existing binding. If 832 there is a match, the the UDP packet is not a TURN request (see 833 Section 7.2.4 for details on how this determination is made), the 834 destination IP address and port in the remote five-tuple of the 835 binding are checked. If they are not filled in yet, the UDP packet 836 is discarded. If they are, the packet is forwarded. It is forwarded 837 using the source IP address and port from the remote five-tuple, and 838 a destination IP address and port from the remote five-tuple. 840 If a TCP connection associated with an allocate five-tuple is closed, 841 the connection associated with the corresponding remote five-tuple is 842 also closed. At that point, the binding is destroyed. Similarly, if 843 the TCP connection associated with a remote five-tuple is closed, the 844 connection associated with the corresponding allocate five-tuple is 845 closed, and the binding is destroyed. 847 7.5 Lifetime Expiration 849 When the activity timer for a binding fires, the server checks to see 850 if there has been any activity on the binding since its creation, or 851 since the last firing of the timer, whichever is more recent. 852 Activity is defined as connection establishment, or packet 853 transmission in either direction. If there has been activity, the 854 timer is set to fire once again in M seconds, where M is the value of 855 the LIFETIME attribute returned in the most recent Allocate Response 856 for this binding. 858 If there has been no activity, the server MUST destroy the binding, 859 along with its associated one-time password. If the binding was over 860 TCP, the server MUST close any connections it is holding to the 861 client and to the remote client. 863 8. Client Behavior 865 Client behavior is broken into several separate steps. First, the 866 client obtains a one-time username and password. Secondly, it 867 generates initial Allocate Requests, and processes the responses. It 868 manages those addresses (refreshing and tearing them down), issues 869 Send Requests, and processes TURN indications and data received on 870 those addresses. 872 8.1 Discovery 874 Generally, the client will be configured with a domain name of the 875 provider of the TURN servers. This domain name is resolved to an IP 876 address and port of using the SRV procedures [3]. When sending a 877 Shared Secret request, the service name is "turn" and the protocol is 878 "tcp". RFC 2782 spells out the details of how a set of SRV records 879 are sorted and then tried. However, it only states that the client 880 should "try to connect to the (protocol, address, service)" without 881 giving any details on what happens in the event of failure. Those 882 details are described here for TURN. 884 For TURN requests, failure occurs if there is a transport failure of 885 some sort (generally, due to fatal ICMP errors in UDP or connection 886 failures in TCP). Failure also occurs if the the request does not 887 solicit a response after 9.5 seconds. If a failure occurs, the 888 client SHOULD create a new request, which is identical to the 889 previous, but has a different transaction ID and MESSAGE-INTEGRITY 890 attribute. That request is sent to the next element in the list as 891 specified by RFC~2782. 893 8.2 Obtaining a One Time Password 895 In order to allocate addresses, a client must obtain a one-time 896 username and password from the TURN server. A unique username and 897 password are required for each distinct address allocated from the 898 server. 900 To obtain a one-time username and password, the client generates and 901 sends a Shared Secret Request. This is done as described in Section 902 9.2 of STUN. This request will have no attributes, and therefore, 903 based on the processing in Section 7.1, the server will reject it 904 with a Shared Secret Error Response with a 401 response code. That 905 response will contain a NONCE and a REALM. The client SHOULD 906 generate a new Shared Secret Request (with a new transaction ID), 907 which contains the NONCE and REALM attributes copied from the 401 908 response. The request MUST include the USERNAME attribute, which 909 contains a username supplied by the user for the specified realm. 910 The request MUST include a MESSAGE-INTEGRITY attribute as the last 911 attribute. The key for the HMAC is computed as described in Section 912 7.1. 914 If the response (either to the initial request or to the second 915 attempt with the credentials) is a Shared Secret Error Response, the 916 processing depends on the the value of the response code in the 917 ERROR-CODE attribute. If the response code was a 430, the client 918 SHOULD generate a new Shared Secret Request, using the username and 919 password provided by the user, and the REALM and NONCE provided in 920 the 430 response. For a 431 or 436 response code, the client SHOULD 921 alert the user. For a 432, 434 and 435 response codes, if the client 922 had omitted the USERNAME, REALM or NONCE attributes, respectively, 923 from the previous request, it SHOULD retry, this time including the 924 USERNAME, NONCE, REALM, and MESSAGE-INTEGRITY attributes. For a 500 925 response code, the client MAY wait several seconds and then retry the 926 request. For a 600 response code, the client MUST NOT retry the 927 request, and SHOULD display the reason phrase to the user. Unknown 928 attributes between 400 and 499 are treated like a 400, unknown 929 attributes between 500 and 599 are treated like a 500, and unknown 930 attributes between 600 and 699 are treated like a 600. Any response 931 between 100 and 399 MUST result in the cessation of request 932 retransmissions, but otherwise is discarded. 934 If a client receives a Shared Secret Response with an attribute whose 935 type is greater than 0x7fff, the attribute MUST be ignored. If the 936 client receives a Shared Secret Response with an attribute whose type 937 is less than or equal to 0x7fff, the response is ignored. 939 If the response is a Shared Secret Response, it will contain the 940 USERNAME and PASSWORD attributes. The client can use these to 941 authenticate an Allocate Request, as described below. 943 A client MAY send multiple Shared Secret Requests over the same TLS 944 connection, and MAY do so without waiting for responses to previous 945 requests. The client SHOULD close its connection when it has 946 completed allocating usernames and passwords. 948 8.3 Allocating a Binding 950 When a client wishes to obtain a transport address, it sends an 951 Allocate Request to the TURN server. Requests for TCP transport 952 addresses MUST be sent over a TCP connection, and requests for UDP 953 transport addresses MUST be sent over UDP. 955 First, the client obtains a one-time username and password, using the 956 mechanisms described in Section 8.2. The client then formulates an 957 Allocate Request. The request MUST contain a transaction ID, unique 958 for each request, and uniformly and randomly distributed between 0 959 and 2**128 - 1. The message type of the request MUST be ``Allocate 960 Request''. The length is set as described in Section 11.1 of STUN. 962 The Allocate request MUST contain the MAGIC-COOKIE attribute as the 963 first attribute. If the client wishes to allocate an odd or even 964 port, it can do so by including the TRANSPORT-PREFERENCES attribute 965 in the request. That attribute can also be used by the client if it 966 wishes to pre-allocate the port one higher. 968 The client SHOULD include a BANDWIDTH attribute, which indicates the 969 maximum bandwidth that will be used with this binding. If the 970 maximum is unknown, the attribute is not included in the request. 972 The client MAY request a particular lifetime for the binding by 973 including it in the LIFETIME attribute in the request. If the no 974 data is sent or received on the binding before expiration of the 975 lifetime, the binding will be deleted by the client. 977 The client MUST include a USERNAME attribute, containing a username 978 obtained from a previous Shared Secret Response. The request MUST 979 include a MESSAGE-INTEGRITY attribute as the last attribute. The key 980 is equal to the password obtained from the PASSWORD attribute of the 981 Shared Secret Response. The Allocate Request MUST be sent to the 982 same IP address and port as the Shared Secret Request. This is 983 because one time passwords are expected to be host-specific. Rules 984 for retransmissions for Allocate Requests sent over UDP are identical 985 to those for STUN Binding Requests. Allocate Requests sent over TCP 986 are not retransmitted. Transaction timeouts are identical to those 987 for STUN Binding Requests, independent of the transport protocol. 989 8.4 Processing Allocate Responses 991 If the response is an Allocate Error Response, the client checks the 992 response code from the ERROR-CODE attribute of the response. For a 993 400 response code, the client SHOULD display the reason phrase to the 994 user. For a 420 response code, the client SHOULD retry the request, 995 this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES 996 attribute of the response. For a 430 response code, the client 997 SHOULD obtain a new one-time username and password, and retry the 998 Allocate Request with a new transaction. For 401 and 432 response 999 codes, if the client had omitted the USERNAME or MESSAGE-INTEGRITY 1000 attribute as indicated by the error, it SHOULD try again with those 1001 attributes. A new one-time username and password is needed in that 1002 case. For a 431 response code, the client SHOULD alert the user, and 1003 MAY try the request again after obtaining a new username and 1004 password. For a 300 response code, the client SHOULD attempt a new 1005 TURN transaction to the server indicated in the ALTERNATE-SERVER 1006 attribute. For a 500 response code, the client MAY wait several 1007 seconds and then retry the request with a new username and password. 1008 For a 600 response code, the client MUST NOT retry the request, and 1009 SHOULD display the reason phrase to the user. Unknown attributes 1010 between 400 and 499 are treated like a 400, unknown attributes 1011 between 500 and 599 are treated like a 500, and unknown attributes 1012 between 600 and 699 are treated like a 600. Unknown attributes 1013 between 300 and 399 are treated like 300. Any response between 100 1014 and 299 MUST result in the cessation of any request retransmissions, 1015 but otherwise is discarded. 1017 If a client receives a response with an attribute whose type is 1018 greater than 0x7fff, the attribute MUST be ignored. If the client 1019 receives a response with an attribute whose type is less than or 1020 equal to 0x7fff, any request retransmissions MUST cease, but the 1021 entire response is otherwise ignored. 1023 If the response is an Allocate Response, the client MUST check the 1024 response for a MESSAGE-INTEGRITY attribute. If not present, the 1025 client MUST discard the response. If present, the client computes 1026 the HMAC over the response. The key MUST be same as used to compute 1027 the MESSAGE-INTEGRITY attribute in the request. If the computed HMAC 1028 differs from the one in the response, the client MUST discard the 1029 response, and SHOULD alert the user about a possible attack. If the 1030 computed HMAC matches the one from the response, processing 1031 continues. 1033 The MAPPED-ADDRESS in the Binding Response can be used by the client 1034 for receiving packets. The server will expire the binding after 1035 LIFETIME seconds have passed with no activity. The server will allow 1036 the user to send and receive no more than the amount of data 1037 indicated in the BANDWIDTH attribute. 1039 8.5 Allocating a Pre-Allocated Binding 1041 If the initial Allocate Request included TRANSPORT-PREFERENCES that 1042 indicated a desire to pre-allocate the port one-higher, the client 1043 MAY allocate that port at a later time. It MUST do so within 4 1044 minutes of receiving the Allocate Response, or the pre-allocated port 1045 will expire. 1047 To allocate the port, the client generates an Allocate Request as 1048 described in Section 8.3. A new username and password MUST be used 1049 for this allocation. The request MUST contain a 1050 TRANSPORT-PREFERENCES attribute. It MUST indicate an explicit 1051 interface and port, whose value is one higher than the port number 1052 returned in the prior Allocate Response. 1054 Processing of the responses is identical to Section 8.4. However, 1055 the client SHOULD explicitly check that received packets are TURN 1056 responses, as opposed to data packets, using the techniques described 1057 in Section 7.2.4. 1059 8.6 Refreshing a Binding 1061 If there has been no activity on a UDP binding for a period of time 1062 equalling 3/4 of the lifetime of the binding (as conveyed in the 1063 LIFETIME attribute of the Allocate Response), the client SHOULD 1064 refresh the binding with another Allocate Request if it wishes to 1065 keep it. Note that only UDP bindings can be refreshed. For TCP, 1066 application-specific keepalives are needed. 1068 To perform a refresh, the client generates an Allocate Request as 1069 described in Section 8.3. However, the one-time username and 1070 password used MUST be the same as those used in the successful 1071 Allocate Request for that binding. The client will need to look for 1072 the TURN response amongst the data packets using the MAGIC-COOKIE, as 1073 described in Section 7.2.4. Processing of that response is as 1074 defined in Section 8.4. If the response was an Allocate Response, 1075 and the MAPPED-ADDRESS contains the same transport address as 1076 previously obtained, the binding has been refreshed. The LIFETIME 1077 attribute indicates the amount of additional time the binding will 1078 live without activity. If, however, the response was an Allocate 1079 Error Response with an ERROR-CODE indicating a 430 response, it means 1080 that the binding has expired at the server. The client MAY use the 1081 procedures in Section 8.3 to obtain a new binding (this will require 1082 a new one-time username and password. Other response codes do not 1083 imply that the binding has been expired, just that the refresh has 1084 failed. 1086 8.7 Sending Data 1088 Before lockdown has occured, a client MAY send data using a binding 1089 it has allocated from the TURN server. To do that, it formulates a 1090 Send Request. This request MUST contain a transaction ID, unique for 1091 each request, and uniformly and randomly distributed between 0 and 1092 2**128 - 1. The message type of the request MUST be "Send Request". 1093 The length is set as described in Section 11.1 of STUN. 1095 The Send request MUST contain the MAGIC-COOKIE attribute as the first 1096 attribute. The client MUST include a USERNAME attribute, containing 1097 the same username used in the Allocate request for this binding. The 1098 request MUST include a MESSAGE-INTEGRITY attribute as the last 1099 attribute. The key is equal to the password used for the Allocate 1100 request for this binding. The Send Request MUST be sent to the same 1101 IP address and port as the Allocate Request, and MUST be sent from 1102 the same source IP and port used to send the Allocate request for the 1103 binding. Rules for retransmissions for Send Requests sent over UDP 1104 are identical to those for STUN Binding Requests. There is currently 1105 no support for Send Requests over TCP. Transaction timeouts are 1106 identical to those for STUN Binding Requests, independent of the 1107 transport protocol. 1109 The Send Request MUST contain a DESTINATION-ADDRESS attribute, which 1110 contains the IP address and port that the data is being sent to. A 1111 client MUST NOT specify a port below 1024, as the server will reject 1112 such requests. This prevents TURN from being used as a relay to 1113 launch DoS attacks against well-known services. The Send Request 1114 MUST contain a DATA attribute, whose contents are the data to 1115 transmit. 1117 If the server successfully sends the data, the client will receive a 1118 Send Response. Note that, as with responses to Allocate refreshes, 1119 the client will need to pick the Send Response (or Send Error 1120 Response) out of the packet stream by searching for the MAGIC-COOKIE 1121 in each received UDP packet. If the response is a Send Error 1122 Response, it is processed as described in the first two paragraphs of 1123 Section 8.4. If the response code is 438, the client is forbidden 1124 from using the Send Request, since lockdown has occurred. The client 1125 can relay data to the peer by sending the data without a TURN message 1126 wrapper. [[OPEN ISSUE: is there a need for the client to be told 1127 what the locked-down address is?]] 1129 8.8 Tearing Down a Binding 1131 If a client no longer needs a binding, it SHOULD tear it down. For 1132 TCP, this is done by closing the connection. For UDP, this is done 1133 by performing a refresh, as described in Section 8.6, but with a 1134 LIFETIME attribute indicating a time of 0. 1136 8.9 Receiving and Sending Data 1138 Once a binding has been allocated by an Allocate Response, the client 1139 MUST be prepared to receive data from the socket on which the 1140 Allocate Request was sent. For UDP, the client MUST be prepared to 1141 disambiguate TURN messages from data for the lifetime of the binding. 1142 This disambiguation is done using the MAGIC-COOKIE, as described in 1143 Section 7.2.4. 1145 Once data has been received, the client MAY send data to its peer by 1146 sending data on that same socket. Sending data on the socket before 1147 data is received will cause the data to be discarded by the server. 1149 The client may receive a Data Indication message from the TURN 1150 server. The client does not generate any kind of response to this 1151 message. Its receipt implies that a packet from a second peer has 1152 been received after lock-down. This specification does not define 1153 any particular treatment to data received in such an indication. 1154 However, in many cases, it can be a sign of a potential 1155 denial-of-service attack against the client. If the client believes 1156 that it should not be receiving data from any other source, it SHOULD 1157 terminate the binding. 1159 9. Protocol Details 1161 This section presents the detailed encoding of the message types, 1162 attributes, and response codes which are new to TURN. The general 1163 message structure of TURN is identical to STUN [1]. 1165 9.1 Message Types 1167 TURN defines three new Message Types: 1169 0x0003 : Allocate Request 1170 0x0103 : Allocate Response 1171 0x0113 : Allocate Error Response 1172 0x0004 : Send Request 1173 0x0104 : Send Response 1174 0x0114 : Send Error Response 1175 0x0115 : Data Indication 1177 9.2 Message Attributes 1179 TURN defines the following message attributes: 1181 0x000c: TRANSPORT-PREFERENCES 1182 0x000d: LIFETIME 1183 0x000e: ALTERNATE-SERVER 1184 0x000f: MAGIC-COOKIE 1185 0x0010: BANDWIDTH 1186 0x0011: DESTINATION-ADDRESS 1187 0x0012: SOURCE-ADDRESS 1188 0x0013: DATA 1189 0x0014: NONCE 1191 9.2.1 TRANSPORT-PREFERENCES 1193 The TRANSPORT-PREFERENCES attribute indicates preferences for the 1194 ports allocated by the TURN server. It is either 32 or 96 bits long, 1195 depending on the value of the Typ bits. These bits indicate the 1196 preferences for the allocated port: 1198 0b00: no preferences 1199 0b01: odd port parity 1200 0b10: even port parity 1201 0b11: allocate a pre-allocated port 1202 When the Typ bits are 0b11, the following 64 bits encode the 1203 pre-allocated transport address. They are in the same format used 1204 for MAPPED-ADDRESS. 1206 The P bit indicates a desire for pre-allocating the port one-higher. 1207 If 1, it means pre-allocation is desired. This bit MUST NOT be set 1208 to 1 if the Typ bits are 0b11. That is, pre-allocation cannot be 1209 done again when allocating a previously pre-allocated port. 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | 0 |P|Typ| 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 |x x x x x x x x| Family | Port | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Address | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 9.2.2 LIFETIME 1221 The lifetime attribute represents the duration for which the server 1222 will maintain a binding in the absence of data traffic either from or 1223 to the client. It is a 32 bit value representing the number of 1224 seconds remaining until expiration. 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | Lifetime | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 9.2.3 ALTERNATE-SERVER 1232 The alternate server represents an alternate IP address and port for 1233 a different TURN server to try. It is encoded in the same way as 1234 MAPPED-ADDRESS. 1236 9.2.4 MAGIC-COOKIE 1238 The MAGIC-COOKIE is used by TURN clients and servers to disambiguate 1239 TURN traffic from data traffic. Its value ix 0x72c64bc6. 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 |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| 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 9.2.5 BANDWIDTH 1247 The bandwidth attribute represents the peak bandwidth, measured in 1248 kbits per second, that the client expects to use on the binding. The 1249 value represents the sum in the receive and send directions. 1250 [[Editors note: Need to define leaky bucket parameters for this.]] 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Bandwidth | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 9.2.6 DESTINATION-ADDRESS 1258 The DESTINATION-ADDRESS is present in Send Requests. It specifies 1259 the address and port where the data is to be sent. It is encoded in 1260 the same way as MAPPED-ADDRESS. 1262 9.2.7 SOURCE-ADDRESS 1264 The SOURCE-ADDRESS is present in Data Indications. It specifies the 1265 address and port from which a packet was received. It is encoded in 1266 the same way as MAPPED-ADDRESS. 1268 9.2.8 DATA 1270 The DATA attribute is present in Send Requests and Data Indications. 1271 It contains raw payload data that is to be sent (in the case of a 1272 Send Request) or was received (in the case of a Data Indication). 1274 9.2.9 NONCE 1276 The NONCE attribute is present in Shared Secret Requests and Shared 1277 Secret Error responses. It contains a sequence of qdtext or 1278 quoted-pair, which are defined in [6]. 1280 9.2.10 Response Codes 1282 TURN defines the following new response codes: 1283 300 (Try Alternate): The client should contact an alternate server 1284 for this request. 1285 434 (Missing Realm): The REALM attribute was not present in the 1286 request. 1287 435 (Missing Nonce): The NONCE attribute was not present in the 1288 request. 1289 436 (Unknown Username): The USERNAME supplied in the Shared Secret 1290 Request is not known in the given REALM. 1292 437 (No Binding): A Send Request was received by the server, but 1293 there is no binding in place for the source 5-tuple. 1294 438 (Sending Disallowed): A Send Request was received by the 1295 server, but lock-down has already occurred, and sending is 1296 disallowed. 1297 439 (Illegal Port): A Send Request was received by the server, but 1298 lock-down has already occurred, and sending is disallowed. 1300 10. Security Considerations 1302 TURN servers allocate bandwidth and port resources to clients. 1303 Therefore, a TURN server requires authentication and authorization of 1304 TURN requests. This authentication is provided by a client digest 1305 over TLS, which results in the generation of a one-time password that 1306 is used in a single subsequent Allocate Request. This mechanism 1307 protects against eavesdropping attacks and man-in-the-middle attacks. 1308 The usage of one-time passwords ensures that the Allocate Requests, 1309 which do not run over TLS, are not susceptible to offline dictionary 1310 attacks that can be used to guess the long lived shared secret 1311 between the client and the server. 1313 Because TURN servers allocate resources, they can be susceptible to 1314 denial-of-service attacks. All Allocate Requests are authenticated, 1315 so that an unknown attacker cannot launch an attack. An 1316 authenticated attacker can generate multiple Allocate Requests, but 1317 each requires a new one-time username and password. It is 1318 RECOMMENDED that servers implement a cap on the number of one-time 1319 passwords that are allocated to any specific user at a time (around 5 1320 or 10 should be sufficient). This will prevent floods of Allocate 1321 requests from a single user, in an attempt to use up the resources of 1322 the system. A single malicious user could generate a single Allocate 1323 Request, obtain a binding, and then flood the server with data over 1324 this binding, in an attempt to deny others service. However, this 1325 attack requires the attacker themselves to receive the data being 1326 sent at the server. To ameliorate these kinds of attacks, servers 1327 SHOULD implement a bandwidth cap on each binding (conveyed to the 1328 client in the BANDWIDTH attribute of the Allocate Response), and 1329 discard packets beyond the threshold. 1331 A client will use the transport address learned from the 1332 MAPPED-ADDRESS attribute of the Binding Response to tell other users 1333 how to reach them. Therefore, a client needs to be certain that this 1334 address is valid, and will actually route to them. Such validation 1335 occurs through the TLS and HMAC-based authentication and integrity 1336 checks provided in TURN. They can guarantee the authenticity and 1337 integrity of the mapped addressses. Note that TURN is not 1338 susceptible to the attacks described in Section 12.2.3, 12.2.4, 1339 12.2.5 or 12.2.6 of STUN. These attacks are based on the fact that a 1340 STUN server mirrors the source IP address, which cannot be 1341 authenticated. TURN does not use the source address of the Binding 1342 Request, and therefore, those attacks do not apply. 1344 Confidentiality of the transport addresses learned through TURN does 1345 not appear to be that important, and therefore, this capability is 1346 not provided. 1348 TURN servers are useful even for users not behind a NAT. They can 1349 provide a way for truly anonymous communications. A user can cause a 1350 call to have its media routed through a TURN server, so that the 1351 user's IP addresses are never revealed. 1353 TCP transport addresses allocated by TURN will properly work with TLS 1354 and SSL. However, any addresses allocated by TURN will not operate 1355 properly with IPSec Authentication Header (AH) [10] in transport 1356 mode. IPSec ESP [11] and any tunnel-mode ESP or AH should still 1357 operate. 1359 Once a binding is locked down by the receipt of a packet, a client is 1360 prohibited from using the binding to send packets anywhere else. If 1361 an eavesdropper had observed a packet containing a TURN allocated 1362 address, it can transmit a packet to this address in an attempt to 1363 cause lock-down. This will prohibit a legitimate user from 1364 communicating with the client on that address. This particular 1365 attack is most easily prevented by ensuring that confidentiality is 1366 provided in any protocols that are used to transport a TURN binding. 1367 However, in a variant of this attack, a malicious client may flood a 1368 TURN server with UDP packets over a wide port range, in an attempt to 1369 cause lock-down on any bindings which were just allocated. This 1370 attack cannot be prevent with confidentiality mechanisms within other 1371 protocols. Fortunately, this attack is expensive to launch. Because 1372 the server provides no positive indications of lock-down, an attacker 1373 will need to be flooding continously without any indication of 1374 success. Furthermore, the rate of packets sent to any particular 1375 port needs to be very high - on the order of one every second or so - 1376 since there is a limited window of opportunity for locking down 1377 before a legitimate client sends a packet to the binding and causes 1378 lock-down. This attack can also be detected by clients. They will 1379 still receive the legitimate packets through the TURN Data 1380 Indications. In many cases, a client will be able to disambiguate 1381 the legitimate ones from those from the attacker. If it determines 1382 an attack is in progress, it can terminate the binding and retry. 1384 11. IAB Considerations 1386 The IAB has studied the problem of ``Unilateral Self Address 1387 Fixing'', which is the general process by which a client attempts to 1388 determine its address in another realm on the other side of a NAT 1389 through a collaborative protocol reflection mechanism RFC 3424 [12]. 1390 TURN is an example of a protocol that performs this type of function. 1391 The IAB has mandated that any protocols developed for this purpose 1392 document a specific set of considerations. This section meets those 1393 requirements. 1395 11.1 Problem Definition 1397 From RFC 3424 [12], any UNSAF proposal must provide: 1398 Precise definition of a specific, limited-scope problem that is to 1399 be solved with the UNSAF proposal. A short term fix should not be 1400 generalized to solve other problems; this is why "short term 1401 fixes usually aren't". 1403 The specific problem being solved by TURN is for a client, which may 1404 be located behind a NAT of any type, to obtain an IP address and port 1405 on the public Internet, useful for applications that require a client 1406 to place a transport address into a protocol message, with the 1407 expectation that the client will be able to receive packets from a 1408 single host that will send to this address. Both UDP and TCP are 1409 addressed. It is also possible to send packets so that the recipient 1410 sees a source address equal to the allocated address. TURN, by 1411 design, does not allow a client to run a server (such as a web or 1412 SMTP server) using a TURN address. TURN is useful even when NAT is 1413 not present, to provide anonymity services. 1415 11.2 Exit Strategy 1417 From [12], any UNSAF proposal must provide: 1418 Description of an exit strategy/transition plan. The better short 1419 term fixes are the ones that will naturally see less and less use 1420 as the appropriate technology is deployed. 1422 It is expected that TURN will be useful indefinitely, to provide 1423 anonymity services. When used to facilitate NAT traversal, TURN does 1424 not iself provide an exit strategy. That is provided by the 1425 Interactive Connectivity Establishment (ICE) [13] mechanism. ICE 1426 allows two cooperating clients to interactively determine the best 1427 addresses to use when communicating. ICE uses TURN-allocated 1428 addresses as a last resort, only when no other means of connectivity 1429 exists. As a result, as NATs phase out, and as IPv6 is deployed, ICE 1430 will increasingly use other addresses (host local addresses). 1431 Therefore, clients will allocate TURN addresses, but not use them, 1432 and therefore, de-allocate them. Servers will see a decrease in 1433 usage. Once a provider sees that its TURN servers are not being used 1434 at all (that is, no media flows through them), they can simply remove 1435 them. ICE will operate without TURN-allocated addresses. 1437 11.3 Brittleness Introduced by TURN 1439 From [12], any UNSAF proposal must provide: 1440 Discussion of specific issues that may render systems more 1441 "brittle". For example, approaches that involve using data at 1442 multiple network layers create more dependencies, increase 1443 debugging challenges, and make it harder to transition. 1445 TURN introduces brittleness in a few ways. First, it adds another 1446 server element to any system, which adds another point of failure. 1447 TURN requires clients to demultiplex TURN packets and data based on 1448 hunting for a MAGIC-COOKIE in the TURN messages. It is possible 1449 (with extremely small probabilities) that this cookie could appear 1450 within a data stream, resulting in mis-classification. That might 1451 introduce errors into the data stream (they would appear as lost 1452 packets), and also result in loss of a binding. TURN relies on any 1453 NAT bindings existing for the duration of the bindings held by the 1454 TURN server. Neither the client nor the TURN server have a way of 1455 reliably determining this lifetime (STUN can provide a means, but it 1456 is heuristic in nature and not reliable). Therefore, if there is no 1457 activity on an address learned from TURN for some period, the address 1458 might become useless spontaneously. 1460 TURN will result in potentially significant increases in packet 1461 latencies, and also increases in packet loss probabilities. That is 1462 because it introduces an intermediary on the path of a packet from 1463 point A to B, whose location is determined by application-layer 1464 processing, not underlying routing topologies. Therefore, a packet 1465 sent from one user on a LAN to another on the same LAN may do a trip 1466 around the world before arriving. When combined with ICE, some of 1467 the most problematic cases are avoided (such as this example) by 1468 avoiding the usage of TURN addresses. However, when used, this 1469 problem will exist. 1471 Note that TURN does not suffer from many of the points of brittleness 1472 introduced by STUN. TURN will work with all existing NAT types known 1473 at the time of writing, and for the forseeable future. TURN does not 1474 introduce any topological constraints. TURN does not rely on any 1475 heuristics for NAT type classification. 1477 11.4 Requirements for a Long Term Solution 1479 From [12]}, any UNSAF proposal must provide: 1481 Identify requirements for longer term, sound technical solutions 1482 -- contribute to the process of finding the right longer term 1483 solution. 1485 Our experience with TURN continues to validate our belief in the 1486 requirements outlined in Section 14.4 of STUN. 1488 11.5 Issues with Existing NAPT Boxes 1490 From [12], any UNSAF proposal must provide: 1491 Discussion of the impact of the noted practical issues with 1492 existing, deployed NA[P]Ts and experience reports. 1494 A number of NAT boxes are now being deployed into the market which 1495 try and provide "generic" ALG functionality. These generic ALGs hunt 1496 for IP addresses, either in text or binary form within a packet, and 1497 rewrite them if they match a binding. This will interfere with 1498 proper operation of any UNSAF mechanism, including TURN. However, if 1499 a NAT tries to modify a MAPPED-ADDRESS in a TURN Allocate Response, 1500 this will be detected by the client as an attack. 1502 12. Examples 1504 TODO. 1506 13. References 1508 13.1 Normative References 1510 [1] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 1511 Simple Traversal of User Datagram Protocol (UDP) Through Network 1512 Address Translators (NATs)", RFC 3489, March 2003. 1514 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1515 Levels", BCP 14, RFC 2119, March 1997. 1517 [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1518 specifying the location of services (DNS SRV)", RFC 2782, 1519 February 2000. 1521 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1522 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 1523 Basic and Digest Access Authentication", RFC 2617, June 1999. 1525 13.2 Informative References 1527 [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1528 "RTP: A Transport Protocol for Real-Time Applications", RFC 1529 3550, July 2003. 1531 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1532 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1533 Session Initiation Protocol", RFC 3261, June 2002. 1535 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1536 Protocol", RFC 2327, April 1998. 1538 [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1539 Protocol (RTSP)", RFC 2326, April 1998. 1541 [9] Senie, D., "Network Address Translator (NAT)-Friendly 1542 Application Design Guidelines", RFC 3235, January 2002. 1544 [10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1545 November 1998. 1547 [11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1548 (ESP)", RFC 2406, November 1998. 1550 [12] Daigle, L. and IAB, "IAB Considerations for UNilateral 1551 Self-Address Fixing (UNSAF) Across Network Address 1552 Translation", RFC 3424, November 2002. 1554 [13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1555 Methodology for Nettwork Address Translator (NAT) Traversal 1556 for the Session Initiation Protocol (SIP)", 1557 draft-rosenberg-sipping-ice-01 (work in progress), July 2003. 1559 Authors' Addresses 1561 Jonathan Rosenberg 1562 dynamicsoft 1563 600 Lanidex Plaza 1564 Parsippany, NJ 07054 1565 US 1567 Phone: +1 973 952-5000 1568 EMail: jdrosen@dynamicsoft.com 1569 URI: http://www.jdrosen.net 1571 Rohan Mahy 1572 Cisco Systems 1573 101 Cooper St 1574 Santa Cruz, CA 95060 1575 US 1577 EMail: rohan@cisco.com 1579 Christian Huitema 1580 Microsoft 1581 One Microsoft Way 1582 Redmond, WA 98052-6399 1583 US 1585 EMail: huitema@microsoft.com 1587 Intellectual Property Statement 1589 The IETF takes no position regarding the validity or scope of any 1590 Intellectual Property Rights or other rights that might be claimed to 1591 pertain to the implementation or use of the technology described in 1592 this document or the extent to which any license under such rights 1593 might or might not be available; nor does it represent that it has 1594 made any independent effort to identify any such rights. Information 1595 on the procedures with respect to rights in RFC documents can be 1596 found in BCP 78 and BCP 79. 1598 Copies of IPR disclosures made to the IETF Secretariat and any 1599 assurances of licenses to be made available, or the result of an 1600 attempt made to obtain a general license or permission for the use of 1601 such proprietary rights by implementers or users of this 1602 specification can be obtained from the IETF on-line IPR repository at 1603 http://www.ietf.org/ipr. 1605 The IETF invites any interested party to bring to its attention any 1606 copyrights, patents or patent applications, or other proprietary 1607 rights that may cover technology that may be required to implement 1608 this standard. Please address the information to the IETF at 1609 ietf-ipr@ietf.org. 1611 Disclaimer of Validity 1613 This document and the information contained herein are provided on an 1614 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1615 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1616 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1617 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1618 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1619 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1621 Copyright Statement 1623 Copyright (C) The Internet Society (2004). This document is subject 1624 to the rights, licenses and restrictions contained in BCP 78, and 1625 except as set forth therein, the authors retain all their rights. 1627 Acknowledgment 1629 Funding for the RFC Editor function is currently provided by the 1630 Internet Society.