idnits 2.17.1 draft-ietf-behave-turn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2069. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2082. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 202 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1066 has weird spacing: '...ed with an ex...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 27, 2006) is 6634 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 1987, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1991, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2008, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2011, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2014, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-02 ** 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. '8') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '9') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '11') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '12') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-06 == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-udp-04 Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: August 31, 2006 R. Mahy 5 Plantronics 6 C. Huitema 7 Microsoft 8 February 27, 2006 10 Obtaining Relay Addresses from Simple Traversal of UDP Through NAT 11 (STUN) 12 draft-ietf-behave-turn-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 31, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This specification defines a usage of the Simple Traversal of UDP 46 Through NAT (STUN) Protocol for asking the STUN server to relay 47 packets towards a client. This usage is useful for elements behind 48 NATs whose mapping behavior is address and port dependent. The 49 extension purposefully restricts the ways in which the relayed 50 address can be used. In particular, it prevents users from running 51 well general purpose servers from ports obtained from the STUN 52 server. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 60 5. Applicability Statement . . . . . . . . . . . . . . . . . . 8 61 6. Client Discovery of Server . . . . . . . . . . . . . . . . . 9 62 7. Server Determination of Usage . . . . . . . . . . . . . . . 10 63 8. New Requests and Indications . . . . . . . . . . . . . . . . 10 64 8.1 Allocate Request . . . . . . . . . . . . . . . . . . . . . 11 65 8.1.1 Server Behavior . . . . . . . . . . . . . . . . . . . 11 66 8.1.2 Client Behavior . . . . . . . . . . . . . . . . . . . 15 67 8.2 Connect Request . . . . . . . . . . . . . . . . . . . . . 17 68 8.2.1 Server Behavior . . . . . . . . . . . . . . . . . . . 17 69 8.2.2 Client Behavior . . . . . . . . . . . . . . . . . . . 18 70 8.3 Set Active Destination Request . . . . . . . . . . . . . . 18 71 8.3.1 Server Behavior . . . . . . . . . . . . . . . . . . . 18 72 8.3.2 Client Behavior . . . . . . . . . . . . . . . . . . . 21 73 8.4 Send Indication . . . . . . . . . . . . . . . . . . . . . 24 74 8.4.1 Server Behavior . . . . . . . . . . . . . . . . . . . 24 75 8.4.2 Client Behavior . . . . . . . . . . . . . . . . . . . 25 76 8.5 Data Indication . . . . . . . . . . . . . . . . . . . . . 26 77 8.5.1 Server Behavior . . . . . . . . . . . . . . . . . . . 26 78 8.5.2 Client Behavior . . . . . . . . . . . . . . . . . . . 26 79 9. New Attributes . . . . . . . . . . . . . . . . . . . . . . . 27 80 9.1 LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 9.2 BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . 27 82 9.3 DESTINATION-ADDRESS . . . . . . . . . . . . . . . . . . . 27 83 9.4 REMOTE-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 28 84 9.5 DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 85 9.6 RELAY-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 28 86 9.7 REQUESTED-PORT . . . . . . . . . . . . . . . . . . . . . . 28 87 9.8 REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 29 88 9.9 REQUESTED-IP . . . . . . . . . . . . . . . . . . . . . . . 29 89 9.10 TIMER-VAL . . . . . . . . . . . . . . . . . . . . . . . 30 90 10. New Error Response Codes . . . . . . . . . . . . . . . . . . 30 91 11. Client Procedures . . . . . . . . . . . . . . . . . . . . . 31 92 11.1 Receiving and Sending Unencapsulated Data . . . . . . . 31 93 12. Server Procedures . . . . . . . . . . . . . . . . . . . . . 31 94 12.1 Receiving Data on Allocated Transport Addresses . . . . 31 95 12.1.1 TCP Processing . . . . . . . . . . . . . . . . . . . 31 96 12.1.2 UDP Processing . . . . . . . . . . . . . . . . . . . 32 98 12.2 Receiving Data on Internal Local Transport Addresses . . 33 99 12.3 Lifetime Expiration . . . . . . . . . . . . . . . . . . 34 100 13. Security Considerations . . . . . . . . . . . . . . . . . . 34 101 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36 102 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 36 103 15.1 Problem Definition . . . . . . . . . . . . . . . . . . . 36 104 15.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . 36 105 15.3 Brittleness Introduced by TURN . . . . . . . . . . . . . 37 106 15.4 Requirements for a Long Term Solution . . . . . . . . . 38 107 15.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . 38 108 16. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 38 109 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 110 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 111 18.1 Normative References . . . . . . . . . . . . . . . . . . 44 112 18.2 Informative References . . . . . . . . . . . . . . . . . 44 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 114 Intellectual Property and Copyright Statements . . . . . . . 47 116 1. Introduction 118 The Simple Traversal of UDP Through NAT (STUN) [1] provides a suite 119 of tools for facilitating the traversal of NAT. Specifically, it 120 defines the Binding Request, which is used by a client to determine 121 its reflexive transport address towards the STUN server. The 122 reflexive transport address can be used by the client for receiving 123 packets from peers, but only when the client is behind "good" NATs. 124 In particular, if a client is behind a NAT whose mapping behavior 125 [15] is address or address and port dependent (sometimes called "bad" 126 NATs), the reflexive transport address will not be usable for 127 corresponding with a peer. 129 The only way to obtain a transport address that can be used for 130 corresponding with a peer through such a NAT is to make use of a 131 relay. The relay sits on the public side of the NAT, and allocates 132 transport addresses to clients reaching it from behind the private 133 side of the NAT. These allocated addresses are from interfaces on 134 the relay. When the relay receives a packet on one of these 135 allocated addresses, the relay forwards it towards the client. 137 This specification defines a usage of STUN, called the relay usage, 138 that allows a client to request an address on the STUN server itself, 139 so that the STUN server acts as a relay. To accomplish that, this 140 usage defines two new requests - the Allocate request and the Set 141 Active Destination request. It also defines two indications - Data 142 and Send. The Allocate request is the principal component of this 143 usage, and it is used to provide the client with a transport address 144 that is relayed through the STUN server. A transport address which 145 relays through an intermediary is called a relayed transport address. 147 Though a relayed address is highly likely to work when corresponding 148 with a peer, it comes at high cost to the provider of the STUN 149 server. As a consequence, relayed transport addresses should only be 150 used as a last resort. Protocols using relayed transport addresses 151 should make use of mechanisms to dynamically determine whether such 152 an address is actually needed. One such mechanism, defined for 153 multimedia session establishment protocols based on the offer/answer 154 protocol [7] is Interactive Connectivity Establishment (ICE) [14]. 156 The mechanism defined here was previously a standalone protocol 157 called Traversal Using Relay NAT (TURN), and is now defined as a 158 usage of STUN. 160 2. Terminology 162 In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, 163 SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to 164 be interpreted as described in RFC 2119 [2] and indicate requirement 165 levels for compliant TURN implementations. 167 3. Definitions 169 Relayed Transport Address: A transport address that terminates on a 170 server, and is forwarded towards the client. The STUN Allocate 171 Request can be used to obtain a relayed transport address, for 172 example. 174 4. Overview of Operation 176 The typical configuration is shown in Figure 1. A client is 177 connected to private network 1. This network connects to private 178 network 2 through NAT 1. Private network 2 connects to the public 179 Internet through NAT 2. On the public Internet is a STUN server that 180 implements the relay usage. 182 /-----\ 183 // STUN \\ 184 | Server | 185 \\ // 186 \-----/ 188 +--------------+ Public Internet 189 ................| NAT 2 |....................... 190 +--------------+ 192 +--------------+ Private NET 2 193 ................| NAT 1 |....................... 194 +--------------+ 196 /-----\ 197 // STUN \\ 198 | Client | 199 \\ // Private NET 1 200 \-----/ 202 Figure 1 204 The STUN relay usage defines several new messages that add the 205 ability of the STUN server to act as a relay for packets. The client 206 sends an Allocate request to the server. This request is 207 authenticated by the server. The client can include requests for 208 specific ports, transport protocols and IP addresses to be allocated 209 by the STUN server. The STUN server honors these if it can, and then 210 generates a response to the Allocate request. This response informs 211 the client of the address and port allocated to it, called the 212 allocated transport address. This address and port resides on the 213 STUN server itself. 215 The allocation will remain active as long as the client refreshes it 216 with subsequent Allocate requests. A basic negotiation mechanism is 217 defined which allows the client to request a specific lifetime, and 218 for the server to lower it and indicate the actual lifetime. 220 Once the client has obtained the allocated address from the STUN 221 server, it can use it to receive packets. However, when a packet 222 arrives at the allocated address, the STUN server does not forward 223 the packet. Instead, it will only forward a packet received from 224 some corresponent X if the client had previously sent a packet to X 225 through the relay. In that way, the relay is much like a NAT itself. 227 To send a packet through the relay towards some correspondent X, the 228 client issues a Send Indication to the STUN server. This indication 229 includes the destination address and port where the packet should be 230 sent to, and the data to send. The relay takes the data, and sends 231 it to X. It also adds a permission towards X, so that X can now send 232 packets to the allocated address, and the STUN server will relay 233 those towards the client. The clients are relayed towards the client 234 by encapsulating them in a Data Indication. This is a STUN 235 Indication which contains the data that was received by the STUN 236 server, along with the identity of the correspondent. 238 Since the primary usage of the STUN relay usage is in support of 239 multimedia communications, efficiency is a key design goal of this 240 STUN extension. The mechanism described so far will allow a client 241 behind the NAT to communicate with a correspondent. However, all 242 packets sent to and from the client will be encapsulated as STUN 243 Indications; a Send indication for data sent from the client to the 244 STUN server, and a Data indication for packets from the STUN server 245 to the client. This encapsulation adds 44 bytes to each packet. 246 With voice contents typically around 30 bytes (30 milliseconds of 247 G.729), this is a significant amount of overhead. 249 To optimize it, the relay usage provides a cut-through technique. 250 When the client has decided it would like to optimize the 251 transmission of packets with a particular correspondent, it issues a 252 Set Active Destination request to the server, and provides the IP 253 address and port of the correspondent. After a brief time during 254 which the client and server can determine they are synchronized on 255 the usage of the mechanism, the server enables an optimized path. 257 Packets received from this correspondent are relayed to the client 258 without encapsulation in a STUN Data indication, and the client can 259 send unencapsulated packets to the server, which will be forwarded 260 towards the correspondent. This mechanism requires the STUN server 261 and client to disambiguate STUN from other packets when received on 262 the same IP address and port. That is provided by the magic cookie 263 field in the STUN message. This cookie reduces the likelihood of a 264 data packet from being confused with a STUN packet to 2.32x10^-10, 265 which is deemed sufficiently unlikely. 267 To do all of this, the STUN server will maintain a binding between an 268 internal 5-tuple and 1 or more external 5-tuples, as shown in 269 Figure 2. The internal 5-tuple represents the "connection" between 270 the STUN server and the STUN client. It is the actual connection in 271 the case of TCP, and in the case of UDP, it is the combination of the 272 IP address and port from which the STUN client sent its Allocate 273 Request, with the IP address and port to which that Allocate Request 274 was sent. The external local transport address is the IP address and 275 port allocated to the STUN client (the allocated transport address). 276 The external 5-tuple is the combination of the external local 277 transport address and the IP address and port of an external client 278 that the STUN client is communicating with through the STUN server. 279 Initially, there aren't any external 5-tuples, since the STUN client 280 hasn't communicated with any other hosts yet. As packets are 281 received on or sent from the allocated transport address, external 282 5-tuples are created. 284 +---------+ 285 | | 286 | External| 287 / | Client | 288 // | | 289 / | | 290 // +---------+ 291 / 292 // 293 +-+ / 294 | | / 295 | | // 296 +---------+ | | +---------+ / +---------+ 297 | | |N| | | // | | 298 | STUN | | | | |/ | External| 299 | Client |----|A|----------| STUN |------------------| Client | 300 | | | |^ ^| Server |^ ^| | 301 | | |T|| || || || | 302 +---------+ | || |+---------+| |+---------+ 303 ^ | || | | | 304 | | || | | | 305 | +-+| | | | 306 | | | | | 307 | 308 Internal Internal External External 309 Client Remote Local Local Remote 310 Performing Transport Transport Transport Transport 311 Allocations Address Address Address Address 313 | | | | 314 +-----+----+ +--------+-------+ 315 | | 316 | | 318 Internal External 319 5-Tuple 5-tuple 321 Figure 2 323 5. Applicability Statement 325 STUN requires all usages to define the applicability of the usage 326 [1]. This section contains that information for the relay usage. 328 The relayed transport address obtained from the Allocate request has 329 specific properties which limit its applicability. The transport 330 address will only be useful for applications that require a client to 331 place a transport address into a protocol message, with the 332 expectation that the client will be able to receive packets from a 333 small number of hosts (typically one), and only after sending packets 334 towards those hosts. Because of this limitation, relayed transport 335 addresses obtained from an Allocate request are only useful when 336 combined with rendezvous protocols of some sort, which allow the 337 client to discover the addresses of the hosts it will be 338 corresponding with. Examples of such protocols include the Session 339 Initiation Protocol (SIP) [6]. 341 This limitation is purposeful. Because a client must send a packet 342 to a peer before it can receive packets from that peer, relayed 343 transport addresses obtained from the Allocate request can not be 344 used to run general purpose servers, such as a web or email server. 345 This means that the relay usage can be safely permitted to pass 346 through NATs and firewalls without fear of compromising the purpose 347 of having them there in the first place. Indeed, a relayed transport 348 address obtained from TURN has many of the properties of a transport 349 address obtained from a NAT whose filtering policies are address 350 dependent, but whose mapping properties are endpoint independent 351 [15], and thus "good" NATs. Indeed, to some degree, the relay turns 352 a bad NAT into a good NAT by, quite ironically, adding another NAT 353 function - the relay itself. 355 6. Client Discovery of Server 357 STUN requires all usages to define the mechanism by which a client 358 discovers the server [1]. This section contains that information for 359 the relay usage. 361 The relay usage differs from the other usages defined in [1] in that 362 it demands substantial resources from the STUN server. In addition, 363 it seems likely that administrators might want to block connections 364 from clients to the STUN server for relaying separated from 365 connections for the purposes of binding discovery. As a consequence, 366 the relay usage is defined to run on a separate port from other 367 usages. The client discovers the address and port of the STUN server 368 for the relay usage using the same DNS procedures defined in [1], but 369 using an SRV service name of "stun-relay" instead of just "stun". 371 [[TODO: Still need to sort out discovery for TLS vs. non-TLS, usage 372 of NAPTR, and so on.]] 374 7. Server Determination of Usage 376 STUN requires all usages to define the mechanism by which the server 377 determines the usage [1]. This section contains that information for 378 the relay usage. 380 The relay usage is defined by a specific set of requests and 381 indications. As a consequence, the server knows that this usage in 382 being used because those request and indications were used. 384 8. New Requests and Indications 386 This usage defines two new requests (along with their success and 387 error responses) and two indications. It also defines processing 388 rules for the STUN server and client on receipt of non-STUN messages. 389 See Section 11 and Section 12 391 The new messages are: 393 0x0003 : Allocate Request 394 0x0103 : Allocate Response 395 0x0113 : Allocate Error Response 396 0x0004 : Send Indication 397 0x0115 : Data Indication 398 0x0006 : Set Active Destination Request 399 0x0106 : Set Active Destination Response 400 0x0116 : Set Active Destination Error Response 401 0x0007 : Connect Request 402 0x0107 : Connect Response 403 0x0117 : Connect Error Response 405 The server will receive the Allocate Request, Send Indiaction and Set 406 Active Destination Request on the transport address it has advertised 407 in DNS or that has been provided to clients through configuration. 408 However, the server will also receive non-STUN packets, meant for 409 relaying, on this port. STUN packets are disambiguated from data 410 packets through the MAGIC-COOKIE in the STUN header. Similarly, the 411 client will receive Allocate Responses, Allocate Error Responses, 412 Data Indications, Set Active Destination Responses, and Set Active 413 Destination Error Responses on the ephemeral port it uses to connect 414 to the STUN server. It will also receive non-STUN packets, relayed 415 to it by the STUN server, on this port. Like the server, it 416 disambiguates STUN and non-STUN packets through the presence of the 417 magic cookie. 419 [[OPEN ISSUE: The usage of a magic cookie in the STUN header provides 420 a nice, generic way to disambiguate stun from application packets for 421 the turn usage, as well as sip-outbound, ice and other applications. 422 But, it introduces a problem as a consequence of this generalization. 423 When TURN is used with ICE, the agents will send p2p stun 424 connectivity checks through the turn relay. These being valid stun 425 packets, will also have the same magic cookie, and be processed by 426 the turn server, rather than the ice agent! The proposed remedy for 427 this is to use the DESTINATION-ADDRESS attribute in Allocate 428 requests, indicating the server to which the request is targeted. If 429 the turn server picks up a packet because of a magic cookie, but the 430 destination-address is not it or not there, it would forward the 431 packet as a regular datagram. ]] 433 8.1 Allocate Request 435 8.1.1 Server Behavior 437 The server first processes the request according to the general 438 request processing rules in [1]. This includes performing 439 authentication and checking for mandatory unknown attributes. Due to 440 the fact that the STUN server is allocating resources for processing 441 the request, Allocate requests MUST be authenticated, and 442 furthermore, MUST be authenticated using either a shared secret known 443 between the client and server, or a short term password derived from 444 it. 446 Note that Allocate requests, like all other STUN requests, can be 447 sent to the STUN server over UDP, TCP, or TCP/TLS. 449 The behavior of the server when receiving an Allocate Request depends 450 on whether the request is an initial one, or a subsequent one. An 451 initial request is one whose source and destination transport address 452 matches the internal remote and local transport addresses of an 453 existing internal 5-tuple. A subsequent request is one whose source 454 and destination transport address do not match the internal remote 455 and local transport address of an existing internal 5-tuple. 457 8.1.1.1 Initial Requests 459 The server attempts to allocate transport addresses. It first looks 460 for the BANDWIDTH attribute for the request. If present, the server 461 determines whether or not it has sufficient capacity to handle a 462 binding that will generate the requested bandwidth. 464 If it does, the server attempts to allocate a transport address for 465 the client. The Allocate request can contain several additional 466 attributes that allow the client to request specific characteristics 467 of the transport address. First, the server checks for the 468 REQUESTED-TRANSPORT attribute. This indicates the transport protocol 469 requested by the client. This specification defines values for UDP 470 and TCP. The server MUST allocate a port using the requested 471 transport protocol. If the REQUESTED-TRANSPORT attribute contains a 472 value of the transport protocol unknown to the server, or known to 473 the server but not supported by the server, the server MUST reject 474 the request and include a 442 (Unsupported Transport Protocol) in the 475 response, or else redirect the request. [[OPEN ISSUE: Should we 476 include a list of supported ones? Is this really an issue? If its 477 just ever TCP and UDP its not needed. Can always add it later, as 478 the hooks are here.]]. If the request did not contain a REQUESTED- 479 TRANSPORT attribute, the server MUST use the same transport protocol 480 as the request arrived on. 482 As a consequence of the REQUESTED-TRANSPORT attribute, it is possible 483 for a client to connect to the server over UDP and request a TCP 484 transport address, and for it to connect to the server over TCP (and 485 TLS, which uses TCP) and request a UDP transport address. In such a 486 case, the server will relay data between them. 488 Next, the server checks for the REQUESTED-IP attribute. If present, 489 it indicates a specific interface from which the client would like 490 its transport address allocated. If this interface is not a valid 491 one for allocations on the server, the server MUST reject the request 492 and include a 443 (Invalid IP Address) error code in the response, or 493 else redirect the request to a server that is known to support this 494 IP address. If the IP address is one that is valid for allocations 495 (presumably, the server is configured to know the set of IP addresses 496 from which it performs allocations), the server MUST provide an 497 allocation from that IP address. If the attribute was not present, 498 the selection of an IP address is at the discretion of the server. 500 Finally, the server checks for the REQUESTED-PORT attribute. If 501 present, it indicates a specific port property desired by the client. 502 If the property is for a Specific Port, the server MUST attempt to 503 allocate that specific port for the client. If the port is not 504 available, the server MUST reject the request with a 444 (Invalid 505 Port) response or redirect to an alternate server. If the property 506 is for an even port, the server MUST attempt to allocate an even port 507 for the client. If an even port cannot be obtained, the server MUST 508 reject the request with a 444 (Invalid Port) response or redirect to 509 an alternate server. If the property is for an odd port, the server 510 MUST attempt to allocate an odd port for the client. If an odd port 511 cannot be obtained, the server MUST reject the request with a 444 512 (Invalid Port) response or redirect to an alternate server. Finally, 513 the Even port with hold of the next higher port is similar to Even 514 port. It is a request for an even port, and MUST be rejected by the 515 server if an even port cannot be provided, or redirected to an 516 alternate server. However, it is also a hint from the client that 517 the client will request the next higher port with a separate Allocate 518 request. As such, it is a request for the server to allocate an even 519 port whose one higher port is also available, and furthermore, a 520 request for the server to not allocate that one higher port to any 521 other request except for one that asks for that port explicitly. The 522 server can honor this request for adjacency at its discretion. The 523 only constraint is that the allocated port has to be even. 525 If any of the requested or desired constraints cannot be met, whether 526 it be bandwidth, transport protocol, IP address or port, instead of 527 rejecting the request, the server can alternately redirect the client 528 to a different server that may be able to fulfill the request. This 529 is accomplished using the 300 error response and ALTERNATE-SERVER 530 attribute. 532 Furthermore, if the clients source port was in the range 1024-65535, 533 it is RECOMMENDED that the server allocate a port in that range. If 534 the clients source port was in the range of 1-1024, port selection is 535 at the discrtion of the administrator. It is RECOMMENDED that a port 536 in the range of 1024-65535 be allocated. This is one of several ways 537 to prohibit relayed transport addresses from being used to attempt to 538 run standard services. These guidelines are meant to be consistent 539 with [15], since the relay is effectively a NAT. 541 Once the port is allocated, the server associates it with the 542 internal 5-tuple and fills in that 5-tuple. The internal remote 543 transport address of the internal 5-tuple is set to the source 544 transport address of the Allocate Request. The internal local 545 transport address of the internal 5-tuple is set to the destination 546 transport address of the Allocate Request. For TCP, this amounts to 547 associating the TCP connection from the TURN client with the 548 allocated transport address. 550 If the Allocate request was authenticated using a shared secret 551 between the client and server, this credential MUST be associated 552 with the allocation. If the request was authenticated using a short 553 term password derived from a shared secret, that shared secret MUST 554 be associated with the allocation. This is used in subsequent 555 Allocate requests to ensure that only the same client can refresh or 556 modify the characteristics of the allocation it was given. 558 The allocation created by the Allocate request is also associated 559 with a transport address, called the active destination. This 560 transport address is used for forwarding data through the TURN 561 server, and is described in more detail later. It is initially set 562 to null when the allocation is created. In addition, the allocation 563 created by the server is associated with a set of permissions. Each 564 permission is a specific IP address identifying an external client. 566 Initially, this list is null. Send Indications, Connect requests and 567 Set Active Destination requests add values to this list. 569 If the LIFETIME attribute was present in the request, and the value 570 is larger than the maximum duration the server is willing to use for 571 the lifetime of the allocation, the server MAY lower it to that 572 maximum. However, the server MUST NOT increase the duration 573 requested in the LIFETIME attribute. If there was no LIFETIME 574 attribute, the server may choose a default duration at its 575 discretion. In either case, the resulting duration is added to the 576 current time, and a timer, called the allocation expiration timer, is 577 set to fire at or after that time. Section 12.3 discusses behavior 578 when the timer fires. Note that the LIFETIME attribute in the 579 request can be zero. This typically happens for subsequent 580 Allocations, and provides a mechanism to delete the allocation. It 581 will force the immediate firing of the allocation expiration timer. 583 Once the port has been obtained from the operating system and the 584 activity timer started for the port binding, the server generates an 585 Allocate Response using the general procedures defined in [1]. The 586 transport address allocated to the client MUST be included in the 587 RELAY-ADDRESS attribute in the response. In addition, this response 588 MUST contain the MAPPED-ADDRESS attribute. This allows the client to 589 determine its reflexive transport address in addition to a relayed 590 transport address, from the same Allocate request. 592 The server MUST add a LIFETIME attribute to the Allocate Response. 593 This attribute contains the duration, in seconds, of the allocation 594 expiration timer associated with this allocation. 596 The server MUST add a BANDWIDTH attribute to the Allocate Response. 597 This MUST be equal to the attribute from the request, if one was 598 present. Otherwise, it indicates a per-binding cap that the server 599 is placing on the bandwidth usage on each binding. Such caps are 600 needed to prevent against denial-of-service attacks (See Section 13. 602 The server MUST add, as the final attribute of the request, a 603 MESSAGE-INTEGRITY attribute. The key used in the HMAC MUST be the 604 same as that used to validate the request. 606 If the allocated port was for TCP, the server MUST be prepared to 607 receive a TCP connection request on that port. 609 8.1.1.2 Subsequent Requests 611 A subsequent Allocate request is one received whose source and 612 destination IP address and ports match the internal 5-tuple of an 613 existing allocation. The request is processed used the general 614 server procedures in [1] and is processed identically to 615 Section 8.1.1.1, with a few important exceptions. 617 First, the request MUST be authenticated using the same shared secret 618 as the one associated with the allocation, or be authenticated using 619 a short term password derived from that shared secret. If the 620 request was authenticated but not with such a matching credential, 621 the server MUST generate an Allocate Error Response with a 441 622 response code. 624 Secondly, if the allocated transport address given out previously to 625 the client still matches the constraints in the request (in terms of 626 request ports, IP addresses and transport protocols), the same 627 allocation granted previously MUST be returned. However, if one of 628 the constraints is not met any longer, because the client changed 629 some aspect of the request, the server MUST free the previous 630 allocation and allocate a new request to the client. 632 Finally, a subsequent Allocate request will set a new allocation 633 expiration timer for the allocation, effectively canceling the 634 previous timer that was running. 636 8.1.2 Client Behavior 638 Client behavior for Allocate requests depends on whether the request 639 is an initial one, for the purposes of obtaining a new relayed 640 transport address, or a subsequent one, used for refreshing an 641 existing allocation. 643 8.1.2.1 Initial Requests 645 When a client wishes to obtain a transport address, it sends an 646 Allocate Request to the server. This request is constructed and sent 647 using the general procedures defined in [1]. The server will 648 challenge the request for credentials. The client MAY either provide 649 its credentials to the server directly, else obtain a short-term set 650 of credentials using the Shared Secret request, and then use those as 651 the credentials in the Allocate request. 653 The client SHOULD include a BANDWIDTH attribute, which indicates the 654 maximum bandwidth that will be used with this binding. If the 655 maximum is unknown, the attribute is not included in the request. 657 The client MAY request a particular lifetime for the allocation by 658 including it in the LIFETIME attribute in the request. 660 The client MAY include a REQUESTED-PORT, REQUESTED-TRANSPORT, or 661 REQUESTED-IP attribute in the request to obtain specific types of 662 transport addresses. Whether these are needed depends on the 663 application using the relay usage. As an example, the Real Time 664 Transport Protocol (RTP) [5] requires that RTP and RTCP ports be even 665 and odd respectively, and contiguous. The REQUESTED-PORT attribute 666 allows the client to ask the relay for those properties. 668 Processing of the response follows the general procedures of [1]. A 669 successful response will include both a RELAY-ADDRESS and MAPPED- 670 ADDRESS attribute, providing both a relayed transport address and a 671 reflexive transport address, respectively, to the client. The server 672 will expire the allocation after LIFETIME seconds have passed if not 673 refreshed by another Allocate request. The server will allow the 674 user to send and receive no more than the amount of data indicated in 675 the BANDWIDTH attribute. 677 If the response is an error response and contains a 442, 443 or 444 678 error code, the client knows that its requested properties could not 679 be met. The client MAY retry with different properties, with the 680 same properties (in a hope that something has changed on the server), 681 or give up, depending on the needs of the application. However, if 682 the client retries, it SHOULD wait 500ms, and if the request fails 683 again, wait 1 second, then 2 seconds, and so on, exponentially 684 backing off. 686 8.1.2.2 Subsequent Requests 688 Before 3/4 of the lifetime of the allocation has passed (the lifetime 689 of the allocation is conveyed in the LIFETIME attribute of the 690 Allocate Response), the client SHOULD refresh the allocation with 691 another Allocate Request if it wishes to keep the allocation. 693 To perform a refresh, the client generates an Allocate Request as 694 described in Section 8.1.2.1. If the initial request was 695 authenticated with a shared secret P that the client holds with the 696 server, or using a short term password derived from P through a 697 Shared Secret request, the client MUST use shared secret P, or a 698 short-term password derived from it, in the subsequent request. 700 In a successful response, the RELAY-ADDRESS contains the same 701 transport address as previously obtained, indicating that the binding 702 has been refreshed. The LIFETIME attribute indicates the amount of 703 additional time the binding will live without being refreshed. Note 704 that an error response do not imply that the binding has been 705 expired, just that the refresh has failed. 707 If the client wishes to explicitly remove the allocation because it 708 no longer needs it, it generates a subsequent Allocate request, but 709 sets the LIFETIME attribute to zero. This will cause the server to 710 remove the allocation. 712 8.2 Connect Request 714 The Connect Request is used by a client when it has obtained an 715 allocated transport address that is TCP. The Connect request asks 716 the server to open a TCP connection to a specified destination 717 address, included in the request. 719 8.2.1 Server Behavior 721 Once the server has identified a request as a Connect request, the 722 server verifies that it has arrived with a source and destination 723 transport address that matches the internal remote and local 724 transport address of an internal 5-tuple associated with an existing 725 allocation. If there is no matching allocation, the server MUST 726 generate a 437 (No Binding) Send Error Response. 728 The request MUST be authenticated using the same shared secret as the 729 one associated with the allocation, or be authenticated using a short 730 term password derived from that shared secret. If the request was 731 authenticated but not with such a matching credential, the server 732 MUST generate an error response with a 441 response code. 734 If the allocation is not for TCP, the server MUST reject the request 735 with a 445 (Operation for TCP Only) response. 737 If the request does not contain a DESTINATION-ADDRESS attribute, the 738 server sends a Connect response, but otherwise does nothing. 740 If the request contains a DESTINATION-ADDRESS attribute, the IP 741 address contained within it is added to the permissions for this 742 allocation, if it was not already present. This happens regardless 743 of whether the subsequent TCP connection attempt succeeds or not. 745 The server then checks to see if it has any TCP connections in 746 existence from the allocated transport address to the IP address and 747 port in DESTINATION-ADDRESS. If it does, the server responds to the 748 request with a Connect response, indicating to the client that a 749 connection exists already. 751 Next, the server attempts to open a TCP connection from the allocated 752 transport address to the IP address and port in the DESTINATION- 753 ADDRESS attribute. If the connection succeeds, the server generates 754 a Connect Response. If the connection attempt fails or times out, 755 the server generates a Connect Error Response and includes an error 756 response of 446 (Connection Failure). If the connection attempt is 757 still pending prior to the the timeout of the STUN transaction, the 758 server MUST send a 447 (Connection Timeout) error response. However, 759 the server continues to wait for the connection to get set up. If it 760 succeeds, the client holds on to the connection. The client can 761 retry the request at a later time, and if the connection has been 762 succesfully setup, it will result in a Success Response as described 763 above. 765 8.2.2 Client Behavior 767 If a client wishes to send data towards a peer on a TCP allocated 768 transport address, the client must first tell the server to open a 769 TCP connection towards the destination. To do that, the client sends 770 a Connect request to the server. The client MUST NOT send this 771 request for non-TCP allocated transport addresses. The request 772 SHOULD contain a DESTINATION-ADDRESS attribute indicating the desired 773 target for the connection attempt. 775 If the Connect request generates a successful response, it means that 776 a connection was opened, or was already opened, towards DESTINATION- 777 ADDRESS. If it generates a Connect Error response with a response 778 code of 446, it means that the servers attempt at the connection has 779 failed. If it generates a Connect Error response with a response 780 code of 447, it means that the server is still trying to connect, but 781 the attempt could not be completed before the STUN transaction needed 782 to end. Whether the client wishes to retry depends on the 783 application using the request. If the client wishes to determine the 784 disposition of the attempt, it MAY send a Connect request with the 785 same DESTINATION-ADDRESS at a later time. 787 [[OPEN ISSUE: yes, this is a hack. STUN transactions were designed 788 for immediate responses, and so the handshake is two-way, like SIP 789 non-INVITE. However, I am reluctant to include yet another new 790 transaction to SIP. The alternative to the above design is to have 791 the server send a request to the client when the connection 792 completes.]] 794 If the Connect request generates a 437, it means that the client's 795 allocation no longer exists, possibly due to server or network 796 failures. The client MAY obtain a new allocation if the application 797 so desires. 799 8.3 Set Active Destination Request 801 8.3.1 Server Behavior 803 The Set Active Destination Request is used by a client to set an 804 external 5-tuple that will be used as the forwarding destination of 805 all data that isn't to be processed by the STUN server itself. In 806 addition, all data received from that external client will be 807 forwarded to the STUN client without encapsulation in a Data 808 Indication. 810 Once the server has identified a request as a Set Active Destination 811 request, the server verifies that it has arrived with a source and 812 destination transport address that matches the internal remote and 813 local transport address of an internal 5-tuple associated with an 814 existing allocation. If there is no matching allocation, the server 815 MUST generate a 437 (No Binding) Send Error Response. 817 The request MUST be authenticated using the same shared secret as the 818 one associated with the allocation, or be authenticated using a short 819 term password derived from that shared secret. If the request was 820 authenticated but not with such a matching credential, the server 821 MUST generate an error response with a 441 response code. 823 If the Set Active Destination request contains a DESTINATION-ADDRESS 824 attribute, the IP address contained within it is added to the 825 permissions for this allocation, if it was not already present. 827 Unfortunately, there is a race condition associated with the active 828 destination concept. Consider the case where the active destination 829 is set, and the server is relaying packets towards the client. The 830 client knows the IP address and port where the packets came from - 831 the current value of the active destination. The client issues a Set 832 Active Destination Request to change the active destination, and 833 receives a response. A moment later, a data packet is received, not 834 encapsulated in a STUN Data Indication. What is the source if this 835 packet? Is it the active destination that existed prior to the Set 836 Active Destination request, or the one after? If the transport 837 between the client and the STUN server is not reliable, there is no 838 way to know. 840 To deal with this problem, a small state machine is used to force a 841 "cooldown" period during which the server will not relay packets 842 towards the client without encapsulating them. This cooldown period 843 gives enough time for the client to be certain that any old data 844 packets have left the network. Once the cooldown period ends, the 845 server can begin relaying packets without encapsulation. There is an 846 instance of this state machine for each allocation. 848 +-----+ 849 | | Req Recvd, DA absent 850 | | 851 | | 852 | | 853 | V 854 +-----------+ 855 | | timer fires 856 | | ----------- 857 | None | active=null 858 | Set |<--------------------------------+ 859 | | | 860 | | | 861 +-----------+ | 862 | | Req Recvd 863 | | --------- 864 | Req Recvd, DA present | 439 865 | ---------------------- | +----+ 866 | active = DA | | | 867 | | | | 868 | | | | 869 V Req Recvd, | | V 870 +-----------+ DA!=active,absent +-----------+ 871 | | ----------------- | | 872 | | Set timer | | 873 | Set |------------------------------>| Trans- | 874 | | | itioning | 875 | |<------------------------------| | 876 | | timer fires | | 877 +-----------+ ----------- +-----------+ 878 | ^ active=DA 879 | | 880 | | 881 | | 882 +-----+ 883 Req Recvd, DA=active 885 Figure 4 887 When the allocation is originally created, the active destination is 888 null, and the server sets the state to "None Set". In this state, 889 the server will relay all received packets in encapsulated form 890 towards the client. If the server receives a Set Active Destination 891 request, but the request contained no DESTINATION-ADDRESS attribute, 892 the state machine stays in the same state. The request is responded 893 to with a Set Active Destination Response. If, however, the Set 894 Active Destination request contained a DESTINATION-ADDRESS, the 895 server sets the active destination to the transport address from the 896 DESTINATION-ADDRESS attribute, and enters the "Set" state. The 897 request is responded to with a Set Active Destination Response. In 898 this state, the server will relay packets from that transport address 899 towards the client in unencapsulated form. 901 If the server receives another Set Active Destination request while 902 in this state, and the DESTINATION-ADDRESS is present, but has a 903 value equal to the current active destination, the request causes no 904 change. The request is responded to with a Set Active Destination 905 Response. If, however, the request contained a DESTINATION-ADDRESS 906 which did not match the existing active destination, or omitted the 907 active destination, the server enters the "transitioning" state. The 908 request is responded to with a Set Active Destination Response. In 909 this state, the server will forward all packets to the client in 910 encapsulated form. In addition, when this state is entered, the 911 client sets a timer to fire in Ta seconds. If the connection between 912 the client and server is unreliable, this timer SHOULD be 913 configurable. It is RECOMMENDED that it be set to three seconds. If 914 the connection between the client and server is reliable, the timer 915 SHOULD be set to 0 seconds, causing it to fire immediately. This 916 makes the transitioning state transient for reliable transports. The 917 value of the timer used by the server, regardless of the transport 918 protocol, MUST be included in a TIMER-VAL attribute in the Set Active 919 Destination response. 921 If, while in the "transitioning" state, the server receives a Set 922 Active Destination Request, it generates a Set Active Destination 923 Error Response that includes a 439 (Transitioning) response code. 924 Once the timer fires, the server transitions to the "Set" state if 925 the Set Active Destination request that caused the server to enter 926 "transitioning" had contained the DESTINATION-ADDRESS. In this case, 927 the active destination is set to this transport address. If the Set 928 Active Destination request had not contained a DESTINATION-ADDRESS 929 attribute, the server enters the "Not Set" state and sets the active 930 destination to null. 932 8.3.2 Client Behavior 934 The Set Active Destination address allows the client to create an 935 optimized relay function between it and the server. When the server 936 receives packets from a particular preferred external client, the 937 server will forward those packets towards the client without 938 encapsulating them in a Data Indication. Similarly, the client can 939 send non-STUN packets to the server without encapsulation, and these 940 are forwarded to the external client. Sending and receiving data in 941 unencapsulated form is critical for efficiency purposes. One of the 942 primary use cases for the STUN relay usage is in support of Voice 943 over IP (VoIP), which uses very small UDP packets to begin with. The 944 extra overhead of an additional layer of encapsulation is considered 945 unacceptable. 947 The Set Active Destination request is used by the client to provide 948 the identity of this preferred external client. The request also has 949 the side effect of adding a permission for the target of the 950 DESTINATION-ADDRESS. 952 The Set Active Destination address MAY contain a DESTINATION-ADDRESS 953 attribute. This attribute, when present, provides the address of the 954 preferred external client to the server. When absent, it clears the 955 value of the preferred external client. 957 In order for the client to know where incoming non-STUN packets were 958 sent from, and to be sure where non-STUN packets sent to the server 959 will go to, it is necessary to coordinate the value of the active 960 destination between the client and the server. As discussed above, 961 there is a race condition involved in this coordination which 962 requires a state machine to execute on both the client and the 963 server. 965 +-----+ 966 | | OK Recvd, DA absent 967 | | 968 | | 969 | | 970 | V 971 +-----------+ 972 439 Recvd| | timer fires 973 +------| | ----------- 974 | | None | active=null 975 | | Set |<--------------------------------+ 976 +----->| | | 977 | | | 978 +-----------+ | 979 | | 980 | | 981 | OK Recvd, DA present | 982 | ---------------------- | 983 | active = DA | 984 | | 985 | | 986 V OK Recvd, | 987 +-----------+ DA!=active,absent +-----------+ 988 | | ----------------- | | 989 | | Set timer | | 990 | Set |------------------------------>| Trans- | 991 | | | itioning | 992 | |<------------------------------| | 993 | | timer fires | | 994 +-----------+ ----------- +-----------+ 995 | ^ active=DA 996 | | 997 | | 998 | | 999 +-----+ 1000 439 Recvd, 1001 OK Recvd, DA=active 1003 Figure 5 1005 The state machine is shown in Figure 5. The client starts in the 1006 "None Set" state. When the client is in either the "None Set" or 1007 "Set" state, it can send Set Active Destination requests. The 1008 transitions in the state machines are governed by responses to those 1009 requests. Only success and 439 responses cause changes in state. A 1010 437 response implies that the allocation has been removed, and thus 1011 the state machine destroyed. A client MUST NOT send a new Set Active 1012 Destination request prior to the receipt of a response to the 1013 previous. The state machine will further limit the transmission of 1014 subsequent Set Active Destination requests. 1016 If, while in the "None Set" state, the client sent a Set Active 1017 Destination request without a DESTINATION-ADDRESS, and got a 1018 successful response, there is no change in state. If a successful 1019 response was received, but there was a DESTINATION-ADDRESS in the 1020 request, the state machine transitions to the "Set" state, and the 1021 client sets the active destination to the value of the DESTINATION- 1022 ADDRESS attribute that was in the request. 1024 If, while in the "Set" state, the client sends a Set Active 1025 Destination request and received a 439 response, it means that there 1026 was a temporal misalignment in the states between client and server. 1027 The client thought that the active destination was updated on the 1028 server, but the server was still in its transitioning state. When 1029 this error is received, the client remains in the "Set" state. The 1030 client SHOULD retry its Set Active Destination request, but no sooner 1031 than 500ms after receipt of the 439 response. In addition, if, while 1032 in the "Set" state, the client sends a Set Active Destination request 1033 whose DESTINATION-ADDRESS attribute equals the current active 1034 destination, and that request generates a success response, the 1035 client remains in the "Set" state. 1037 However, if, while in the "Set" state, the client sends a Set Active 1038 Destination request whose DESTINATION-ADDRESS was either absent or 1039 not equal to the current active destination, and receives a success 1040 response, the client enters the "Transitioning" state. While in this 1041 state, the client MUST NOT send a new Set Active Destination request. 1042 The value of the active destination remains unchanged. In addition, 1043 the client sets a timer. This timer MUST have a value equal to the 1044 value of the TIMER-VAL attribute from the Set Active Destination 1045 response. This is necessary for coordinating the state machines 1046 between client and server. 1048 Once the timer fires, if the DESTINATION-ADDRESS was not absent from 1049 the Set Active Destination request which caused the client to start 1050 the timer, the client moves back to the "Set" state, and then updates 1051 the value of the active destination to the value of DESTINATION- 1052 ADDRESS. If DESTINATION-ADDRESS was absent, the client sets the 1053 active destination to null and enders the "None Set" state. 1055 8.4 Send Indication 1057 8.4.1 Server Behavior 1059 A Send Indication is sent by a client after it has completed its 1060 Allocate transaction, in order to create permissions in the server 1061 and send data to an external client. 1063 Once the server has identified a message as a Send Indication, the 1064 server verifies that it has arrived with a source and destination 1065 transport address that matches the internal remote and local 1066 transport address of an internal 5-tuple associated with an existing 1067 allocation. If there is no matching allocation, the indication is 1068 discarded. If there was no DESTINATION-ADDRESS, the indication is 1069 discarded. If there was no DATA attribute, the indication is 1070 discarded. 1072 [[OPEN ISSUE: should message integrity checks be done for send? THey 1073 cannot be challenged!]] 1075 The server takes the contents of the DATA attribute present in the 1076 indication. If the allocation was a UDP allocation, the server 1077 creates a UDP packet whose payload equals that content. The server 1078 sets the source IP address of the packet equal to the allocated 1079 transport address. The destination transport address is set to the 1080 contents of the DESTINATION-ADDRESS attribute. The server then sends 1081 the UDP packet. Note that any retransmissions of this packet which 1082 might be needed are not handled by the server. It is the clients 1083 responsibility to generate another Send indication if needed. If the 1084 TURN client hasn't previously sent to this destination IP address and 1085 port, an external 5-tuple is instantiated in the TURN server. Its 1086 local and remote transport addresses, respectively, are set to the 1087 source and destination transport addresses of the UDP packet. 1089 The server then adds the IP address of the DESTINATION-ADDRESS 1090 attribute to the permission list for this allocation. 1092 In the case of a TCP allocation, the server checks if it has an 1093 existing TCP connection open from the allocated transport address to 1094 the address in the DESTINATION-ADDRESS attribute. If so, the server 1095 extracts the content of the DATA attribute and sends it on the 1096 matching TCP connection. If the server doesn't have an existing TCP 1097 connection to the destination, it discards the data and does nothing. 1098 The client must first open a TCP connection with the Connect request 1099 before it can send data. 1101 8.4.2 Client Behavior 1103 Before receiving any UDP or TCP data, a client has to send first. 1104 Prior to the establishment of an active destination, or while the 1105 client is in the transitioning state, transmission of data towards a 1106 peer through the relay is done using the Send Indication. Indeed, if 1107 the client is in the transitioning state, and it wishes to send data 1108 through the relay, it MUST use a Send indication. 1110 For TCP allocated transport addresses, the client MUST first open a 1111 connection towards an external client with a Connect request prior to 1112 using the Send request. Data sent with a Send request prior to the 1113 opening of a TCP connection is discarded silently by the server. 1115 The Send Indication MUST contain a DESTINATION-ADDRESS attribute, 1116 which contains the IP address and port that the data is being sent 1117 to. The DATA attribute MAY be present, and contains the data that is 1118 to be sent towards DESTINATION-ADDRESS. If absent, the server will 1119 send an empty UDP packet in the case of UDP. In the case of TCP, the 1120 server will do nothing. 1122 Since Send is an Indication, it generates no response. The client 1123 must relay on application layer mechanisms to determine if the data 1124 was received by the peer. 1126 8.5 Data Indication 1128 8.5.1 Server Behavior 1130 A server MUST send data packets towards the client using a Data 1131 Indication under the conditions described in Section 12.1. Data 1132 Indications MUST contain a DATA attribute containing the data to 1133 send, and MUST contain a REMOTE-ADDRESS attribute indicating where 1134 the data came from. 1136 8.5.2 Client Behavior 1138 Once a client has obtained an allocation and created permissions for 1139 a particular external client, the server can begin to relay packets 1140 from that external client towards the client. If the external client 1141 is not the active destination, this data is relayed towards the 1142 client in encapsulated form using the Data Indication. 1144 The Data Indication contains two attributes - DATA and REMOTE- 1145 ADDRESS. The REMOTE-ADDRESS attribute indicates the source transport 1146 address that the request came from, and it will equal the external 1147 remote transport address of the external client. When processing 1148 this data, a client MUST treat the data as if it came from this 1149 address, rather than the stun server itself. The DATA attribute 1150 contains the data from the UDP packet or TCP segment that was 1151 received. Note that the TURN server will not retransmit this 1152 indication over UDP. 1154 9. New Attributes 1156 The STUN relay usage defines the following new attributes: 1158 0x000d: LIFETIME 1159 0x0010: BANDWIDTH 1160 0x0011: DESTINATION-ADDRESS 1161 0x0012: REMOTE-ADDRESS 1162 0x0013: DATA 1163 0x0016: RELAY-ADDRESS 1164 0x0018: REQUESTED-PORT 1165 0x0019: REQUESTED-TRANSPORT 1166 0x0020: REQUESTED-IP 1167 0x0021: TIMER-VAL 1169 9.1 LIFETIME 1171 The lifetime attribute represents the duration for which the server 1172 will maintain an allocation in the absence of data traffic either 1173 from or to the client. It is a 32 bit value representing the number 1174 of seconds remaining until expiration. 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Lifetime | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 9.2 BANDWIDTH 1182 The bandwidth attribute represents the peak bandwidth, measured in 1183 kbits per second, that the client expects to use on the binding. The 1184 value represents the sum in the receive and send directions. 1185 [[Editors note: Need to define leaky bucket parameters for this.]] 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Bandwidth | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 9.3 DESTINATION-ADDRESS 1193 The DESTINATION-ADDRESS is present in Send Indications and Set Active 1194 Destination Requests. It specifies the address and port where the 1195 data is to be sent. It is encoded in the same way as MAPPED-ADDRESS. 1197 [[OPEN ISSUE: Should some of thes be xor-encoded? I don't see a need 1198 really...]] 1200 9.4 REMOTE-ADDRESS 1202 The REMOTE-ADDRESS is present in Data Indications. It specifies the 1203 address and port from which a packet was received. It is encoded in 1204 the same way as MAPPED-ADDRESS. 1206 9.5 DATA 1208 The DATA attribute is present in Send Indications and Data 1209 Indications. It contains raw payload data that is to be sent (in the 1210 case of a Send Request) or was received (in the case of a Data 1211 Indication). 1213 9.6 RELAY-ADDRESS 1215 The RELAY-ADDRESS is present in Allocate responses. It specifies the 1216 address and port that the server allocated to the client. It is 1217 encoded in the same way as MAPPED-ADDRESS. 1219 9.7 REQUESTED-PORT 1221 This attribute allows the client to request certain properties for 1222 the port that is allocated by the server. The attribute can be used 1223 with any transport protocol that has the notion of a 16 bit port 1224 space (including TCP and UDP). The attribute is 32 bits long. Its 1225 format is: 1227 x 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Property | Port Filter | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 The property is an unsigned integer from 0 to 65535 which identifies 1233 the specific property that is desired. The meaning of the port 1234 filter depends on the port property, and is not used for certain port 1235 properties. 1237 This specification defines the following port properties: 1239 0x0000: Even Port 1240 0x0001: Odd Port 1241 0x0002: Even Port, hold next higher port 1242 0x0003: Specific Port 1244 Even Port is a request to the server to allocate a port with even 1245 parity. The port filter is not used with this property. Odd Port is 1246 a request to the server to allocate a port with odd parity. The port 1247 filter is not used with this property. Even port, with a hold on the 1248 next higher port, is a request to the server to allocate an even 1249 port. Furthermore, the client indicates that it will want the next 1250 higher port as well. As such, the client requests that the server, 1251 if it can, not allocate the next higher port to anyone unless that 1252 port is explicitly requested, which the client will itself do. The 1253 port filter is not used with this property. Finally, the Specific 1254 Port property is a request for a specific port. The port that is 1255 requested is contained in the Port filter. 1257 Extensions to the relay usage can define additional port properties. 1258 [[TODO: Add IANA registry]] 1260 9.8 REQUESTED-TRANSPORT 1262 This attribute is used by the client to request a specific transport 1263 protocol for the allocated transport address. It is a 32 bit 1264 unsigned integer. Its values are: 1266 0x0000 0000: UDP 1267 0x0000 0001: TCP 1269 If an Allocate request is sent over TCP and requests a UDP 1270 allocation, or an Allocate request is sent over UDP and requests a 1271 TCP allocation, the server will relay data between the two 1272 transports. 1274 Extensions to the relay usage can define additional transport 1275 protocols. [[TODO: Add IANA registry]] 1277 9.9 REQUESTED-IP 1279 The REQUESTED-IP attribute is used by the client to request that a 1280 specific IP address be allocated to it. This attribute is needed 1281 since it is anticipated that STUN relays will be multi-homed so as to 1282 be able to allocate more than 64k transport addresses. As a 1283 consequence, a client needing a second transport address on the same 1284 interface as a previous one can make that request. 1286 The format of this attribute is identical to MAPPED-ADDRESS. 1287 However, the port component of the attribute is ignored by the 1288 server. If a client wishes to request a specific IP address and 1289 port, it uses both the REQUESTED-IP and REQUESTED-PORT attributes. 1291 9.10 TIMER-VAL 1293 The TIMER-VAL attribute is used only in conjunction with the Set 1294 Active Destination response. It conveys from the server, to the 1295 client, the value of the timer used in the server state machine. 1296 Coordinated values are needed for proper operation of the mechanism. 1298 The attribute is a 32 bit unsigned integer representing the number if 1299 milliseconds used by the server for its timer. 1301 10. New Error Response Codes 1303 The STUN relay usage defines the following new Error response codes: 1305 437 (No Binding): A request was received by the server that 1306 requires an allocation to be in place. However, there is none yet 1307 in place. 1309 439 (Transitioning): A Set Active Destination request was received 1310 by the server. However, a previous request was sent within the 1311 last few seconds, and the server is still transitioning to that 1312 active destination. Please repeat the request later. 1314 441 (Wrong Username): A TURN request was received for an allocated 1315 binding, but it did not use the same username and password that 1316 were used in the allocation. The client must supply the proper 1317 credentials, and if it cannot, it should teardown its binding, 1318 allocate a new one time password, and try again. 1320 442 (Unsupported Transport Protocol): The Allocate request asked 1321 for a transport protocol to be allocated that is not supported by 1322 the server. 1324 443 (Invalid IP Address): The Allocate request asked for a 1325 transport address to be allocated from a specific IP address that 1326 is not valid on the server. 1328 444 (Invalid Port): The Allocate request asked for a port to be 1329 allocated that is not available on the server. 1331 445 (Operation for TCP Only): The client tried to send a request 1332 to perform a TCP-only operation on an allocation, and allocation 1333 is UDP. 1335 446 (Connection Failure): The attempt by the server to open the 1336 connection failed. 1338 447 (Connection Timeout): The attempt by the server to open the 1339 connection could not be completed, and is still in progress. 1341 11. Client Procedures 1343 If a client no longer needs a binding, it SHOULD tear it down. For 1344 TCP, this is done by closing the connection. For UDP, this is done 1345 by performing a refresh, as described in Section 8.1.2.2, but with a 1346 LIFETIME attribute indicating a time of 0. 1348 11.1 Receiving and Sending Unencapsulated Data 1350 Once the active destination has been set, a client will receive both 1351 STUN and non-STUN data on the socket on which the Allocate Request 1352 was sent. If the client receives non-STUN data (disambiguated 1353 through the magic cookie), it MUST be processed as if it had a source 1354 IP address and port equal to the value of the active destination. 1356 In addition, once the active destination has been set, if the client 1357 is in the "Set" state, it MAY send data to the active destination by 1358 sending data on that same socket. Unencapsulated data MUST NOT be 1359 sent while in the "Not Set" or "Transitioning" states. However, it 1360 is RECOMMENDED that the client not send unencapsulated data for 1361 approximately 500 milliseconds after the client enters the "Set" 1362 state. This eliminates any synchronization problems resulting from 1363 network delays. Of course, even if the active destination is set, 1364 the client can send data to that destination at any time by using the 1365 Send Indication. 1367 12. Server Procedures 1369 Besides the processing of the request and indications described 1370 above, this specification defines rules for processing of data 1371 packets received by the STUN server. There are two cases - receipt 1372 of any packets on an allocated address, and receipt of non-STUN data 1373 on its internal local transport address. 1375 12.1 Receiving Data on Allocated Transport Addresses 1377 12.1.1 TCP Processing 1379 If a server receives a TCP connection request on an allocated TCP 1380 transport address, it checks the permissions associated with that 1381 allocation. If the source IP address of the TCP SYN packet match one 1382 of the permissions, the TCP connection is accepted. Otherwise, it is 1383 rejected. No information is passed to the client about the 1384 acceptance of the connection; rather, data passed to the client with 1385 a source transport address it has not seen before serves this 1386 purpose. 1388 If a server receives data on a TCP connection that terminates on the 1389 allocated TCP transport address, the server checks the value of the 1390 active destination. If it equals the source IP address and port of 1391 the data packet (in other words, if the active destination identifies 1392 the other side of the TCP connection), the server checks the state 1393 machine of the allocation. If the state is "Set", the data is taken 1394 from the TCP connection and sent towards the client in unencapsulated 1395 form. Otherwise, the data is sent towards the client in a Data 1396 Indication, also known as encapsulated form. In this form, the 1397 server MUST add a REMOTE-ADDRESS which corresponds to the external 1398 remote transport address of the TCP connection, and MUST add a DATA 1399 attribute containing the data received on the TCP connection. 1401 Sending of the data towards the client, whether in encapsulated or 1402 unencapsulated form, depends on the linkage with the client. If the 1403 linkage with the client is over UDP, the data is placed in a UDP 1404 datagram and sent over the linkage. Note that the server will not 1405 retransmit this data to ensure reliability. If the linkage with the 1406 client is over TCP, the data is placed into the TCP connection 1407 corresponding to the linkage. If the TCP connection generates an 1408 error (because, for example, the incoming TCP packet rate exceeds the 1409 throughput of the TCP connection to the client), the data is 1410 discarded silently by the server. 1412 Note that, because data is forwarded blindly across TCP bindings, TLS 1413 will successfully operate over a TURN allocated TCP port if the 1414 linkage to the client is also TCP. 1416 12.1.2 UDP Processing 1418 If a server receives a UDP packet on an allocated UDP transport 1419 address, it checks the permissions associated with that allocation. 1420 If the source IP address of the UDP packet matches one of the 1421 permissions, the UDP packet is accepted. Otherwise, it is discarded. 1423 Assuming the packet is accepted, it must be forwarded to the client. 1424 It will be forwarded in either encapsulated or unencapsulated form. 1425 To determine which, the server checks the value of the active 1426 destination. If it equals the source IP address and port of the UDP 1427 packet, the server checks the state machine of the allocation. If 1428 the state is "Set", the data is taken from the UDP payload and sent 1429 towards the client in unencapsulated form. Otherwise, the data is 1430 sent towards the client in a Data Indication, also known as 1431 encapsulated form. In this form, the server MUST add a REMOTE- 1432 ADDRESS which corresponds to the external remote transport address of 1433 the UDP packet, and MUST add a DATA attribute containing the data 1434 payload of the UDP packet. 1436 Sending of the data towards the client, whether in encapsulated or 1437 unencapsulated form, depends on the linkage with the client. If the 1438 linkage with the client is over UDP, the data is placed in a UDP 1439 datagram and sent over the linkage. Note that the server will not 1440 retransmit this data to ensure reliability. If the linkage with the 1441 client is over TCP, the data is placed into the TCP connection 1442 corresponding to the linkage. If the TCP connection generates an 1443 error (because, for example, the incoming UDP packet rate exceeds the 1444 throughput of the TCP connection), the data is discarded silently by 1445 the server. 1447 12.2 Receiving Data on Internal Local Transport Addresses 1449 If a server receives a UDP packet from the client on its internal 1450 local transport address, and it is coming from an internal remote 1451 transport address associated with an existing allocation, it 1452 represents UDP data that the client wishes to forward. If the active 1453 destination is not set, the server MUST discard the packet. If the 1454 active destination is set, and the allocated transport protocol is 1455 TCP, the server selects the TCP connection from the allocated 1456 transport address to the active destination. The data is then sent 1457 over that connection. If the transmission fails due to a TCP error, 1458 the data is discarded silently by the server. If the active 1459 destination is set, and the allocated transport protocol is UDP, the 1460 server places the data from the client in a UDP payload, and sets the 1461 destination address and port to the active destination. The UDP 1462 packet is then sent with a source IP address and port equal to the 1463 allocated transport address. Note that the server will not 1464 retransmit the UDP datagram. 1466 If a server receives data on a TCP connection to a client, the server 1467 retrieves the allocation bound to that connection. If the active 1468 destination for the allocation is not set, the server MUST discard 1469 the data. If the active destination is set, and the allocated 1470 transport protocol is TCP, the server selects the TCP connection from 1471 the allocated transport address to the active destination. The data 1472 is then sent over that connection. If the transmission fails due to 1473 a TCP error, the data is discarded silently by the server. If the 1474 active destination is set, and the allocated transport protocol is 1475 UDP, the server places the data from the client in a UDP payload, and 1476 sets the destination address and port to the active destination. The 1477 UDP packet is then sent with a source IP address and port equal to 1478 the allocated transport address. Note that the server will not 1479 retransmit the UDP datagram. 1481 If a TCP connection from a client is closed, the associated 1482 allocation is destroyed. This involves terminating any TCP 1483 connections from the allocated transport address to external clients 1484 (applicable only when the allocated transport address was TCP), and 1485 then freeing the the allocated transport address (and all associated 1486 state maintained by the server) for use by other clients. 1488 Note that the state of the allocation, whether it is "Set", "Not 1489 Set", or "Transitioning", has no bearing on the rules for forwarding 1490 of packets received from clients. Only the value of the active 1491 destination is relevant. 1493 12.3 Lifetime Expiration 1495 When the allocation expiration timer for a binding fires, the server 1496 MUST destroy the allocation. This involves terminating any TCP 1497 connections from the allocated transport address to external clients 1498 (applicable only when the allocated transport address was TCP), and 1499 then freeing the the allocated transport address (and all associated 1500 state maintained by the server) for use by other clients. 1502 [[OPEN ISSUE: This is a change from the previous version, which 1503 allowed data traffic to keep allocations alive. This change was made 1504 based on implementation considerations, as it allows an easier 1505 separation of packet processing and signaling. Is this OK?]] 1507 13. Security Considerations 1509 TODO: Need to spend more time on this. 1511 STUN servers implementing this relay usage allocate bandwidth and 1512 port resources to clients, in constrast to the usages defined in [1]. 1513 Therefore, a STUN server providing the relay usage requires 1514 authentication and authorization of STUN requests. This 1515 authentication is provided by mechanisms defined in the STUN 1516 specification itself. In particular, digest authentication and the 1517 usage of short-term passwords, obtained through a digest exchange 1518 over TLS, are available. The usage of short-tem passwords ensures 1519 that the Allocate Requests, which often do not run over TLS, are not 1520 susceptible to offline dictionary attacks that can be used to guess 1521 the long lived shared secret between the client and the server. 1523 Because STUN servers implementing the relay usage allocate resources, 1524 they can be susceptible to denial-of-service attacks. All Allocate 1525 Requests are authenticated, so that an unknown attacker cannot launch 1526 an attack. An authenticated attacker can generate multiple Allocate 1527 Requests, however. To prevent a single malicious user from 1528 allocating all of the resources on the server, it is RECOMMENDED that 1529 a server implement a modest per user cap on the amount of bandwidth 1530 that can be allocated. Such a mechanism does not prevent a large 1531 number of malicious users from each requesting a small number of 1532 allocations. Attacks as these are possible using botnets, and are 1533 difficult to detect and prevent. Implementors of the STUN relay 1534 usage should keep up with best practices around detection of 1535 anomalous botnet attacks. 1537 A client will use the transport address learned from the RELAY- 1538 ADDRESS attribute of the Allocate Response to tell other users how to 1539 reach them. Therefore, a client needs to be certain that this 1540 address is valid, and will actually route to them. Such validation 1541 occurs through the message integrity checks provided in the Allocate 1542 response. They can guarantee the authenticity and integrity of the 1543 allocated addresss. Note that the STUN relay usage is not 1544 susceptible to the attacks described in Section 12.2.3, 12.2.4, 1545 12.2.5 or 12.2.6 of RFC 3489 [[TODO: Update references once 3489bis 1546 is more stable]]. These attacks are based on the fact that a STUN 1547 server mirrors the source IP address, which cannot be authenticated. 1548 STUN does not use the source address of the Allocate Request in 1549 providing the RELAY-ADDRESS, and therefore, those attacks do not 1550 apply. 1552 The relay usage cannot be used by clients for subverting firewall 1553 policies. The relay usage has fairly limited applicability, 1554 requiring a user to send a packet to a peer before being able to 1555 receive a packet from that peer. This applies to both TCP and UDP. 1556 Thus, it does not provide a general technique for externalizing TCP 1557 and UDP sockets. Rather, it has similar security properties to the 1558 placement of an address-restricted NAT in the network, allowing 1559 messaging in from a peer only if the internal client has sent a 1560 packet out towards the IP address of that peer. This limitation 1561 means that the relay usage cannot be used to run web servers, email 1562 servers, SIP servers, or other network servers that service a large 1563 number of clients. Rather, it facilitates rendezvous of NATted 1564 clients that use some other protocol, such as SIP, to communicate IP 1565 addresses and ports for communications. 1567 Confidentiality of the transport addresses learned through Allocate 1568 requests does not appear to be that important, and therefore, this 1569 capability is not provided. 1571 Relay servers are useful even for users not behind a NAT. They can 1572 provide a way for truly anonymous communications. A user can cause a 1573 call to have its media routed through a STUN server, so that the 1574 user's IP addresses are never revealed. 1576 TCP transport addresses allocated by Allocate requests will properly 1577 work with TLS and SSL. However, any relay addresses learned through 1578 an Allcoate will not operate properly with IPSec Authentication 1579 Header (AH) [11] in transport mode. IPSec ESP [12] and any tunnel- 1580 mode ESP or AH should still operate. 1582 14. IANA Considerations 1584 TODO. 1586 15. IAB Considerations 1588 The IAB has studied the problem of ``Unilateral Self Address 1589 Fixing'', which is the general process by which a client attempts to 1590 determine its address in another realm on the other side of a NAT 1591 through a collaborative protocol reflection mechanism RFC 3424 [13]. 1592 TURN is an example of a protocol that performs this type of function. 1593 The IAB has mandated that any protocols developed for this purpose 1594 document a specific set of considerations. This section meets those 1595 requirements. 1597 15.1 Problem Definition 1599 From RFC 3424 [13], any UNSAF proposal must provide: 1601 Precise definition of a specific, limited-scope problem that is to 1602 be solved with the UNSAF proposal. A short term fix should not be 1603 generalized to solve other problems; this is why "short term 1604 fixes usually aren't". 1606 The specific problem being solved by TURN is for a client, which may 1607 be located behind a NAT of any type, to obtain an IP address and port 1608 on the public Internet, useful for applications that require a client 1609 to place a transport address into a protocol message, with the 1610 expectation that the client will be able to receive packets from a 1611 single host that will send to this address. Both UDP and TCP are 1612 addressed. It is also possible to send packets so that the recipient 1613 sees a source address equal to the allocated address. TURN, by 1614 design, does not allow a client to run a server (such as a web or 1615 SMTP server) using a TURN address. TURN is useful even when NAT is 1616 not present, to provide anonymity services. 1618 15.2 Exit Strategy 1620 From [13], any UNSAF proposal must provide: 1622 Description of an exit strategy/transition plan. The better short 1623 term fixes are the ones that will naturally see less and less use 1624 as the appropriate technology is deployed. 1626 It is expected that TURN will be useful indefinitely, to provide 1627 anonymity services. When used to facilitate NAT traversal, TURN does 1628 not iself provide an exit strategy. That is provided by the 1629 Interactive Connectivity Establishment (ICE) [14] mechanism. ICE 1630 allows two cooperating clients to interactively determine the best 1631 addresses to use when communicating. ICE uses TURN-allocated 1632 addresses as a last resort, only when no other means of connectivity 1633 exists. As a result, as NATs phase out, and as IPv6 is deployed, ICE 1634 will increasingly use other addresses (host local addresses). 1635 Therefore, clients will allocate TURN addresses, but not use them, 1636 and therefore, de-allocate them. Servers will see a decrease in 1637 usage. Once a provider sees that its TURN servers are not being used 1638 at all (that is, no media flows through them), they can simply remove 1639 them. ICE will operate without TURN-allocated addresses. 1641 15.3 Brittleness Introduced by TURN 1643 From [13], any UNSAF proposal must provide: 1645 Discussion of specific issues that may render systems more 1646 "brittle". For example, approaches that involve using data at 1647 multiple network layers create more dependencies, increase 1648 debugging challenges, and make it harder to transition. 1650 TURN introduces brittleness in a few ways. First, it adds another 1651 server element to any system, which adds another point of failure. 1652 TURN requires clients to demultiplex TURN packets and data based on 1653 hunting for a MAGIC-COOKIE in the TURN messages. It is possible 1654 (with extremely small probabilities) that this cookie could appear 1655 within a data stream, resulting in mis-classification. That might 1656 introduce errors into the data stream (they would appear as lost 1657 packets), and also result in loss of a binding. TURN relies on any 1658 NAT bindings existing for the duration of the bindings held by the 1659 TURN server. Neither the client nor the TURN server have a way of 1660 reliably determining this lifetime (STUN can provide a means, but it 1661 is heuristic in nature and not reliable). Therefore, if there is no 1662 activity on an address learned from TURN for some period, the address 1663 might become useless spontaneously. 1665 TURN will result in potentially significant increases in packet 1666 latencies, and also increases in packet loss probabilities. That is 1667 because it introduces an intermediary on the path of a packet from 1668 point A to B, whose location is determined by application-layer 1669 processing, not underlying routing topologies. Therefore, a packet 1670 sent from one user on a LAN to another on the same LAN may do a trip 1671 around the world before arriving. When combined with ICE, some of 1672 the most problematic cases are avoided (such as this example) by 1673 avoiding the usage of TURN addresses. However, when used, this 1674 problem will exist. 1676 Note that TURN does not suffer from many of the points of brittleness 1677 introduced by STUN. TURN will work with all existing NAT types known 1678 at the time of writing, and for the forseeable future. TURN does not 1679 introduce any topological constraints. TURN does not rely on any 1680 heuristics for NAT type classification. 1682 15.4 Requirements for a Long Term Solution 1684 From [13]}, any UNSAF proposal must provide: 1686 Identify requirements for longer term, sound technical solutions 1687 -- contribute to the process of finding the right longer term 1688 solution. 1690 Our experience with TURN continues to validate our belief in the 1691 requirements outlined in Section 14.4 of STUN. 1693 15.5 Issues with Existing NAPT Boxes 1695 From [13], any UNSAF proposal must provide: 1697 Discussion of the impact of the noted practical issues with 1698 existing, deployed NA[P]Ts and experience reports. 1700 A number of NAT boxes are now being deployed into the market which 1701 try and provide "generic" ALG functionality. These generic ALGs hunt 1702 for IP addresses, either in text or binary form within a packet, and 1703 rewrite them if they match a binding. This will interfere with 1704 proper operation of any UNSAF mechanism, including TURN. However, if 1705 a NAT tries to modify a MAPPED-ADDRESS in a TURN Allocate Response, 1706 this will be detected by the client as an attack. 1708 16. Example 1710 In this example, a client is behind a NAT. The client has a private 1711 address of 10.0.1.1. The STUN server is on the public side of the 1712 NAT, and is listening for STUN relay requests on 192.0.2.3:8776. The 1713 public side of the NAT has an IP address of 192.0.2.1. The client is 1714 attempting to send a SIP INVITE to a peer, and wishes to allocate an 1715 IP address and port for inclusion in the SDP of the INVITE. 1716 Normally, TURN would be used in conjunction with ICE when applied to 1717 SIP. For simplicities sake, TURN is showed without ICE. 1719 The client communicates with a SIP user agent on the public network. 1720 This user agent uses a 192.0.2.17:12734 for receipt of its RTP 1721 packets. 1723 Client NAT STUN Srvr Called Pary 1724 | | | | 1725 |(1) Allocate | | | 1726 |S=10.0.1.1:4334 | | | 1727 |D=192.0.2.3:8776 | | | 1728 |------------------>| | | 1729 | | | | 1730 | | | | 1731 | | | | 1732 | |(2) Allocate | | 1733 | |S=192.0.2.1:63346 | | 1734 | |D=192.0.2.3:8776 | | 1735 | |------------------>| | 1736 | | | | 1737 | | | | 1738 | | | | 1739 | |(3) Error | | 1740 | |S=192.0.2.3:8776 | | 1741 | |D=192.0.2.1:63346 | | 1742 | |<------------------| | 1743 | | | | 1744 | | | | 1745 | | | | 1746 |(4) Error | | | 1747 |S=192.0.2.3:8776 | | | 1748 |D=10.0.1.1:4334 | | | 1749 |<------------------| | | 1750 | | | | 1751 | | | | 1752 | | | | 1753 |(5) Allocate | | | 1754 |S=10.0.1.1:4334 | | | 1755 |D=192.0.2.3:8776 | | | 1756 |------------------>| | | 1757 | | | | 1758 | | | | 1759 | | | | 1760 | |(6) Allocate | | 1761 | |S=192.0.2.1:63346 | | 1762 | |D=192.0.2.3:8776 | | 1763 | |------------------>| | 1764 | | | | 1765 | |(7) Response | | 1766 | |RA=192.0.2.3:32766 | | 1767 | |MA=192.0.2.1:63346 | | 1768 | |S=192.0.2.3:8776 | | 1769 | |D=192.0.2.1:63346 | | 1770 | |<------------------| | 1771 | | | | 1772 |(8) Response | | | 1773 |RA=192.0.2.3:32766 | | | 1774 |MA=192.0.2.1:63346 | | | 1775 |S=192.0.2.3:8776 | | | 1776 |D=10.0.1.1:4334 | | | 1777 |<------------------| | | 1778 | | | | 1779 | | | | 1780 | | | | 1781 | | | | 1782 |(9) INVITE | | | 1783 |SDP=192.0.2.3:32766| | | 1784 |---------------------------------------------------------->| 1785 | | | | 1786 | | | | 1787 | | | | 1788 | | | | 1789 |(10) 200 OK | | | 1790 |SDP=192.0.2.17:12734 | | 1791 |<----------------------------------------------------------| 1792 | | | | 1793 | | | | 1794 | | | | 1795 | | | | 1796 | | | | 1797 |(11) ACK | | | 1798 |---------------------------------------------------------->| 1799 | | | | 1800 |(12) Send | | | 1801 |DATA=RTP | | | 1802 |DA=192.0.2.17:12734| | | 1803 |S=10.0.1.1:4334 | | | 1804 |D=192.0.2.3:8776 | | | 1805 |------------------>| | | 1806 | | | | 1807 | |(13) Send | | 1808 | |DATA=RTP | | 1809 | |DA=192.0.2.17:12734| | 1810 | |S=192.0.2.1:63346 | | 1811 | |D=192.0.2.3:8776 | | 1812 | |------------------>| | 1813 | | | | 1814 | | | | 1815 | | | | 1816 | | |(14) RTP | 1817 | | |S=192.0.2.3:32766 | 1818 | | |D=192.0.2.17:12734 | 1819 | | |------------------>| 1820 | | | | 1821 | | | | 1822 | | | | 1823 | | |Permission | 1824 | | |Created | 1825 | | |192.0.2.17 | 1826 | | | | 1827 | | | | 1828 | | | | 1829 | | | | 1830 | | |(15) RTP | 1831 | | |S=192.0.2.17:12734 | 1832 | | |D=192.0.2.3:32766 | 1833 | | |<------------------| 1834 | | | | 1835 | |(16) DataInd | | 1836 | |DATA=RTP | | 1837 | |RA=192.0.2.17:12734| | 1838 | |S=192.0.2.3:8776 | | 1839 | |D=192.0.2.1:63346 | | 1840 | |<------------------| | 1841 | | | | 1842 |(17) DataInd | | | 1843 |DATA=RTP | | | 1844 |RA=192.0.2.17:12734| | | 1845 |S=192.0.2.3:8776 | | | 1846 |D=10.0.1.1:4334 | | | 1847 |<------------------| | | 1848 | | | | 1849 | | | | 1850 |(18) SetAct | | | 1851 |DA=192.0.2.17:12734| | | 1852 |S=10.0.1.1:4334 | | | 1853 |D=192.0.2.3:8776 | | | 1854 |------------------>| | | 1855 | | | | 1856 | | | | 1857 | |(19) SetAct | | 1858 | |DA=192.0.2.17:12734| | 1859 | |S=192.0.2.1:63346 | | 1860 | |D=192.0.2.3:8776 | | 1861 | |------------------>| | 1862 | | | | 1863 | | | | 1864 | | | | 1865 | |(20) Response | | 1866 | |S=192.0.2.3:8776 | | 1867 | |D=192.0.2.1:63346 | | 1868 | |<------------------| | 1869 | | | | 1870 | | | | 1871 | | | | 1872 |(21) Response | | | 1873 |S=192.0.2.3:8776 | | | 1874 |D=10.0.1.1:4334 | | | 1875 |<------------------| | | 1876 | | | | 1877 | | | | 1878 | | | | 1879 | | | | 1880 | | | | 1881 | | | |after 3s 1882 | | | | 1883 | | | | 1884 | | | | 1885 | | | | 1886 | | |(22) RTP | 1887 | | |S=192.0.2.17:12734 | 1888 | | |D=192.0.2.3:32766 | 1889 | | |<------------------| 1890 | | | | 1891 | | | | 1892 | | | | 1893 | |(23) RTP | | 1894 | |S=192.0.2.3:8776 | | 1895 | |D=192.0.2.1:63346 | | 1896 | |<------------------| | 1897 | | | | 1898 | | | | 1899 | | | | 1900 |(24) RTP | | | 1901 |S=192.0.2.3:8776 | | | 1902 |D=10.0.1.1:4334 | | | 1903 |<------------------| | | 1904 | | | | 1905 | | | | 1906 | | | | 1907 | | | | 1908 | | | | 1909 | | | | 1910 | | | | 1912 Figure 12 1914 The call flow is shown in Figure 12. The client allocates a port 1915 from the local operating system on its private interface, obtaining 1916 4334. It then attempts to secure a port for RTP traffic. RTCP 1917 processing is not shown. The client sends an Allocate request (1) 1918 with a source address (denoted by S) of 10.0.1.1:4334 and a 1919 destination (denoted by D) of 192.0.2.3:8776. This passes through 1920 the NAT (2), which creates a mapping from the 192.0.2.1:63346 to the 1921 source IP address and port of the request, 10.0.1.1:4334. This 1922 request is received at the STUN server, which challenges it (3), 1923 requesting credentials. This response is passed to the client (4). 1924 The client retries the request, this time with credentials (5). This 1925 arrives at the server (6). The request is now authenticated. The 1926 server provides a UDP allocation, 192.0.2.3:32766, and places it into 1927 the RELAY-ADDRESS (denoted by RA) in the response (7). It also 1928 reflects the source IP address and port of the request into the 1929 MAPPED-ADDRESS (denoted by MA) in the response. This passes through 1930 the NAT to the client (8). The client now proceeds to perform a 1931 basic SIP call setup. In message 9, it includes the relay address 1932 into the SDP of its INVITE. The called party responds with a 200 OK, 1933 and includes its IP address - 192.0.2.17:12734. The exchange 1934 completes with an ACK (11). 1936 Next, user A sends an RTP packet. Since the active destination has 1937 not been set, the client decides to use the Send indication. It does 1938 so, including the RTP packet as the contents of the DATA attribute. 1939 The DESTINATION-ADDRESS attribute (denoted by DA) is set to 1940 192.0.2.17:12734, learned from the 200 OK. This is sent through the 1941 NAT (message 12) and arrives at the STUN server (message 13). The 1942 server extracts the data contents, and sends the packet towards 1943 DESTINATION-ADDRESS (message 14). Note how the source address and 1944 port in this packet is 192.0.2.3:32766, the allocated transport 1945 address given to the client. The act of sending the packet with Send 1946 causes the STUN server to install a permission for 192.0.2.17. 1948 Indeed, the called party now sends an RTP packet toward the client 1949 (message 15). This arrives at the STUN server. Since a permission 1950 has been set for the IP address in the source of this packet, it is 1951 accepted. As no active destination is set, the STUN server 1952 encapsulates the contents of the packet in a Data Indication (message 1953 16), and sends it towards the client. The REMOTE-ADDRESS attribute 1954 (denoted by RA) indicates the source of the packet - 192.0.2.17: 1955 12734. This is forwarded through the NAT to the client (message 17). 1957 The client decides to optimize the path for packets to and from 1958 192.0.2.17:12734. So, it issues a Set Active Destination request 1959 (message 18) with a DESTINATION-ADDRESS of 192.0.2.17:12734. This 1960 passes through the NAT and arrives at the STUN server (message 19). 1961 This generates a successful response (message 20) which is passed to 1962 the client (message 21). At this point, the server and client are in 1963 the transitioning state. A little over 3 seconds later (by default), 1964 the state machines transition back to "Set". Until this point, 1965 packets from the called party would have been relayed back to the 1966 client in Data Indications. Now, the next RTP packet shows up at the 1967 STUN server (message 22). Since the source IP address and port match 1968 the active destination, the RTP packet is relayed towards the client 1969 without encapsulation (message 23 and 24). 1971 17. Acknowledgements 1973 The authors would like to thank Marc Petit-Huguenin for his comments 1974 and suggestions. 1976 18. References 1978 18.1 Normative References 1980 [1] Rosenberg, J., "Simple Traversal of UDP Through Network Address 1981 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02 (work 1982 in progress), July 2005. 1984 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1985 Levels", BCP 14, RFC 2119, March 1997. 1987 [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1988 specifying the location of services (DNS SRV)", RFC 2782, 1989 February 2000. 1991 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1992 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 1993 Basic and Digest Access Authentication", RFC 2617, June 1999. 1995 18.2 Informative References 1997 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1998 "RTP: A Transport Protocol for Real-Time Applications", 1999 RFC 3550, July 2003. 2001 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2002 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2003 Session Initiation Protocol", RFC 3261, June 2002. 2005 [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2006 Session Description Protocol (SDP)", RFC 3264, June 2002. 2008 [8] Handley, M. and V. Jacobson, "SDP: Session Description 2009 Protocol", RFC 2327, April 1998. 2011 [9] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 2012 Protocol (RTSP)", RFC 2326, April 1998. 2014 [10] Senie, D., "Network Address Translator (NAT)-Friendly 2015 Application Design Guidelines", RFC 3235, January 2002. 2017 [11] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 2018 November 1998. 2020 [12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 2021 (ESP)", RFC 2406, November 1998. 2023 [13] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 2024 Address Fixing (UNSAF) Across Network Address Translation", 2025 RFC 3424, November 2002. 2027 [14] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 2028 Methodology for Network Address Translator (NAT) Traversal for 2029 Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in 2030 progress), October 2005. 2032 [15] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 2033 Unicast UDP", draft-ietf-behave-nat-udp-04 (work in progress), 2034 September 2005. 2036 Authors' Addresses 2038 Jonathan Rosenberg 2039 Cisco Systems 2040 600 Lanidex Plaza 2041 Parsippany, NJ 07054 2042 US 2044 Phone: +1 973 952-5000 2045 Email: jdrosen@cisco.com 2046 URI: http://www.jdrosen.net 2047 Rohan Mahy 2048 Plantronics 2050 Email: rohan@ekabal.com 2052 Christian Huitema 2053 Microsoft 2054 One Microsoft Way 2055 Redmond, WA 98052-6399 2056 US 2058 Email: huitema@microsoft.com 2060 Intellectual Property Statement 2062 The IETF takes no position regarding the validity or scope of any 2063 Intellectual Property Rights or other rights that might be claimed to 2064 pertain to the implementation or use of the technology described in 2065 this document or the extent to which any license under such rights 2066 might or might not be available; nor does it represent that it has 2067 made any independent effort to identify any such rights. Information 2068 on the procedures with respect to rights in RFC documents can be 2069 found in BCP 78 and BCP 79. 2071 Copies of IPR disclosures made to the IETF Secretariat and any 2072 assurances of licenses to be made available, or the result of an 2073 attempt made to obtain a general license or permission for the use of 2074 such proprietary rights by implementers or users of this 2075 specification can be obtained from the IETF on-line IPR repository at 2076 http://www.ietf.org/ipr. 2078 The IETF invites any interested party to bring to its attention any 2079 copyrights, patents or patent applications, or other proprietary 2080 rights that may cover technology that may be required to implement 2081 this standard. Please address the information to the IETF at 2082 ietf-ipr@ietf.org. 2084 Disclaimer of Validity 2086 This document and the information contained herein are provided on an 2087 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2088 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2089 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2090 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2091 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2092 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2094 Copyright Statement 2096 Copyright (C) The Internet Society (2006). This document is subject 2097 to the rights, licenses and restrictions contained in BCP 78, and 2098 except as set forth therein, the authors retain all their rights. 2100 Acknowledgment 2102 Funding for the RFC Editor function is currently provided by the 2103 Internet Society.