idnits 2.17.1 draft-rosenberg-midcom-turn-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2004) is 7375 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: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIDCOM J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: August 16, 2004 R. Mahy 5 Cisco Systems 6 C. Huitema 7 Microsoft 8 February 16, 2004 10 Traversal Using Relay NAT (TURN) 11 draft-rosenberg-midcom-turn-04 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 16, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 Traversal Using Relay NAT (TURN) is a protocol that allows for an 42 element behind a NAT or firewall to receive incoming data over TCP or 43 UDP connections. It is most useful for elements behind symmetric NATs 44 or firewalls that wish to be on the receiving end of a connection to 45 a single peer. TURN does not allow for users to run servers on well 46 known ports if they are behind a nat; it supports the connection of a 47 user behind a nat to only a single peer. In that regard, its role is 48 to provide the same security functions provided by symmetric NATs and 49 firewalls, but to ``turn'' the tables so that the element on the 50 inside can be on the receiving end, rather than the sending end, of a 51 connection that is requested by the client. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Applicability Statement . . . . . . . . . . . . . . . . . . 7 59 5. Overview of Operation . . . . . . . . . . . . . . . . . . . 8 60 6. Message Overview . . . . . . . . . . . . . . . . . . . . . . 10 61 7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . 11 62 7.1 Shared Secret Request . . . . . . . . . . . . . . . . . . . 11 63 7.2 Allocate Request . . . . . . . . . . . . . . . . . . . . . . 13 64 7.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 7.2.2 Initial Requests . . . . . . . . . . . . . . . . . . . . . . 13 66 7.2.3 Requests for Pre-Allocated Ports . . . . . . . . . . . . . . 17 67 7.2.4 Subsequent Requests . . . . . . . . . . . . . . . . . . . . 18 68 7.3 Send Request . . . . . . . . . . . . . . . . . . . . . . . . 19 69 7.4 Receiving Packets and Connections . . . . . . . . . . . . . 20 70 7.5 Lifetime Expiration . . . . . . . . . . . . . . . . . . . . 22 71 8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . 23 72 8.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 8.2 Obtaining a One Time Password . . . . . . . . . . . . . . . 23 74 8.3 Allocating a Binding . . . . . . . . . . . . . . . . . . . . 24 75 8.4 Processing Allocate Responses . . . . . . . . . . . . . . . 25 76 8.5 Allocating a Pre-Allocated Binding . . . . . . . . . . . . . 26 77 8.6 Refreshing a Binding . . . . . . . . . . . . . . . . . . . . 27 78 8.7 Sending Data . . . . . . . . . . . . . . . . . . . . . . . . 27 79 8.8 Tearing Down a Binding . . . . . . . . . . . . . . . . . . . 28 80 8.9 Receiving and Sending Data . . . . . . . . . . . . . . . . . 28 81 9. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 30 82 9.1 Message Types . . . . . . . . . . . . . . . . . . . . . . . 30 83 9.2 Message Attributes . . . . . . . . . . . . . . . . . . . . . 30 84 9.2.1 TRANSPORT-PREFERENCES . . . . . . . . . . . . . . . . . . . 30 85 9.2.2 LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . . 31 86 9.2.3 ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . . . 31 87 9.2.4 MAGIC-COOKIE . . . . . . . . . . . . . . . . . . . . . . . . 31 88 9.2.5 BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 9.2.6 DESTINATION-ADDRESS . . . . . . . . . . . . . . . . . . . . 32 90 9.2.7 SOURCE-ADDRESS . . . . . . . . . . . . . . . . . . . . . . . 32 91 9.2.8 DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 92 9.3 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 32 93 10. Security Considerations . . . . . . . . . . . . . . . . . . 34 94 11. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 36 95 11.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . 36 96 11.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . 36 97 11.3 Brittleness Introduced by TURN . . . . . . . . . . . . . . . 37 98 11.4 Requirements for a Long Term Solution . . . . . . . . . . . 38 99 11.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . . 38 100 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39 101 Normative References . . . . . . . . . . . . . . . . . . . . 40 102 Informative References . . . . . . . . . . . . . . . . . . . 41 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 104 Intellectual Property and Copyright Statements . . . . . . . 43 106 1. Introduction 108 Network Address Translators (NATs), while providing many benefits, 109 also come with many drawbacks. The most troublesome of those 110 drawbacks is the fact that they break many existing IP applications, 111 and make it difficult to deploy new ones. Guidelines [9] have been 112 developed that describe how to build "NAT friendly" protocols, but 113 many protocols simply cannot be constructed according to those 114 guidelines. Examples of such protocols include multimedia 115 applications and file sharing. 117 Simple Traversal of UDP Through NAT (STUN) [1] provides one means for 118 an application to traverse a NAT. STUN allows a client to obtain a 119 transport address (and IP address and port) which may be useful for 120 receiving packets from a peer. However, addresses obtained by STUN 121 may not be usable by all peers. Those addresses work depending on the 122 topological conditions of the network. Therefore, STUN by itself 123 cannot provide a complete solution for NAT traversal. 125 A complete solution requires a means by which a client can obtain a 126 transport address from which it can receive media from any peer which 127 can send packets to the public Internet. This can only be 128 accomplished by relaying data though a server that resides on the 129 public Internet. This specification describes Traversal Using Relay 130 NAT (TURN), a protocol that allows a client to obtain IP addresses 131 and ports from such a relay. 133 Although TURN will almost always provide connectivity to a client, it 134 comes at high cost to the provider of the TURN server. It is 135 therefore desirable to use TURN as a last resort only, preferring 136 other mechanisms (such as STUN or direct connectivity) when possible. 137 To accomplish that, the Interactive Connectivity Establishment (ICE) 138 [13] methodology can be used to discover the optimal means of 139 connectivity. 141 2. Terminology 143 In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, 144 SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to 145 be interpreted as described in RFC 2119 [2] and indicate requirement 146 levels for compliant TURN implementations. 148 3. Definitions 150 TURN Client: A TURN client (also just referred to as a client) is 151 an entity that generates TURN requests. A TURN client can be an 152 end system, such as a Session Initiation Protocol (SIP) [6] User 153 Agent, or can be a network element, such as a Back-to-Back User 154 Agent (B2BUA) SIP server. The TURN protocol will provide the STUN 155 client with IP addresses that route to it from the public 156 Internet. 158 TURN Server: A TURN Server (also just referred to as a server) is 159 an entity that receives TURN requests, and sends TURN responses. 160 The server is capable of acting as a data relay, receiving data on 161 the address it provides to clients, and forwarding them to the 162 clients. 164 Transport Address: An IP address and port. 166 4. Applicability Statement 168 TURN is useful for applications that require a client to place a 169 transport address into a protocol message, with the expectation that 170 the client will be able to receive packets from a single host that 171 will send to this address. Examples of such protocols include SIP, 172 which makes use of the Session Description Protocol (SDP) [7]. SDP 173 carries and IP address on which the client will receive media packets 174 from its peer. Another example of a protocol meeting this criteria is 175 the Real Time Streaming Protocol (RTSP) [8]. 177 When a client is behind a NAT, transport addresses obtained from the 178 local operating system will not be publically routable, and 179 therefore, not useful in these protocols. TURN allows a client to 180 obtain a transport address, from a server on the public Internet, 181 which can be used in protocols meeting the above criteria. However, 182 the transport addresses obtained from TURN servers are not generally 183 useful for receiving data from anywhere. They are only useful for 184 communicating with a single peer. Once a host sends packets to that 185 transport address, it is ``locked down'', meaning that the client 186 cannot cause packets to be sent to that host through the relay. The 187 client will still receive packets sent from different peers to that 188 transport address, but these are wrapped in TURN protocol headers, 189 reducing their efficiency. This is done purposefully, so as to 190 prevent TURN from being used to run servers (such as a web server or 191 DNS server) on a client behind a NAT. In this way, enterprises which 192 deploy NATs and firewalls to prevent users from running servers, can 193 be confident that TURN will not cause any violations in their 194 enterprise security policies. 196 5. Overview of Operation 198 The typical TURN configuration is shown in Figure 1. A TURN client is 199 connected to private network 1. This network connects to private 200 network 2 through NAT 1. Private network 2 connects to the public 201 Internet through NAT 2. On the public Internet is a TURN server. 203 /-----\ 204 // TURN \\ 205 | Server | 206 \\ // 207 \-----/ 209 +--------------+ Public Internet 210 ................| NAT 2 |....................... 211 +--------------+ 213 +--------------+ Private NET 2 214 ................| NAT 1 |....................... 215 +--------------+ 217 /-----\ 218 // TURN \\ 219 | Client | 220 \\ // Private NET 1 221 \-----/ 223 Figure 1 225 TURN is a simple client-server protocol. It is identical in syntax 226 and general operation to STUN, in order to facilitate a joint 227 implementation of both. TURN defines a request message, called 228 Allocate, which asks for a public IP address and port. TURN can run 229 over UDP and TCP, as it allows for a client to request address/port 230 pairs for receiving both UDP and TCP. 232 A TURN client first discovers the address of a TURN server. This can 233 be preconfigured, or it can be discovered using SRV records [3] This 234 will allow for different TURN servers for UDP and TCP. Once a TURN 235 server is discovered, the client sends a TURN Allocate request to the 236 TURN server. TURN provides a mechanism for mutual authentication and 237 integrity checks for both requests and responses, based on a shared 238 secret. Assuming the request is authenticated and has not been 239 tampered with, the TURN server remembers the source transport address 240 that the request came from (call this SA), and returns a public 241 transport address, PA, in the TURN response. The TURN server is 242 responsible for guaranteeing that packets sent to PA route to the 243 TURN server. The TURN server then waits for data on PA. When data is 244 received (either a UDP packet or a TCP connection request), the TURN 245 server accepts the connection (in the case of TCP), and then stores 246 the remote address and port where the data came from (RA). The data 247 just received, if any, are then forwarded to SA. The TURN server then 248 acts as a relay. Any data received from SA are forwarded to RA. Any 249 data sent from RA to PA are sent to SA. If some other host sends 250 packets to PA, those packets are forwarded to PA as well, but they 251 are sent as a TURN message from the server to the client. This 252 affords some protection against denial of service attacks that would 253 otherwise be possible. TURN also allows a client to send packets 254 through the TURN server before lockdown has occurred, by using the 255 SEND command. 257 For TCP, the TURN server does not need to examine the data received; 258 it merely forwards all data between the socket pairs it has 259 associated together. In the case of UDP, the TURN server looks for a 260 magic cookie in the first 128 bytes of each UDP packet. If present, 261 it indicates that the packet is a TURN control packet, used for 262 keepalives and teardown of the binding. In the case of TCP, if either 263 side closes a connection, the TURN server closes the other 264 connection. For both UDP and TCP, the TURN server can also time out a 265 connection in the event data is not received after some configured 266 time out period. This period is sent to the client in the TURN 267 response to the Allocate request. 269 TURN also allows a client to request an odd or even port when one is 270 allocated, and for it to pre-allocate the next higher port. This is 271 useful for securing consecutive ports for usage with the Real Time 272 Transport Protocol (RTP) [5]. 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 TRANSPORT-PREFERENCES attribute, which 285 allows a client to request an odd or even port, and to pre-allocate 286 the next higher port. It defines the LIFETIME attribute, which allows 287 the TURN server to tell the client when the binding will be released. 288 It defines the MAGIC-COOKIE attribute, which allows the TURN client 289 to find TURN messages in a stream of UDP packets. It defines the 290 BANDWIDTH attribute, which allows a client to inform the server of 291 the expected bandwidth usage on the connection. Finally, it defines 292 the ALTERNATE-SERVER attribute, which allows the server to redirect 293 the TURN client to connect to an alternate server. 295 7. Server Behavior 297 The server behavior depends on whether the request is a Shared Secret 298 Request or an Allocate Request. 300 7.1 Shared Secret Request 302 Unlike a STUN server, a TURN server provides resources to clients 303 that connect to it. Therefore, only authorized clients can gain 304 access to a TURN server. This requires that TURN requests be 305 authenticated. TURN assumes the existence of a long-lived shared 306 secret between the client and the TURN server in order to achieve 307 this authentication. The client uses this long-lived shared secret to 308 authenticate itself in a Shared Secret Request, sent over TLS. The 309 Shared Secret Response provides the client with a one-time username 310 and password. This one-time credential is then used by the server to 311 authenticate an Allocate Request. The usage of a separate long lived 312 and one-time credentials prevents dictionary attacks, whereby an 313 observer of a message and its HMAC could guess the password by an 314 offline dictionary search. 316 When a TURN server receives a Shared Secret Request, it first 317 executes the processing described in the first three paragraphs of 318 Section 8.2 of STUN. This processing will ensure that the Shared 319 Secret Request is received over TLS. 321 Assuming it was, the server checks the Shared Secret Request for a 322 MESSAGE-INTEGRITY attribute. If not present, the server generates a 323 Shared Secret Error Response with an ERROR-CODE attribute with 324 response code 401. That response MUST include a NONCE attribute, 325 containing a nonce that the server wishes the client to reflect back 326 in a subsequent Shared Secret Request (and therefore include the 327 message integrity computation). The response MUST include a REALM 328 attribute, containing a realm from which the username and password 329 are scoped [4]. 331 If the MESSAGE-INTEGRITY attribute was present, the server checks for 332 the existence of the REALM attribute. If the attribute is not 333 present, the server MUST generate a Shared Secret Error Response. 334 That response MUST include an ERROR-CODE attribute with response code 335 434. That response MUST include a NONCE and a REALM attribute. 337 If the REALM attribute was present, the server checks for the 338 existence of the NONCE attribute. If the NONCE attribute is not 339 present, the server MUST generate a Shared Secret Error Response. 340 That response MUST include an ERROR-CODE attribute with response code 341 435. That response MUST include a NONCE attribute and a REALM 342 attribute. 344 If the NONCE attribute was present, the server checks for the 345 existence of the USERNAME attribute. If it was not present, the 346 server MUST generate a Shared Secret Error Response. The Shared 347 Secret Error Response MUST include an ERROR-CODE attribute with 348 response code 432. It MUST include a NONCE attribute and a REALM 349 attribute. 351 If the USERNAME is present, the server computes the HMAC over the 352 request as described in Section 11.2.8 of STUN. The key is computed 353 as MD5(unq(USERNAME-value) ":" unq(REALM-value) ":" passwd), where 354 the password is the password associated with the username and realm 355 provided in the request. If the server does not have a record for 356 that username within that realm, the server generates a Shared Secret 357 Error Response. That response MUST include an ERROR-CODE attribute 358 with response code 436. That response MUST include a NONCE attribute 359 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 a 374 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 is 433 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 has 458 already been used, the server generates an Allocate Error Response. 459 That response MUST include an ERROR-CODE attribute with response code 460 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 server 489 looks for the presence of the TRANSPORT-PREFERENCES attribute in the 490 request. If the attribute indicates that an even port is requested, 491 the server attempts to allocate a transport address with an even 492 port. If the attribute indicates that an odd port is requested, the 493 server attempts to allocate a transport address with an odd port. If 494 the attribute indicates that there is no preference for port parity, 495 or if the TRANSPORT-PREFERENCES attribute was absent, the server 496 attempts to allocate a port with either parity. The server MUST NOT 497 allocate ports from the well-known port range (0-1023) and MUST NOT 498 allocate ports from the user registered port range (1024 through 499 49151). 501 This aspect of the protocol helps guarantee that users cannot run 502 servers (such as a web server, SIP server, or SMTP server) using 503 TURN. 505 The TRANSPORT-PREFERENCES attribute can also indicate a preference 506 for a specific address and port, pre-allocated previously by a prior 507 Allocate request. This case is described in Section 7.2.3. 509 If a port meeting the constraints (including bandwidth) cannot be 510 allocated, the server MUST generate a Allocate Error Response that 511 includes an ERROR-CODE attribute with a response code of 300. That 512 response MAY include an ALTERNATE-SERVER attribute pointing to an 513 alternate server which can be used by the client. 515 Assuming a port was allocated according to the preferences (call this 516 the base port), the server checks to see if the TRANSPORT-PREFERENCES 517 attribute is present, and indicates a desire to pre-allocate the next 518 higher port (called the pre-allocated port). If so, the server 519 attempts to allocate that port from its local operating system. If it 520 cannot be allocated, the server can do one of two things. First, it 521 MAY try to allocate a different base port, in the hopes that the next 522 higher port is available. If the server believes that there are no 523 adjacent ports meeting the parity constraints present in the request, 524 the server MAY generate an Allocate Error Response that includes an 525 ERROR-CODE attribute with a response code of 300. That response MAY 526 include an ALTERNATE-SERVER attribute pointing to an alternate server 527 which can be used by the client. 529 Once a base port is allocated, the server creates a binding for it. 530 This binding is a mapping between two five-tuples - the allocate 531 five-tuple and the remote five-tuple. The allocate five-tuple is set 532 to the five-tuple of the Allocate Request (that is, the protocol of 533 the allocate five-tuple is set to the protocol of the Allocate 534 Request (TCP or UDP), the source IP address and port of the allocate 535 five-tuple are set to the source IP address and port in the Allocate 536 Request, and the destination IP address and port of the allocate 537 five-tuple are set to the destination IP address and port in the 538 Allocate Request). The protocol in the remote five-tuple is set to 539 the protocol from the Allocate Request. The source IP address of the 540 remote five-tuple is set to the interface from which the base port 541 was allocated. The source port of the remote five-tuple is set to the 542 base port. If the binding was allocated for TCP, the connection on 543 which the Allocate request was received is associated with the 544 allocate five-tuple in the binding. 546 The server MUST remember the one-time username and password used to 547 obtain the binding. 549 If an address and port was pre-allocated (either at the request or 550 the user, or the at the discretion of the server), a binding is also 551 created for it. The allocate five-tuple is left empty. The protocol 552 in the remote five-tuple is set to the protocol from the Allocate 553 Request. The source IP address of the remote five-tuple is set to the 554 interface from which the pre-allocated port was allocated. The source 555 port of the remote five-tuple is set to the pre-allocated port. The 556 identity of the user (defined as the username provided in the Shared 557 Secret Request used to obtain the one-time password used in the 558 Allocate Request) is associated with this pre-allocated tuple. Only 559 that user can perform an allocation for this tuple. Furthermore, a 560 timer is set. If no allocation is made against this pre-allocation 561 within 5 minutes, the port is released and the binding 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 is 593 placing on the bandwidth usage on each binding. Such caps are needed 594 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 was 668 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 NOT 671 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 source 683 IP address and port from the remote five-tuple of the binding. It 684 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 the 720 remote 5-tuple for the binding has been filled in (i.e., lock-down 721 has occurred). If it has, the server MUST generate a 438 (Sending 722 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 compared 728 to the allocate five-tuples in existing bindings. The matching 729 binding is selected. The one-time username and password associated 730 with that binding MUST match the ones used in the request. 732 Once the request has been authenticated, the server validates it. The 733 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 that 747 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. If 768 the destination IP address and port of the remote five-tuple in the 769 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 attribute 788 whose contents are equal to the payload of the UDP packet. The 789 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 allocate 792 five-tuple. That is, its destination address is equal to the source 793 address from the allocate five-tuple, and its source address is equal 794 to the destination address from the allocate five-tuple. 796 If the packet was not sent as a Data Indication message, it is 797 forwarded. To forward, the packet is sent with a source IP address 798 and port equal to the destination IP address and port in the allocate 799 five-tuple, and with a destination address and port equal to the 800 source IP address and port in the allocate five-tuple. If the 801 destination address and port of the remote five-tuple were not filled 802 in, they are populated at this time. The server MUST set the 803 destination IP address and port of the remote five-tuple to the 804 source IP address and port in the UDP packet. Note that, unlike a 805 Data Indication message, when the packet is forwarded, the payload of 806 the transmitted packet is identical to the one received. No headers 807 are added to the packet. 809 The process of filling in the destination IP address and port of the 810 remote five-tuple is called "locking down". Once done, the client can 811 only send and receive packets with the specific peer from which the 812 first packet or connection was received. 814 If a TURN server receives data on a TCP connection that was opened to 815 a port it had allocated, the server MUST forward this data onto the 816 connection associated with allocate-tuple in the binding. 818 If a TURN server receives data on a TCP connection that is associated 819 with an allocate five-tuple, the binding for that tuple is retrieved. 820 If the destination IP address and port of that tuple have not been 821 filled in yet, the data is discarded. If the destination address and 822 port have been filled in, the connection associated with the remote 823 five-tuple is obtained, and the data is forwarded on that connection. 825 Note that, because data is forwarded blindly across TCP bindings, TLS 826 will successfully operate over a TURN allocated TCP port. 828 Similarly, if a TURN server receives a UDP packet on one of its 829 public TURN ports, it checks to see if the source IP address and port 830 match those of the allocate five-tuples in an existing binding. If 831 there is a match, the the UDP packet is not a TURN request (see 832 Section 7.2.4 for details on how this determination is made), the 833 destination IP address and port in the remote five-tuple of the 834 binding are checked. If they are not filled in yet, the UDP packet is 835 discarded. If they are, the packet is forwarded. It is forwarded 836 using the source IP address and port from the remote five-tuple, and 837 a destination IP address and port from the remote five-tuple. 839 If a TCP connection associated with an allocate five-tuple is closed, 840 the connection associated with the corresponding remote five-tuple is 841 also closed. At that point, the binding is destroyed. Similarly, if 842 the TCP connection associated with a remote five-tuple is closed, the 843 connection associated with the corresponding allocate five-tuple is 844 closed, and the binding is destroyed. 846 7.5 Lifetime Expiration 848 When the activity timer for a binding fires, the server checks to see 849 if there has been any activity on the binding since its creation, or 850 since the last firing of the timer, whichever is more recent. 851 Activity is defined as connection establishment, or packet 852 transmission in either direction. If there has been activity, the 853 timer is set to fire once again in M seconds, where M is the value of 854 the LIFETIME attribute returned in the most recent Allocate Response 855 for this binding. 857 If there has been no activity, the server MUST destroy the binding, 858 along with its associated one-time password. If the binding was over 859 TCP, the server MUST close any connections it is holding to the 860 client and to the remote client. 862 8. Client Behavior 864 Client behavior is broken into several separate steps. First, the 865 client obtains a one-time username and password. Secondly, it 866 generates initial Allocate Requests, and processes the responses. It 867 manages those addresses (refreshing and tearing them down), issues 868 Send Requests, and processes TURN indications and data received on 869 those addresses. 871 8.1 Discovery 873 Generally, the client will be configured with a domain name of the 874 provider of the TURN servers. This domain name is resolved to an IP 875 address and port of using the SRV procedures [3]. When sending a 876 Shared Secret request, the service name is "turn" and the protocol is 877 "tcp". RFC 2782 spells out the details of how a set of SRV records 878 are sorted and then tried. However, it only states that the client 879 should "try to connect to the (protocol, address, service)" without 880 giving any details on what happens in the event of failure. Those 881 details are described here for TURN. 883 For TURN requests, failure occurs if there is a transport failure of 884 some sort (generally, due to fatal ICMP errors in UDP or connection 885 failures in TCP). Failure also occurs if the the request does not 886 solicit a response after 9.5 seconds. If a failure occurs, the client 887 SHOULD create a new request, which is identical to the previous, but 888 has a different transaction ID and MESSAGE-INTEGRITY attribute. That 889 request is sent to the next element in the list as specified by 890 RFC~2782. 892 8.2 Obtaining a One Time Password 894 In order to allocate addresses, a client must obtain a one-time 895 username and password from the TURN server. A unique username and 896 password are required for each distinct address allocated from the 897 server. 899 To obtain a one-time username and password, the client generates and 900 sends a Shared Secret Request. This is done as described in Section 901 9.2 of STUN. This request will have no attributes, and therefore, 902 based on the processing in Section 7.1, the server will reject it 903 with a Shared Secret Error Response with a 401 response code. That 904 response will contain a NONCE and a REALM. The client SHOULD generate 905 a new Shared Secret Request (with a new transaction ID), which 906 contains the NONCE and REALM attributes copied from the 401 response. 907 The request MUST include the USERNAME attribute, which contains a 908 username supplied by the user for the specified realm. The request 909 MUST include a MESSAGE-INTEGRITY attribute as the last attribute. The 910 key for the HMAC is computed as described in Section 7.1. 912 If the response (either to the initial request or to the second 913 attempt with the credentials) is a Shared Secret Error Response, the 914 processing depends on the the value of the response code in the 915 ERROR-CODE attribute. If the response code was a 430, the client 916 SHOULD generate a new Shared Secret Request, using the username and 917 password provided by the user, and the REALM and NONCE provided in 918 the 430 response. For a 431 or 436 response code, the client SHOULD 919 alert the user. For a 432, 434 and 435 response codes, if the client 920 had omitted the USERNAME, REALM or NONCE attributes, respectively, 921 from the previous request, it SHOULD retry, this time including the 922 USERNAME, NONCE, REALM, and MESSAGE-INTEGRITY attributes. For a 500 923 response code, the client MAY wait several seconds and then retry the 924 request. For a 600 response code, the client MUST NOT retry the 925 request, and SHOULD display the reason phrase to the user. Unknown 926 attributes between 400 and 499 are treated like a 400, unknown 927 attributes between 500 and 599 are treated like a 500, and unknown 928 attributes between 600 and 699 are treated like a 600. Any response 929 between 100 and 399 MUST result in the cessation of request 930 retransmissions, but otherwise is discarded. 932 If a client receives a Shared Secret Response with an attribute whose 933 type is greater than 0x7fff, the attribute MUST be ignored. If the 934 client receives a Shared Secret Response with an attribute whose type 935 is less than or equal to 0x7fff, the response is ignored. 937 If the response is a Shared Secret Response, it will contain the 938 USERNAME and PASSWORD attributes. The client can use these to 939 authenticate an Allocate Request, as described below. 941 A client MAY send multiple Shared Secret Requests over the same TLS 942 connection, and MAY do so without waiting for responses to previous 943 requests. The client SHOULD close its connection when it has 944 completed allocating usernames and passwords. 946 8.3 Allocating a Binding 948 When a client wishes to obtain a transport address, it sends an 949 Allocate Request to the TURN server. Requests for TCP transport 950 addresses MUST be sent over a TCP connection, and requests for UDP 951 transport addresses MUST be sent over UDP. 953 First, the client obtains a one-time username and password, using the 954 mechanisms described in Section 8.2. The client then formulates an 955 Allocate Request. The request MUST contain a transaction ID, unique 956 for each request, and uniformly and randomly distributed between 0 957 and 2**128 - 1. The message type of the request MUST be ``Allocate 958 Request''. The length is set as described in Section 11.1 of STUN. 960 The Allocate request MUST contain the MAGIC-COOKIE attribute as the 961 first attribute. If the client wishes to allocate an odd or even 962 port, it can do so by including the TRANSPORT-PREFERENCES attribute 963 in the request. That attribute can also be used by the client if it 964 wishes to pre-allocate the port one higher. 966 The client SHOULD include a BANDWIDTH attribute, which indicates the 967 maximum bandwidth that will be used with this binding. If the maximum 968 is unknown, the attribute is not included in the request. 970 The client MAY request a particular lifetime for the binding by 971 including it in the LIFETIME attribute in the request. If the no data 972 is sent or received on the binding before expiration of the lifetime, 973 the binding will be deleted by the client. 975 The client MUST include a USERNAME attribute, containing a username 976 obtained from a previous Shared Secret Response. The request MUST 977 include a MESSAGE-INTEGRITY attribute as the last attribute. The key 978 is equal to the password obtained from the PASSWORD attribute of the 979 Shared Secret Response. The Allocate Request MUST be sent to the same 980 IP address and port as the Shared Secret Request. This is because one 981 time passwords are expected to be host-specific. Rules for 982 retransmissions for Allocate Requests sent over UDP are identical to 983 those for STUN Binding Requests. Allocate Requests sent over TCP are 984 not retransmitted. Transaction timeouts are identical to those for 985 STUN Binding Requests, independent of the transport protocol. 987 8.4 Processing Allocate Responses 989 If the response is an Allocate Error Response, the client checks the 990 response code from the ERROR-CODE attribute of the response. For a 991 400 response code, the client SHOULD display the reason phrase to the 992 user. For a 420 response code, the client SHOULD retry the request, 993 this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES 994 attribute of the response. For a 430 response code, the client SHOULD 995 obtain a new one-time username and password, and retry the Allocate 996 Request with a new transaction. For 401 and 432 response codes, if 997 the client had omitted the USERNAME or MESSAGE-INTEGRITY attribute as 998 indicated by the error, it SHOULD try again with those attributes. A 999 new one-time username and password is needed in that case. For a 431 1000 response code, the client SHOULD alert the user, and MAY try the 1001 request again after obtaining a new username and password. For a 300 1002 response code, the client SHOULD attempt a new TURN transaction to 1003 the server indicated in the ALTERNATE-SERVER attribute. For a 500 1004 response code, the client MAY wait several seconds and then retry the 1005 request with a new username and password. For a 600 response code, 1006 the client MUST NOT retry the request, and SHOULD display the reason 1007 phrase to the user. Unknown attributes between 400 and 499 are 1008 treated like a 400, unknown attributes between 500 and 599 are 1009 treated like a 500, and unknown attributes between 600 and 699 are 1010 treated like a 600. Unknown attributes between 300 and 399 are 1011 treated like 300. Any response between 100 and 299 MUST result in the 1012 cessation of any request retransmissions, but otherwise is discarded. 1014 If a client receives a response with an attribute whose type is 1015 greater than 0x7fff, the attribute MUST be ignored. If the client 1016 receives a response with an attribute whose type is less than or 1017 equal to 0x7fff, any request retransmissions MUST cease, but the 1018 entire response is otherwise ignored. 1020 If the response is an Allocate Response, the client MUST check the 1021 response for a MESSAGE-INTEGRITY attribute. If not present, the 1022 client MUST discard the response. If present, the client computes the 1023 HMAC over the response. The key MUST be same as used to compute the 1024 MESSAGE-INTEGRITY attribute in the request. If the computed HMAC 1025 differs from the one in the response, the client MUST discard the 1026 response, and SHOULD alert the user about a possible attack. If the 1027 computed HMAC matches the one from the response, processing 1028 continues. 1030 The MAPPED-ADDRESS in the Binding Response can be used by the client 1031 for receiving packets. The server will expire the binding after 1032 LIFETIME seconds have passed with no activity. The server will allow 1033 the user to send and receive no more than the amount of data 1034 indicated in the BANDWIDTH attribute. 1036 8.5 Allocating a Pre-Allocated Binding 1038 If the initial Allocate Request included TRANSPORT-PREFERENCES that 1039 indicated a desire to pre-allocate the port one-higher, the client 1040 MAY allocate that port at a later time. It MUST do so within 4 1041 minutes of receiving the Allocate Response, or the pre-allocated port 1042 will expire. 1044 To allocate the port, the client generates an Allocate Request as 1045 described in Section 8.3. A new username and password MUST be used 1046 for this allocation. The request MUST contain a TRANSPORT-PREFERENCES 1047 attribute. It MUST indicate an explicit interface and port, whose 1048 value is one higher than the port number returned in the prior 1049 Allocate Response. 1051 Processing of the responses is identical to Section 8.4. However, the 1052 client SHOULD explicitly check that received packets are TURN 1053 responses, as opposed to data packets, using the techniques described 1054 in Section 7.2.4. 1056 8.6 Refreshing a Binding 1058 If there has been no activity on a UDP binding for a period of time 1059 equalling 3/4 of the lifetime of the binding (as conveyed in the 1060 LIFETIME attribute of the Allocate Response), the client SHOULD 1061 refresh the binding with another Allocate Request if it wishes to 1062 keep it. Note that only UDP bindings can be refreshed. For TCP, 1063 application-specific keepalives are needed. 1065 To perform a refresh, the client generates an Allocate Request as 1066 described in Section 8.3. However, the one-time username and password 1067 used MUST be the same as those used in the successful Allocate 1068 Request for that binding. The client will need to look for the TURN 1069 response amongst the data packets using the MAGIC-COOKIE, as 1070 described in Section 7.2.4. Processing of that response is as defined 1071 in Section 8.4. If the response was an Allocate Response, and the 1072 MAPPED-ADDRESS contains the same transport address as previously 1073 obtained, the binding has been refreshed. The LIFETIME attribute 1074 indicates the amount of additional time the binding will live without 1075 activity. If, however, the response was an Allocate Error Response 1076 with an ERROR-CODE indicating a 430 response, it means that the 1077 binding has expired at the server. The client MAY use the procedures 1078 in Section 8.3 to obtain a new binding (this will require a new 1079 one-time username and password. Other response codes do not imply 1080 that the binding has been expired, just that the refresh has failed. 1082 8.7 Sending Data 1084 Before lockdown has occured, a client MAY send data using a binding 1085 it has allocated from the TURN server. To do that, it formulates a 1086 Send Request. This request MUST contain a transaction ID, unique for 1087 each request, and uniformly and randomly distributed between 0 and 1088 2**128 - 1. The message type of the request MUST be "Send Request". 1089 The length is set as described in Section 11.1 of STUN. 1091 The Send request MUST contain the MAGIC-COOKIE attribute as the first 1092 attribute. The client MUST include a USERNAME attribute, containing 1093 the same username used in the Allocate request for this binding. The 1094 request MUST include a MESSAGE-INTEGRITY attribute as the last 1095 attribute. The key is equal to the password used for the Allocate 1096 request for this binding. The Send Request MUST be sent to the same 1097 IP address and port as the Allocate Request, and MUST be sent from 1098 the same source IP and port used to send the Allocate request for the 1099 binding. Rules for retransmissions for Send Requests sent over UDP 1100 are identical to those for STUN Binding Requests. There is currently 1101 no support for Send Requests over TCP. Transaction timeouts are 1102 identical to those for STUN Binding Requests, independent of the 1103 transport protocol. 1105 The Send Request MUST contain a DESTINATION-ADDRESS attribute, which 1106 contains the IP address and port that the data is being sent to. A 1107 client MUST NOT specify a port below 1024, as the server will reject 1108 such requests. This prevents TURN from being used as a relay to 1109 launch DoS attacks against well-known services. The Send Request MUST 1110 contain a DATA attribute, whose contents are the data to transmit. 1112 If the server successfully sends the data, the client will receive a 1113 Send Response. Note that, as with responses to Allocate refreshes, 1114 the client will need to pick the Send Response (or Send Error 1115 Response) out of the packet stream by searching for the MAGIC-COOKIE 1116 in each received UDP packet. If the response is a Send Error 1117 Response, it is processed as described in the first two paragraphs of 1118 Section 8.4. If the response code is 438, the client is forbidden 1119 from using the Send Request, since lockdown has occurred. The client 1120 can relay data to the peer by sending the data without a TURN message 1121 wrapper. [[OPEN ISSUE: is there a need for the client to be told what 1122 the locked-down address is?]] 1124 8.8 Tearing Down a Binding 1126 If a client no longer needs a binding, it SHOULD tear it down. For 1127 TCP, this is done by closing the connection. For UDP, this is done by 1128 performing a refresh, as described in Section 8.6, but with a 1129 LIFETIME attribute indicating a time of 0. 1131 8.9 Receiving and Sending Data 1133 Once a binding has been allocated by an Allocate Response, the client 1134 MUST be prepared to receive data from the socket on which the 1135 Allocate Request was sent. For UDP, the client MUST be prepared to 1136 disambiguate TURN messages from data for the lifetime of the binding. 1137 This disambiguation is done using the MAGIC-COOKIE, as described in 1138 Section 7.2.4. 1140 Once data has been received, the client MAY send data to its peer by 1141 sending data on that same socket. Sending data on the socket before 1142 data is received will cause the data to be discarded by the server. 1144 The client may receive a Data Indication message from the TURN 1145 server. The client does not generate any kind of response to this 1146 message. Its receipt implies that a packet from a second peer has 1147 been received after lock-down. This specification does not define any 1148 particular treatment to data received in such an indication. However, 1149 in many cases, it can be a sign of a potential denial-of-service 1150 attack against the client. If the client believes that it should not 1151 be receiving data from any other source, it SHOULD terminate the 1152 binding. 1154 9. Protocol Details 1156 This section presents the detailed encoding of the message types, 1157 attributes, and response codes which are new to TURN. The general 1158 message structure of TURN is identical to STUN [1]. 1160 9.1 Message Types 1162 TURN defines three new Message Types: 1164 0x0003 : Allocate Request 1165 0x0103 : Allocate Response 1166 0x0113 : Allocate Error Response 1167 0x0004 : Send Request 1168 0x0104 : Send Response 1169 0x0114 : Send Error Response 1170 0x0115 : Data Indication 1172 9.2 Message Attributes 1174 TURN defines the following message attributes: 1176 0x000c: TRANSPORT-PREFERENCES 1177 0x000d: LIFETIME 1178 0x000e: ALTERNATE-SERVER 1179 0x000f: MAGIC-COOKIE 1180 0x0010: BANDWIDTH 1181 0x0011: DESTINATION-ADDRESS 1182 0x0012: SOURCE-ADDRESS 1183 0x0013: DATA 1185 9.2.1 TRANSPORT-PREFERENCES 1187 The TRANSPORT-PREFERENCES attribute indicates preferences for the 1188 ports allocated by the TURN server. It is either 32 or 96 bits long, 1189 depending on the value of the Typ bits. These bits indicate the 1190 preferences for the allocated port: 1192 0b00: no preferences 1193 0b01: odd port parity 1194 0b10: even port parity 1195 0b11: allocate a pre-allocated port 1196 When the Typ bits are 0b11, the following 64 bits encode the 1197 pre-allocated transport address. They are in the same format used for 1198 MAPPED-ADDRESS. 1200 The P bit indicates a desire for pre-allocating the port one-higher. 1201 If 1, it means pre-allocation is desired. This bit MUST NOT be set to 1202 1 if the Typ bits are 0b11. That is, pre-allocation cannot be done 1203 again when allocating a previously pre-allocated port. 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | 0 |P|Typ| 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 |x x x x x x x x| Family | Port | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Address | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 9.2.2 LIFETIME 1215 The lifetime attribute represents the duration for which the server 1216 will maintain a binding in the absence of data traffic either from or 1217 to the client. It is a 32 bit value representing the number of 1218 seconds remaining until expiration. 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Lifetime | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 9.2.3 ALTERNATE-SERVER 1226 The alternate server represents an alternate IP address and port for 1227 a different TURN server to try. It is encoded in the same way as 1228 MAPPED-ADDRESS. 1230 9.2.4 MAGIC-COOKIE 1232 The MAGIC-COOKIE is used by TURN clients and servers to disambiguate 1233 TURN traffic from data traffic. Its value ix 0x72c64bc6. 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 |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| 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 9.2.5 BANDWIDTH 1241 The bandwidth attribute represents the peak bandwidth, measured in 1242 kbits per second, that the client expects to use on the binding. The 1243 value represents the sum in the receive and send directions. 1244 [[Editors note: Need to define leaky bucket parameters for this.]] 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Bandwidth | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 9.2.6 DESTINATION-ADDRESS 1252 The DESTINATION-ADDRESS is present in Send Requests. It specifies the 1253 address and port where the data is to be sent. It is encoded in the 1254 same way as MAPPED-ADDRESS. 1256 9.2.7 SOURCE-ADDRESS 1258 The SOURCE-ADDRESS is present in Data Indications. It specifies the 1259 address and port from which a packet was received. It is encoded in 1260 the same way as MAPPED-ADDRESS. 1262 9.2.8 DATA 1264 The DATA attribute is present in Send Requests and Data Indications. 1265 It contains raw payload data that is to be sent (in the case of a 1266 Send Request) or was received (in the case of a Data Indication). 1268 9.3 Response Codes 1270 TURN defines the following new response codes: 1272 300 (Try Alternate): The client should contact an alternate server 1273 for this request. 1275 434 (Missing Realm): The REALM attribute was not present in the 1276 request. 1278 435 (Missing Nonce): The NONCE attribute was not present in the 1279 request. 1281 436 (Unknown Username): The USERNAME supplied in the Shared Secret 1282 Request is not known in the given REALM. 1284 437 (No Binding): A Send Request was received by the server, but 1285 there is no binding in place for the source 5-tuple. 1287 438 (Sending Disallowed): A Send Request was received by the 1288 server, but lock-down has already occurred, and sending is 1289 disallowed. 1291 439 (Illegal Port): A Send Request was received by the server, but 1292 lock-down has already occurred, and sending is disallowed. 1294 10. Security Considerations 1296 TURN servers allocate bandwidth and port resources to clients. 1297 Therefore, a TURN server requires authentication and authorization of 1298 TURN requests. This authentication is provided by a client digest 1299 over TLS, which results in the generation of a one-time password that 1300 is used in a single subsequent Allocate Request. This mechanism 1301 protects against eavesdropping attacks and man-in-the-middle attacks. 1302 The usage of one-time passwords ensures that the Allocate Requests, 1303 which do not run over TLS, are not susceptible to offline dictionary 1304 attacks that can be used to guess the long lived shared secret 1305 between the client and the server. 1307 Because TURN servers allocate resources, they can be susceptible to 1308 denial-of-service attacks. All Allocate Requests are authenticated, 1309 so that an unknown attacker cannot launch an attack. An authenticated 1310 attacker can generate multiple Allocate Requests, but each requires a 1311 new one-time username and password. It is RECOMMENDED that servers 1312 implement a cap on the number of one-time passwords that are 1313 allocated to any specific user at a time (around 5 or 10 should be 1314 sufficient). This will prevent floods of Allocate requests from a 1315 single user, in an attempt to use up the resources of the system. A 1316 single malicious user could generate a single Allocate Request, 1317 obtain a binding, and then flood the server with data over this 1318 binding, in an attempt to deny others service. However, this attack 1319 requires the attacker themselves to receive the data being sent at 1320 the server. To ameliorate these kinds of attacks, servers SHOULD 1321 implement a bandwidth cap on each binding (conveyed to the client in 1322 the BANDWIDTH attribute of the Allocate Response), and discard 1323 packets beyond the threshold. 1325 A client will use the transport address learned from the 1326 MAPPED-ADDRESS attribute of the Binding Response to tell other users 1327 how to reach them. Therefore, a client needs to be certain that this 1328 address is valid, and will actually route to them. Such validation 1329 occurs through the TLS and HMAC-based authentication and integrity 1330 checks provided in TURN. They can guarantee the authenticity and 1331 integrity of the mapped addressses. Note that TURN is not susceptible 1332 to the attacks described in Section 12.2.3, 12.2.4, 12.2.5 or 12.2.6 1333 of STUN. These attacks are based on the fact that a STUN server 1334 mirrors the source IP address, which cannot be authenticated. TURN 1335 does not use the source address of the Binding Request, and 1336 therefore, those attacks do not apply. 1338 Confidentiality of the transport addresses learned through TURN does 1339 not appear to be that important, and therefore, this capability is 1340 not provided. 1342 TURN servers are useful even for users not behind a NAT. They can 1343 provide a way for truly anonymous communications. A user can cause a 1344 call to have its media routed through a TURN server, so that the 1345 user's IP addresses are never revealed. 1347 TCP transport addresses allocated by TURN will properly work with TLS 1348 and SSL. However, any addresses allocated by TURN will not operate 1349 properly with IPSec Authentication Header (AH) [10] in transport 1350 mode. IPSec ESP [11] and any tunnel-mode ESP or AH should still 1351 operate. 1353 Once a binding is locked down by the receipt of a packet, a client is 1354 prohibited from using the binding to send packets anywhere else. If 1355 an eavesdropper had observed a packet containing a TURN allocated 1356 address, it can transmit a packet to this address in an attempt to 1357 cause lock-down. This will prohibit a legitimate user from 1358 communicating with the client on that address. This particular attack 1359 is most easily prevented by ensuring that confidentiality is provided 1360 in any protocols that are used to transport a TURN binding. However, 1361 in a variant of this attack, a malicious client may flood a TURN 1362 server with UDP packets over a wide port range, in an attempt to 1363 cause lock-down on any bindings which were just allocated. This 1364 attack cannot be prevent with confidentiality mechanisms within other 1365 protocols. Fortunately, this attack is expensive to launch. Because 1366 the server provides no positive indications of lock-down, an attacker 1367 will need to be flooding continously without any indication of 1368 success. Furthermore, the rate of packets sent to any particular port 1369 needs to be very high - on the order of one every second or so - 1370 since there is a limited window of opportunity for locking down 1371 before a legitimate client sends a packet to the binding and causes 1372 lock-down. This attack can also be detected by clients. They will 1373 still receive the legitimate packets through the TURN Data 1374 Indications. In many cases, a client will be able to disambiguate the 1375 legitimate ones from those from the attacker. If it determines an 1376 attack is in progress, it can terminate the binding and retry. 1378 11. IAB Considerations 1380 The IAB has studied the problem of ``Unilateral Self Address 1381 Fixing'', which is the general process by which a client attempts to 1382 determine its address in another realm on the other side of a NAT 1383 through a collaborative protocol reflection mechanism RFC 3424 [12]. 1384 TURN is an example of a protocol that performs this type of function. 1385 The IAB has mandated that any protocols developed for this purpose 1386 document a specific set of considerations. This section meets those 1387 requirements. 1389 11.1 Problem Definition 1391 From RFC 3424 [12], any UNSAF proposal must provide: 1393 Precise definition of a specific, limited-scope problem that is to 1394 be solved with the UNSAF proposal. A short term fix should not 1395 be generalized to solve other problems; this is why "short term 1396 fixes usually aren't". 1398 The specific problem being solved by TURN is for a client, which may 1399 be located behind a NAT of any type, to obtain an IP address and port 1400 on the public Internet, useful for applications that require a client 1401 to place a transport address into a protocol message, with the 1402 expectation that the client will be able to receive packets from a 1403 single host that will send to this address. Both UDP and TCP are 1404 addressed. It is also possible to send packets so that the recipient 1405 sees a source address equal to the allocated address. TURN, by 1406 design, does not allow a client to run a server (such as a web or 1407 SMTP server) using a TURN address. TURN is useful even when NAT is 1408 not present, to provide anonymity services. 1410 11.2 Exit Strategy 1412 From [12], any UNSAF proposal must provide: 1414 Description of an exit strategy/transition plan. The better short 1415 term fixes are the ones that will naturally see less and less use 1416 as the appropriate technology is deployed. 1418 It is expected that TURN will be useful indefinitely, to provide 1419 anonymity services. When used to facilitate NAT traversal, TURN does 1420 not iself provide an exit strategy. That is provided by the 1421 Interactive Connectivity Establishment (ICE) [13] mechanism. ICE 1422 allows two cooperating clients to interactively determine the best 1423 addresses to use when communicating. ICE uses TURN-allocated 1424 addresses as a last resort, only when no other means of connectivity 1425 exists. As a result, as NATs phase out, and as IPv6 is deployed, ICE 1426 will increasingly use other addresses (host local addresses). 1427 Therefore, clients will allocate TURN addresses, but not use them, 1428 and therefore, de-allocate them. Servers will see a decrease in 1429 usage. Once a provider sees that its TURN servers are not being used 1430 at all (that is, no media flows through them), they can simply remove 1431 them. ICE will operate without TURN-allocated addresses. 1433 11.3 Brittleness Introduced by TURN 1435 From [12], any UNSAF proposal must provide: 1437 Discussion of specific issues that may render systems more 1438 "brittle". For example, approaches that involve using data at 1439 multiple network layers create more dependencies, increase 1440 debugging challenges, and make it harder to transition. 1442 TURN introduces brittleness in a few ways. First, it adds another 1443 server element to any system, which adds another point of failure. 1444 TURN requires clients to demultiplex TURN packets and data based on 1445 hunting for a MAGIC-COOKIE in the TURN messages. It is possible (with 1446 extremely small probabilities) that this cookie could appear within a 1447 data stream, resulting in mis-classification. That might introduce 1448 errors into the data stream (they would appear as lost packets), and 1449 also result in loss of a binding. TURN relies on any NAT bindings 1450 existing for the duration of the bindings held by the TURN server. 1451 Neither the client nor the TURN server have a way of reliably 1452 determining this lifetime (STUN can provide a means, but it is 1453 heuristic in nature and not reliable). Therefore, if there is no 1454 activity on an address learned from TURN for some period, the address 1455 might become useless spontaneously. 1457 TURN will result in potentially significant increases in packet 1458 latencies, and also increases in packet loss probabilities. That is 1459 because it introduces an intermediary on the path of a packet from 1460 point A to B, whose location is determined by application-layer 1461 processing, not underlying routing topologies. Therefore, a packet 1462 sent from one user on a LAN to another on the same LAN may do a trip 1463 around the world before arriving. When combined with ICE, some of the 1464 most problematic cases are avoided (such as this example) by avoiding 1465 the usage of TURN addresses. However, when used, this problem will 1466 exist. 1468 Note that TURN does not suffer from many of the points of brittleness 1469 introduced by STUN. TURN will work with all existing NAT types known 1470 at the time of writing, and for the forseeable future. TURN does not 1471 introduce any topological constraints. TURN does not rely on any 1472 heuristics for NAT type classification. 1474 11.4 Requirements for a Long Term Solution 1476 From [12]}, any UNSAF proposal must provide: 1478 Identify requirements for longer term, sound technical solutions 1479 -- contribute to the process of finding the right longer term 1480 solution. 1482 Our experience with TURN continues to validate our belief in the 1483 requirements outlined in Section 14.4 of STUN. 1485 11.5 Issues with Existing NAPT Boxes 1487 From [12], any UNSAF proposal must provide: 1489 Discussion of the impact of the noted practical issues with 1490 existing, deployed NA[P]Ts and experience reports. 1492 A number of NAT boxes are now being deployed into the market which 1493 try and provide "generic" ALG functionality. These generic ALGs hunt 1494 for IP addresses, either in text or binary form within a packet, and 1495 rewrite them if they match a binding. This will interfere with proper 1496 operation of any UNSAF mechanism, including TURN. However, if a NAT 1497 tries to modify a MAPPED-ADDRESS in a TURN Allocate Response, this 1498 will be detected by the client as an attack. 1500 12. Examples 1502 TODO. 1504 Normative References 1506 [1] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 1507 Simple Traversal of User Datagram Protocol (UDP) Through Network 1508 Address Translators (NATs)", RFC 3489, March 2003. 1510 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1511 Levels", BCP 14, RFC 2119, March 1997. 1513 [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1514 specifying the location of services (DNS SRV)", RFC 2782, 1515 February 2000. 1517 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1518 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 1519 Basic and Digest Access Authentication", RFC 2617, June 1999. 1521 Informative References 1523 [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1524 "RTP: A Transport Protocol for Real-Time Applications", RFC 1525 3550, July 2003. 1527 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1528 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1529 Session Initiation Protocol", RFC 3261, June 2002. 1531 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1532 Protocol", RFC 2327, April 1998. 1534 [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 1535 Protocol (RTSP)", RFC 2326, April 1998. 1537 [9] Senie, D., "Network Address Translator (NAT)-Friendly 1538 Application Design Guidelines", RFC 3235, January 2002. 1540 [10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1541 November 1998. 1543 [11] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1544 (ESP)", RFC 2406, November 1998. 1546 [12] Daigle, L. and IAB, "IAB Considerations for UNilateral 1547 Self-Address Fixing (UNSAF) Across Network Address 1548 Translation", RFC 3424, November 2002. 1550 [13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1551 Methodology for Nettwork Address Translator (NAT) Traversal 1552 for the Session Initiation Protocol (SIP)", 1553 draft-rosenberg-sipping-ice-01 (work in progress), July 2003. 1555 Authors' Addresses 1557 Jonathan Rosenberg 1558 dynamicsoft 1559 600 Lanidex Plaza 1560 Parsippany, NJ 07054 1561 US 1563 Phone: +1 973 952-5000 1564 EMail: jdrosen@dynamicsoft.com 1565 URI: http://www.jdrosen.net 1566 Rohan Mahy 1567 Cisco Systems 1568 101 Cooper St 1569 Santa Cruz, CA 95060 1570 US 1572 EMail: rohan@cisco.com 1574 Christian Huitema 1575 Microsoft 1576 One Microsoft Way 1577 Redmond, WA 98052-6399 1578 US 1580 EMail: huitema@microsoft.com 1582 Intellectual Property Statement 1584 The IETF takes no position regarding the validity or scope of any 1585 intellectual property or other rights that might be claimed to 1586 pertain to the implementation or use of the technology described in 1587 this document or the extent to which any license under such rights 1588 might or might not be available; neither does it represent that it 1589 has made any effort to identify any such rights. Information on the 1590 IETF's procedures with respect to rights in standards-track and 1591 standards-related documentation can be found in BCP-11. Copies of 1592 claims of rights made available for publication and any assurances of 1593 licenses to be made available, or the result of an attempt made to 1594 obtain a general license or permission for the use of such 1595 proprietary rights by implementors or users of this specification can 1596 be obtained from the IETF Secretariat. 1598 The IETF invites any interested party to bring to its attention any 1599 copyrights, patents or patent applications, or other proprietary 1600 rights which may cover technology that may be required to practice 1601 this standard. Please address the information to the IETF Executive 1602 Director. 1604 Full Copyright Statement 1606 Copyright (C) The Internet Society (2004). All Rights Reserved. 1608 This document and translations of it may be copied and furnished to 1609 others, and derivative works that comment on or otherwise explain it 1610 or assist in its implementation may be prepared, copied, published 1611 and distributed, in whole or in part, without restriction of any 1612 kind, provided that the above copyright notice and this paragraph are 1613 included on all such copies and derivative works. However, this 1614 document itself may not be modified in any way, such as by removing 1615 the copyright notice or references to the Internet Society or other 1616 Internet organizations, except as needed for the purpose of 1617 developing Internet standards in which case the procedures for 1618 copyrights defined in the Internet Standards process must be 1619 followed, or as required to translate it into languages other than 1620 English. 1622 The limited permissions granted above are perpetual and will not be 1623 revoked by the Internet Society or its successors or assignees. 1625 This document and the information contained herein is provided on an 1626 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1627 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1628 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1629 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1630 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1632 Acknowledgment 1634 Funding for the RFC Editor function is currently provided by the 1635 Internet Society.