idnits 2.17.00 (12 Aug 2021) /tmp/idnits34608/draft-ietf-behave-turn-04.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, updated by RFC 4748 on line 1779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1803. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2007) is 5431 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) == Outdated reference: draft-ietf-behave-rfc3489bis has been published as RFC 5389 == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 == Outdated reference: draft-ietf-behave-nat-udp has been published as RFC 4787 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 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 Intended status: Standards Track R. Mahy 5 Expires: January 9, 2008 Plantronics 6 C. Huitema 7 Microsoft 8 July 8, 2007 10 Traversal Using Relays around NAT (TURN): Relay Extensions to Session 11 Traversal Utilities for NAT (STUN) 12 draft-ietf-behave-turn-04.txt 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 January 9, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This specification defines an extension of the Session Traversal 46 Utilities for NAT (STUN) Protocol for asking the STUN server to relay 47 packets towards a client. This extension, called Traversal Using 48 Relays around NAT (TURN), is useful for elements behind NATs whose 49 mapping behavior is address and port dependent. The extension 50 purposefully restricts the ways in which the relayed address can be 51 used. In particular, it prevents users from running general purpose 52 servers from ports obtained from the STUN server. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Tuple Terminology . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. New Framing Mechanism for Stream-Oriented Transports . . . . . 10 64 6. New STUN Requests and Indications . . . . . . . . . . . . . . 10 65 6.1. Allocate Request . . . . . . . . . . . . . . . . . . . . . 11 66 6.1.1. Client Behavior . . . . . . . . . . . . . . . . . . . 11 67 6.1.2. Server Behavior . . . . . . . . . . . . . . . . . . . 13 68 6.2. Procedures for all other Requests and Indications . . . . 17 69 6.3. Set Active Destination Request . . . . . . . . . . . . . . 18 70 6.3.1. Client Behavior . . . . . . . . . . . . . . . . . . . 18 71 6.3.2. Server Behavior . . . . . . . . . . . . . . . . . . . 19 72 6.4. Connect Request . . . . . . . . . . . . . . . . . . . . . 19 73 6.4.1. Server Behavior . . . . . . . . . . . . . . . . . . . 20 74 6.5. Connection Status Indication . . . . . . . . . . . . . . . 20 75 6.6. Send Indication . . . . . . . . . . . . . . . . . . . . . 20 76 6.6.1. Client Behavior . . . . . . . . . . . . . . . . . . . 21 77 6.6.2. Server Behavior . . . . . . . . . . . . . . . . . . . 21 78 6.7. Data Indication . . . . . . . . . . . . . . . . . . . . . 22 79 6.7.1. Client Behavior . . . . . . . . . . . . . . . . . . . 22 80 6.7.2. Server Behavior . . . . . . . . . . . . . . . . . . . 22 81 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 22 82 7.1. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 7.2. BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . 23 84 7.3. REMOTE-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 23 85 7.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 7.5. RELAY-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 24 87 7.6. REQUESTED-PORT-PROPS . . . . . . . . . . . . . . . . . . . 24 88 7.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 25 89 7.8. REQUESTED-IP . . . . . . . . . . . . . . . . . . . . . . . 25 90 7.9. CONNECT_STAT . . . . . . . . . . . . . . . . . . . . . . . 25 91 8. New Error Response Codes . . . . . . . . . . . . . . . . . . . 26 92 9. Client Procedures . . . . . . . . . . . . . . . . . . . . . . 26 93 9.1. Receiving and Sending Unencapsulated Data . . . . . . . . 26 94 9.1.1. Datagram Protocols . . . . . . . . . . . . . . . . . . 27 95 9.1.2. Stream Transport Protocols . . . . . . . . . . . . . . 27 97 10. Server Procedures . . . . . . . . . . . . . . . . . . . . . . 27 98 10.1. Receiving Data on Allocated Transport Addresses . . . . . 27 99 10.1.1. TCP Processing . . . . . . . . . . . . . . . . . . . . 27 100 10.1.2. UDP Processing . . . . . . . . . . . . . . . . . . . . 28 101 10.2. Receiving Data on Internal Local Transport Addresses . . . 29 102 10.3. Lifetime Expiration . . . . . . . . . . . . . . . . . . . 29 103 11. Client Discovery of TURN Servers . . . . . . . . . . . . . . . 30 104 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 105 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 106 13.1. New STUN Requests, Responses, and Indications . . . . . . 32 107 13.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 33 108 13.3. New STUN response codes . . . . . . . . . . . . . . . . . 33 109 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 33 110 15. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 111 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 112 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 113 17.1. Normative References . . . . . . . . . . . . . . . . . . . 38 114 17.2. Informative References . . . . . . . . . . . . . . . . . . 38 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 116 Intellectual Property and Copyright Statements . . . . . . . . . . 40 118 1. Introduction 120 Session Traversal Utilities for NAT (STUN) [1] provides a suite of 121 tools for facilitating the traversal of NAT. Specifically, it 122 defines the Binding Request, which is used by a client to determine 123 its reflexive transport address towards the STUN server. The 124 reflexive transport address can be used by the client for receiving 125 packets from peers, but only when the client is behind "good" NATs. 126 In particular, if a client is behind a NAT whose mapping behavior [9] 127 is address or address and port dependent (sometimes called "bad" 128 NATs), the reflexive transport address will not be usable for 129 communicating with a peer. 131 The only way to obtain a transport address that can be used for 132 corresponding with a peer through such a NAT is to make use of a 133 relay. The relay sits on the public side of the NAT, and allocates 134 transport addresses to clients reaching it from behind the private 135 side of the NAT. These allocated addresses are from interfaces on 136 the relay. When the relay receives a packet on one of these 137 allocated addresses, the relay forwards it toward the client. 139 This specification defines an extension of STUN, called TURN, that 140 allows a client to request an address on the STUN server itself, so 141 that the STUN server acts as a relay. To accomplish that, this 142 extension defines a handful of new STUN requests and indications. 143 The Allocate request is the most fundamental component of this set of 144 extensions. It is used to provide the client with a transport 145 address that is relayed through the STUN server. A transport address 146 which relays through an intermediary is called a relayed transport 147 address. 149 Though a relayed address is highly likely to work when corresponding 150 with a peer, it comes at high cost to the provider of the relay 151 service. As a consequence, relayed transport addresses should only 152 be used as a last resort. Protocols using relayed transport 153 addresses should make use of mechanisms to dynamically determine 154 whether such an address is actually needed. One such mechanism, 155 defined for multimedia session establishment protocols, based on the 156 offer/answer protocol in RFC 3264 [4], is Interactive Connectivity 157 Establishment (ICE) [8]. 159 The mechanism defined here was previously a standalone protocol 160 called Traversal Using Relay NAT (TURN), and is now defined as an 161 extension of STUN. A STUN server that supports these extensions can 162 be called a 'STUN relay' or more simply a 'TURN server'. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [2]. 170 3. Definitions 172 Relayed Transport Address: A transport address that terminates on a 173 server, and is forwarded towards the client. The STUN Allocate 174 Request can be used to obtain a relayed transport address, for 175 example. 177 TURN client: A STUN client that implements this specification. It 178 obtains a relayed transport address that it provides to a small 179 number of peers (usually one). 181 TURN server: A STUN server that implements this specification. It 182 relays data between a TURN client and its peer. 184 5-tuple: A combination of the source IP address and port, 185 destination IP address and port, and transport protocol (UDP, TCP, 186 or TLS over TCP). It uniquely identifies a TCP connection, TLS 187 channel, or bi-directional flow of UDP datagrams. 189 Permission: A record of an IP address and transport of a peer that 190 is permitted to send traffic to the TURN client. The TURN server 191 will only forward traffic to its client from peers that match an 192 existing permission. 194 4. Overview of Operation 196 In a typical configuration, a TURN client is connected to a private 197 network and through one or more NATs to the public Internet. On the 198 public Internet is a TURN server. This specification defines several 199 new messages and a new framing mechanism that add the ability for a 200 STUN server to act as a packet relay. The text in this section 201 explains the typical usage of this relay extension. 203 First the client sends an Allocate request to the server, which the 204 server authenticates. The server generates an Allocate response with 205 the allocated address, port, and target transport. All other STUN 206 messages defined by this specification happen in the context of an 207 allocation. 209 A successful Allocate Request just reserves an address on the TURN 210 server. Data does not flow through an allocated port until the TURN 211 client asks the TURN server to open a permission. It can do this by 212 sending data to the far end with a Send Indication for UDP 213 allocations, by sending a ConnectRequest for TCP allocations, or by 214 setting the default destination for either transport. While the 215 client can request more than one permission per allocation, it needs 216 to request each permission explicitly and one at a time. This 217 insures that a client can't use a TURN server to run a traditional 218 server, and partially protects the client from DoS attacks. 220 Once a permission is open, the client can then receive data flowing 221 back from its peer. Initially this data is wrapped in a STUN Data 222 Indication. Since multiple permissions can be open simultaneously, 223 the Data Indication contains the Remote Address attribute so the TURN 224 client knows which peer sent the data. The client can send data to 225 any of its peers with the Send Indication. 227 Once the client wants to primarily receive from one peer, it can send 228 a SetActiveDestination request. All subsequent data received from 229 the active peer is forwarded directly to the client and vice versa, 230 except that it is wrapped or framed according to the protocol used 231 between the TURN client and TURN server. The client can send 232 subsequent SetActiveDestination requests to change or remove the 233 active destination. 235 When the TURN client to server communication is over a datagram 236 protocol (UDP), any datagram received from the active peer that has 237 the STUN magic cookie is wrapped in a Data Indication. Likewise any 238 datagram sent by the client that has the STUN magic cookie and is 239 intended for the active peer is wrapped in a Send Indication. This 240 wrapping prevents the STUN relay server from inappropriately 241 interpreting end-to-end data. 243 Over stream-based transports (TCP and TLS over TCP), the TURN client 244 and server always use some additional framing (defined in Section 5) 245 so that end-to-end data is distinguishable from STUN control 246 messages. This additional framing just has a type and a length 247 field. The value of the type field was chosen so it is always 248 distinguishable from an unframed STUN request or response. 250 The SetActiveDestination Request does not close other bindings. Data 251 to and from other peers is still wrapped in Send and Data indications 252 respectively. 254 Allocations can also request specific attributes such as the desired 255 Lifetime of the allocation, and the maximum Bandwidth. Clients can 256 also request specific port assignment behavior, for example, a 257 specific port number, odd or even port numbers, or pairs of 258 sequential port numbers. 260 4.1. Transports 262 TURN clients can communicate with a TURN server using UDP, TCP, or 263 TLS over TCP. A TURN can even relay traffic between two different 264 transports with certain restrictions. A TURN can never relay from an 265 unreliable transport (client to server) to a reliable transport to 266 the peer. Note that a TURN server never has a TLS relationship with 267 a client's peer, since the TURN server does not interpret data above 268 the TCP layer. When relaying data sent from a stream-based protocol 269 to a UDP peer, the TURN server emits datagrams which are the same 270 length as the length field in the STUN TCP framing or the length 271 field in a Send Indication. Likewise, when a UDP datagram is relayed 272 from a peer over a stream-based transport, the length of the datagram 273 is the length of the TCP framing or Data Indication. 275 +----------------+--------------+ 276 | client to TURN | TURN to peer | 277 +----------------+--------------+ 278 | UDP | UDP | 279 | TCP | TCP | 280 | TCP | UDP | 281 | TLS | TCP | 282 | TLS | UDP | 283 +----------------+--------------+ 285 For TURN clients, using TLS over TCP provides two benefits. When 286 using TLS, the client can be assured that the address of the client's 287 peers are not visible to an attacker except by traffic analysis 288 downstream of the TURN server. Second, the client may be able to 289 communicate with TURN servers using TLS that it would not be able to 290 communicate with using TCP or UDP due to the configuration of a 291 firewall between the TURN client and its server. TLS between the 292 client and TURN server in this case just facilitates traversal. 294 For TCP connections, the Connection Request allows the client to ask 295 the server to open a connection to the peer. This also adds a 296 permission to accept an incoming TCP connection from the remote 297 address of the peer. When the server and the peer try to open a TCP 298 connection at the same time, this is called TCP simultaneous open. 300 When the TURN-to-peer leg is TCP, the TURN client needs to be aware 301 of the status of these TCP connections. The TURN extension defines 302 application states for a TCP connection as follows: LISTEN, 303 ESTABLISHED, and CLOSED. Consequently, the TURN server sends a 304 ConnectionState Indication for a binding whenever the relay 305 connection status changes for one of the client's bindings, except 306 when the status changes due to a TURN client request (ex: an explicit 307 binding deallocation). 309 4.2. Tuple Terminology 311 To relay data to and from the correct location, the TURN server 312 maintains an association between an internal address (called a 313 5-tuple) and one or more external 5-tuples, as shown in Figure 1. 314 The internal 5-tuple identifies the path between the TURN client and 315 the TURN server. It consists of the protocol (UDP, TCP, or TLS over 316 TCP), the internal local IP address and port number and the source IP 317 address and port number of the STUN client, as seen by the relay 318 server. For example, for UDP, the internal 5-tuple is the 319 combination of the IP address and port from which the STUN client 320 sent its Allocate Request, with the IP address and port from which 321 the corresponding Allocate Response was sent. 323 The external local transport address is the IP address and port 324 allocated to the TURN client (the allocated transport address). The 325 external 5-tuple is the combination of the external local transport 326 address and the IP address and port of an external client that the 327 STUN client is communicating with through the STUN server. 328 Initially, there aren't any external 5-tuples, since the STUN client 329 hasn't communicated with any other hosts yet. As packets are 330 received on or sent from the allocated transport address, external 331 5-tuples are created. 333 While the terminology used in this document refers to 5-tuples, 334 the TURN server can store whatever identifier it likes that yields 335 identical results. Specifically, many implementations may use a 336 file-descriptor in place of a 5-tuple to represent a TCP 337 connection. 339 +---------+ 340 | | 341 | External| 342 / | Client | 343 // | | 344 / | | 345 // +---------+ 346 / 347 // 348 +-+ / 349 | | / 350 | | // 351 +---------+ | | +---------+ / +---------+ 352 | | |N| | | // | | 353 | STUN | | | | |/ | External| 354 | Client |----|A|----------| STUN |------------------| Client | 355 | | | |^ ^| Server |^ ^| | 356 | | |T|| || || || | 357 +---------+ | || |+---------+| |+---------+ 358 ^ | || | | | 359 | | || | | | 360 | +-+| | | | 361 | | | | | 362 | 363 Internal Internal External External 364 Client Remote Local Local Remote 365 Performing Transport Transport Transport Transport 366 Allocations Address Address Address Address 368 | | | | 369 +-----+----+ +--------+-------+ 370 | | 371 | | 373 Internal External 374 5-Tuple 5-tuple 376 Figure 1 378 4.3. Keepalives 380 Since the main purpose of STUN and the relay extension are to 381 traverse NATs, it is natural to consider which elements are 382 responsible for generating sufficient periodic traffic to insure that 383 NAT bindings stay alive. Relay clients need to send data frequently 384 enough to keep both NAT bindings and the TURN server internal 385 permissions fresh. Like NAT bindings, the TURN server bindings are 386 refreshed by ordinary data traffic relayed to and from the peer. 388 Unlike permissions, allocations on the TURN server have an explicit 389 expiration time and need to be refreshed explicitly by the client. 390 When an allocation expires, all permissions associated with that 391 allocation are automatically deleted. 393 5. New Framing Mechanism for Stream-Oriented Transports 395 Over stream-based transports, the TURN client and server need to use 396 additional framing so that end-to-end data is distinguishable from 397 STUN control messages, and so that the TURN server can perform 398 conversion from streams to datagrams and vice versa. This additional 399 framing has a one octet type, one reserved octet, and a 2 octet 400 length field. The first octet of this framing is 0x02 to indicate 401 STUN messages or 0x03 to indicate end-to-end data to or from the 402 active destination. Note that the first octet is always 403 distinguishable from an unframed STUN request or response (which is 404 always 0x00 or 0x01). The second octet is reserved and MUST be set 405 to zero. The length field counts the number of octets immediately 406 after the length field itself. 408 0 1 2 3 409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Reserved = 0 | Length | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Use of this framing mechanism is discussed in Section 9 and 415 Section 10. 417 6. New STUN Requests and Indications 419 This document defines three new requests (along with their success 420 and error responses) and three indications. It also defines 421 processing rules for the STUN server and client on receipt of non- 422 STUN messages. See Section 9 and Section 10 424 The new messages are: 426 Request/Response Transactions 427 0x003 : Allocate 428 0x004 : Set Active Destination 429 0x005 : Connect 431 Indications 432 0x006 : Send 433 0x007 : Data 434 0x008 : Connect Status 436 In addition to STUN Messages (Requests, Responses, and Indications), 437 TURN clients and servers send and receive non-STUN packets on the 438 same ports used for STUN messages. How these entities distinguish 439 STUN and non-STUN traffic is discussed in Section 9 and Section 10. 441 6.1. Allocate Request 443 6.1.1. Client Behavior 445 Client behavior for Allocate requests depends on whether the request 446 is an initial one, for the purposes of obtaining a new relayed 447 transport address, or a subsequent one, used for refreshing an 448 existing allocation. 450 6.1.1.1. Initial Requests 452 When a client wishes to obtain a transport address, it sends an 453 Allocate Request to the server. This request is constructed and sent 454 using the general procedures defined in [1]. The server will 455 challenge the request for credentials. The client MAY either provide 456 its credentials to the server directly, or it MAY obtain a short-term 457 set of credentials using the Shared Secret request and then use those 458 as the credentials in the Allocate request. 460 The client SHOULD include a BANDWIDTH attribute, which indicates the 461 maximum bandwidth that will be used with this binding. If the 462 maximum is unknown, the attribute is not included in the request. 464 The client MAY request a particular lifetime for the allocation by 465 including it in the LIFETIME attribute in the request. The default 466 lifetime is 10 minutes. 468 The client MAY include a REQUESTED-PORT-PROPS, REQUESTED-TRANSPORT, 469 or REQUESTED-IP attribute in the request to obtain specific types of 470 transport addresses. Whether these are needed depends on the 471 application using the TURN server. As an example, the Real Time 472 Transport Protocol (RTP) [3] requires that RTP and RTCP ports be an 473 adajacent pair, even and odd respectively, for compatibility with a 474 previous version of that specification. The REQUESTED-PORT-PROPS 475 attribute allows the client to ask the relay for those properties. 476 The client MUST NOT request the TCP transport in an Allocate request 477 sent to the TURN server over UDP. 479 Processing of the response follows the general procedures of [1]. A 480 successful response will include both a RELAY-ADDRESS and an XOR- 481 MAPPED-ADDRESS attribute, providing both a relayed transport address 482 and a reflexive transport address, respectively, to the client. The 483 server will expire the allocation after LIFETIME seconds have passed 484 if not refreshed by another Allocate request. The server will allow 485 the user to send and receive at least the amount of data indicated in 486 the BANDWIDTH attribute per allocation. (At its discretion the 487 server can optionally discard data above this threshold.) 489 If the response is an error response and contains a 442, 443 or 444 490 error code, the client knows that its requested properties could not 491 be met. The client MAY retry with different properties, with the 492 same properties (in a hope that something has changed on the server), 493 or give up, depending on the needs of the application. However, if 494 the client retries, it SHOULD wait 500ms, and if the request fails 495 again, wait 1 second, then 2 seconds, and so on, exponentially 496 backing off. 498 6.1.1.2. Subsequent Requests 500 Before 3/4 of the lifetime of the allocation has passed (the lifetime 501 of the allocation is conveyed in the LIFETIME attribute of the 502 Allocate Response), the client SHOULD refresh the allocation with 503 another Allocate Request if it wishes to keep the allocation. 505 To perform a refresh, the client generates an Allocate Request as 506 described in Section 6.1.1.1. If the initial request was 507 authenticated with a shared secret P that the client holds with the 508 server, or using a short term password derived from P through a 509 Shared Secret request, the client MUST use shared secret P, or a 510 short-term password derived from it, in the subsequent request. 512 In a successful response, the RELAY-ADDRESS contains the same 513 transport address as previously obtained, indicating that the binding 514 has been refreshed. The LIFETIME attribute indicates the amount of 515 additional time the binding will live without being refreshed. Note 516 that an error response does not imply that the binding has been 517 expired, just that the refresh has failed. 519 If a client no longer needs an allocation, it SHOULD perform an 520 explict deallocation. If the client wishes to explicitly remove the 521 allocation because it no longer needs it, it generates a subsequent 522 Allocate request, but sets the LIFETIME attribute to zero. This will 523 cause the server to remove the allocation, and all associated 524 bindings. For connection-oriented transports such as TCP, the client 525 can also remove the allocation (and all associated bindings) by 526 closing the relevant connection with the TURN server. 528 6.1.2. Server Behavior 530 The server first processes the request according to the general 531 request processing rules in [1]. This includes performing 532 authentication, and checking for mandatory unknown attributes. Due 533 to the fact that the STUN server is allocating resources for 534 processing the request, Allocate requests MUST be authenticated, and 535 furthermore, MUST be authenticated using either a shared secret known 536 between the client and server, or a short term password derived from 537 it. 539 Note that Allocate requests, like most other STUN requests, can be 540 sent to the TURN server over UDP, TCP, or TCP/TLS. 542 The behavior of the server when receiving an Allocate Request depends 543 on whether the request is an initial one, or a subsequent one. An 544 initial request is one whose source and destination transport address 545 do not match the internal remote and local transport addresses of an 546 existing internal 5-tuple. A subsequent request is one whose source 547 and destination transport address matches the internal remote and 548 local transport address of an existing internal 5-tuple. 550 6.1.2.1. Initial Requests 552 The server attempts to allocate transport addresses. It first looks 553 for the BANDWIDTH attribute for the request. If present, the server 554 determines whether or not it has sufficient capacity to handle a 555 binding that will generate the requested bandwidth. 557 If it does, the server attempts to allocate a transport address for 558 the client. The Allocate request can contain several additional 559 attributes that allow the client to request specific characteristics 560 of the transport address. First, the server checks for the 561 REQUESTED-TRANSPORT attribute. This indicates the transport protocol 562 requested by the client. This specification defines values for UDP 563 and TCP. 565 As a consequence of the REQUESTED-TRANSPORT attribute, it is 566 possible for a client to connect to the server over TCP or TLS 567 over TCP and request a UDP transport address. In this case, the 568 server will relay data between the transports. 570 If the requested transport is supported, the server allocates a port 571 using the requested transport protocol. If the REQUESTED-TRANSPORT 572 attribute contains a value of the transport protocol unknown to the 573 server, or known to the server but not supported by the server in the 574 context of this request, the server MUST reject the request and 575 include a 442 (Unsupported Transport Protocol) in the response, or 576 redirect the request. If the request did not contain a REQUESTED- 577 TRANSPORT attribute, the server MUST use the same transport protocol 578 as the request arrived on. 580 Next, the server checks for the REQUESTED-IP attribute. If present, 581 it indicates a specific interface from which the client would like 582 its transport address allocated. If this interface is not a valid 583 one for allocations on the server, the server MUST reject the request 584 and include a 443 (Invalid IP Address) error code in the response, or 585 else redirect the request to a server that is known to support this 586 IP address. If the IP address is one that is valid for allocations 587 (presumably, the server is configured to know the set of IP addresses 588 from which it performs allocations), the server MUST provide an 589 allocation from that IP address. If the attribute is not present, 590 the selection of an IP address is at the discretion of the server. 592 Finally, the server checks for the REQUESTED-PORT-PROPS attribute. 593 If present, it indicates specific port properties desired by the 594 client. This attribute is split into two portions: one portion for 595 port behavior and the other for requested port alignment (whether the 596 allocated port is odd, even, reserved as a pair, or at the discretion 597 of the server). 599 If the port behavior requested is for a Specific Port, the server 600 MUST attempt to allocate that specific port for the client. If the 601 port is allocated to a different internal 5-tuple associated with the 602 same STUN long-term credentials, the client is requesting a move. 603 The server SHOULD replace the old internal 5-tuple with the new tuple 604 over which this Allocate request arrived. The server MUST reject the 605 move request if any of the attributes other than LIFETIME have 606 changed (BANDWIDTH, REQUESTED-TRANSPORT, etc.). 608 If the specific port is not available (in use or reserved), the 609 server MUST reject the request with a 444 (Invalid Port) response or 610 redirect to an alternate server. For example, the STUN server could 611 reject a request for a Specific Port because the port is temporarily 612 reserved as part of an adjacent pair of ports, or because the 613 requested port is a well-known port (1-1023). 615 If the client requests "even" port alignment, the server MUST attempt 616 to allocate an even port for the client. If an even port cannot be 617 obtained, the server MUST reject the request with a 444 (Invalid 618 Port) response or redirect to an alternate server. If the client 619 requests odd port alignment, the server MUST attempt to allocate an 620 odd port for the client. If an odd port cannot be obtained, the 621 server MUST reject the request with a 444 (Invalid Port) response or 622 redirect to an alternate server. Finally, the "Even port with hold 623 of the next higher port" alignment is similar to requesting an even 624 port. It is a request for an even port, and MUST be rejected by the 625 server if an even port cannot be provided, or redirected to an 626 alternate server. However, it is also a hint from the client that 627 the client will request the next higher port with a separate Allocate 628 request. As such, it is a request for the server to allocate an even 629 port whose next higher port is also available, and furthermore, a 630 request for the server to not allocate that one higher port to any 631 other request except for one that asks for that port explicitly. The 632 server can honor this request for adjacency at its discretion. The 633 only constraint is that the allocated port has to be even. 635 Port alignment requests exist for compatibility with 636 implementations of RTP which pre-date RFC 3550. These 637 implementations use the port numbering conventions in (now 638 obsolete) RFC 1889. 640 If any of the requested or desired constraints cannot be met, whether 641 it be bandwidth, transport protocol, IP address or port, instead of 642 rejecting the request, the server can alternately redirect the client 643 to a different server that may be able to fulfill the request. This 644 is accomplished using the 300 error response and ALTERNATE-SERVER 645 attribute. If the server does not redirect and cannot service the 646 request because the server has reached capacity, it sends a 507 647 (Insufficient Capacity) response. The server can also reject the 648 request with a 486 (Allocation Quota Reached) if the user or client 649 is not authorized to request additional allocations. 651 The server SHOULD only allocate ports in the range 1024-65535. This 652 is one of several ways to prohibit relayed transport addresses from 653 being used to attempt to run standard services. These guidelines are 654 meant to be consistent with [9], since the relay is effectively a 655 NAT. 657 Once the port is allocated, the server associates it with the 658 internal 5-tuple and fills in that 5-tuple. The internal remote 659 transport address of the internal 5-tuple is set to the source 660 transport address of the Allocate Request. The internal local 661 transport address of the internal 5-tuple is set to the destination 662 transport address of the Allocate Request. For TCP, this amounts to 663 associating the TCP connection from the TURN client with the 664 allocated transport address. 666 If the Allocate request was authenticated using a shared secret 667 between the client and server, this credential MUST be associated 668 with the allocation. If the request was authenticated using a short 669 term password derived from a shared secret, that shared secret MUST 670 be associated with the allocation. This is used in all subsequent 671 requests and indications to ensure that only the same client can use 672 or modify the allocation it was given. 674 The allocation created by the Allocate request is also associated 675 with a transport address, called the active destination. This 676 transport address is used for forwarding data through the TURN 677 server, and is described in more detail later. It is initially set 678 to null when the allocation is created. In addition, the allocation 679 created by the server is associated with a set of permissions. Each 680 permission is a specific IP address identifying an external client. 681 Initially, this list is null. 683 If the LIFETIME attribute was present in the request, and the value 684 is larger than the maximum duration the server is willing to use for 685 the lifetime of the allocation, the server MAY lower it to that 686 maximum. However, the server MUST NOT increase the duration 687 requested in the LIFETIME attribute. If there was no LIFETIME 688 attribute, the server may choose a default duration at its 689 discretion. In either case, the resulting duration is added to the 690 current time, and a timer, called the allocation expiration timer, is 691 set to fire at or after that time. Section 10.3 discusses behavior 692 when the timer fires. Note that the LIFETIME attribute in the 693 request can be zero. This typically happens for subsequent 694 Allocations, and provides a mechanism to delete the allocation. It 695 will force the immediate deletion of the allocation. 697 Once the port has been obtained and the activity timer started for 698 the port binding, the server generates an Allocate Response using the 699 general procedures defined in [1]. The transport address allocated 700 to the client MUST be included in the RELAY-ADDRESS attribute in the 701 response. In addition, this response MUST contain the XOR-MAPPED- 702 ADDRESS attribute. This allows the client to determine its reflexive 703 transport address in addition to a relayed transport address, from 704 the same Allocate request. 706 The server MUST add a LIFETIME attribute to the Allocate Response. 707 This attribute contains the duration, in seconds, of the allocation 708 expiration timer associated with this allocation. 710 The server MUST add a BANDWIDTH attribute to the Allocate Response. 711 This MUST be equal to the attribute from the request, if one was 712 present. Otherwise, it indicates a per-binding cap that the server 713 is placing on the bandwidth usage on each binding. Such caps are 714 needed to prevent against denial-of-service attacks (See Section 12). 716 The server MUST add, as the final attribute of the request, a 717 MESSAGE-INTEGRITY attribute. The key used in the HMAC MUST be the 718 same as that used to validate the request. 720 6.1.2.2. Subsequent Requests 722 A subsequent Allocate request is one received whose source and 723 destination IP address and ports match the internal 5-tuple of an 724 existing allocation. The request is processed using the general 725 server procedures in [1] and is processed identically to 726 Section 6.1.2.1, with a few important exceptions. 728 First, the request MUST be authenticated using the same shared secret 729 as the one associated with the allocation, or be authenticated using 730 a short term password derived from that shared secret. If the 731 request was authenticated but not with such a matching credential, 732 the server MUST generate an Allocate Error Response with an 733 appropriate error response code. 735 Secondly, if the allocated transport address given out previously to 736 the client still matches the constraints in the request (in terms of 737 request ports, IP addresses and transport protocols), the same 738 allocation granted previously MUST be returned. However, if one of 739 the constraints is not met any longer, because the client changed 740 some aspect of the request, the server MUST free the previous 741 allocation and allocate a new request to the client. 743 Finally, a subsequent Allocate request will set a new allocation 744 expiration timer for the allocation, effectively canceling the 745 previous lifetime expiration timer. 747 6.2. Procedures for all other Requests and Indications 749 Other than initial Allocate Requests, all requests and indications 750 defined in this document need to be sent in the context of a valid 751 allocation. The source and destination IP address and ports for 752 these STUN messages MUST match the internal 5-tuple of an existing 753 allocation. These processed using the general server procedures in 754 [1] with a few important additions. For requests, if there is no 755 matching allocation, the server MUST generate a 437 (No Binding) Send 756 Error Response. For indications, if there is no matching allocation, 757 the indication is silently discarded. 759 All requests and indications MUST be authenticated using the same 760 shared secret as the one associated with the allocation, or be 761 authenticated using a short term password derived from that shared 762 secret. If the request was authenticated but not with such a 763 matching credential, the server MUST generate an Allocate Error 764 Response with an appropriate error response code, such as a 431 765 (Integrity Failure) or 436 (Unknown User). 767 6.3. Set Active Destination Request 769 6.3.1. Client Behavior 771 The Set Active Destination request allows the client to create an 772 optimized relay function between the client and the server. When the 773 server receives packets from a particular preferred external peer, 774 the server will forward those packets towards the client without 775 encapsulating them in a Data Indication. Similarly, the client can 776 send non-STUN packets to the server without encapsulation in a Send 777 Indication, and these packets are forwarded to the external peer. 778 Sending and receiving data in unencapsulated form is critical for 779 efficiency purposes. One of the primary use cases for the STUN relay 780 extensions is in support of Voice over IP (VoIP), which uses very 781 small UDP packets to begin with. The extra overhead of an additional 782 layer of encapsulation is considered unacceptable. 784 The Set Active Destination request is used by the client to provide 785 the identity of this preferred external peer. The Set Active 786 Destination address MAY contain a REMOTE-ADDRESS attribute. This 787 attribute, when present, provides the address of the preferred 788 external peer to the server. When absent, it clears the value of the 789 preferred external peer. As a convenience, if the client sets the 790 REMOTE-ADDRESS attribute to a peer without a permission, the server 791 will add the corresponding permission. 793 The client MUST NOT send a Set Active Destination request with a 794 REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an 795 active destination is already set for that allocation. If the client 796 wishes to set a new active destination, it MUST wait until a 797 successful response is received to a Set Destination Request removing 798 the active destination. The client SHOULD then continue to wait for 799 an additional period of up to 5 seconds until it is extremely 800 unlikely that any data from the previous active destination might 801 still arrive. Failure to wait could cause the client to receive and 802 attribute late data forwarded by the TURN server to the wrong peer. 803 The client MAY wait a shorter period of time if the application has 804 built-in addressing (such as the RTP [3] Sender Source) that makes it 805 unlikely the client would incorrectly attribute late data. [OPEN 806 ISSUE: is this OK with the WG? ] 807 Consider the case where the active destination is set, and the 808 server is relaying packets towards the client. The client knows 809 the IP address and port where the packets came from - the current 810 value of the active destination. The client issues a Set Active 811 Destination Request to change the active destination, and receives 812 a response. A moment later, a data packet is received, not 813 encapsulated in a STUN Data Indication. What is the source if 814 this packet? Is it the active destination that existed prior to 815 the Set Active Destination request, or the one after? If the 816 transport between the client and the STUN server is not reliable, 817 there is no way to know. 819 6.3.2. Server Behavior 821 The Set Active Destination Request is used by a client to set the 822 forwarding destination of all data that is not encapsulated in STUN 823 Send Indications. In addition, when a matching permission is 824 present, all data received from that external peer will be forwarded 825 to the STUN client without being encapsulated in a Data Indication. 827 If the Set Active Destination request does not contain a REMOTE- 828 ADDRESS attribute, the value of the active destination is cleared. 829 If the Set Active Destination request contains a REMOTE-ADDRESS 830 attribute, and the active destination is not set, the active 831 destination is set to that IP address and port. If an active 832 destination is already set, and the request was received over a 833 reliable transport, the active destination is changed to the new 834 value. If the active destination is already set and the request was 835 received over UDP, the Set Active Destination request is rejected 836 with a 439 Active Destination Already Set error response. This 837 prevents the race condition described in the previous section. 839 If the server sets the active destination and there is no permission 840 associated with the REMOTE-ADDRESS, the server adds the corresponding 841 permission. Note that if the permission associated with the active 842 destination becomes invalid, the server does not reset the active 843 destination. The client is expected to do this explicitly. 845 6.4. Connect Request 847 The Connect Request is used by a client when it has obtained an 848 allocated transport address that is TCP. The client can use the 849 Connect Request to ask the server to open a TCP connection to a 850 specified destination address included in the request. 852 6.4.1. Server Behavior 854 If the allocation is for a UDP port, the server MUST reject the 855 request with a 445 (Operation for TCP Only) response. If the request 856 does not contain a REMOTE-ADDRESS attribute, the server sends a 400 857 (Bad Request) Connect error response,. 859 If the request contains a REMOTE-ADDRESS attribute, the IP address 860 contained within it is added to the permissions for this allocation, 861 if it was not already present. This happens regardless of whether 862 the subsequent TCP connection attempt succeeds or not. 864 If a connection already exists for this address and port, the server 865 returns a 446 (Connection Already Exists) Connect error response. 866 Otherwise the server tries to establish the corresponding TCP 867 connection and returns a Connect Success Response. This just 868 indicates that the server added the permission and is attempting to 869 establish a TCP connection. The server does not wait for the 870 connection attempt to succeed or fail. The status of the connection 871 attempt is returned via the Connect Status Indication. 873 Note that the server needs to use the same source connection 874 address for all connections/permissions associated with an 875 allocation. For servers written using Berkeley sockets, the 876 SO_REUSEADDR flag is typically used to use the same local address 877 with multiple sockets. 879 6.5. Connection Status Indication 881 When the TURN to peer leg is TCP, the TURN client needs to be aware 882 of the status of these TCP connections. The TURN extension defines 883 application states for a TCP connection as follows: LISTEN, 884 ESTABLISHED, CLOSED. Consequently, the TURN server sends a 885 Connection State Indication for a TCP permission whenever the relay 886 connection status changes for one of the client's permissions except 887 when the status changes due to a TURN client request (ex: an explicit 888 binding close or deallocation). 890 A TURN can only relay to a peer over TCP if the client 891 communicates with the server over TCP or TLS over TCP. Because of 892 this, the server can be assured that Connection Status Indications 893 are received reliably. 895 6.6. Send Indication 896 6.6.1. Client Behavior 898 The Send Indication is used to ask the relay to forward data to a 899 peer. It is typically used to send to a peer other than the active 900 destination. For TCP allocated transport addresses, the client needs 901 to wait for the peer to open a connection to the TURN server before 902 it can send data. Data sent with a Send request prior to the opening 903 of a TCP connection is discarded silently by the server. 905 The Send Indication MUST contain a REMOTE-ADDRESS attribute, which 906 contains the IP address and port that the data is being sent to. The 907 DATA attribute MAY be present, and contains the data that is to be 908 sent towards REMOTE-ADDRESS. If absent, the server will send an 909 empty UDP packet in the case of UDP. In the case of TCP, the server 910 will do nothing. 912 Since Send is an Indication, it generates no response. The client 913 must rely on application layer mechanisms to determine if the data 914 was received by the peer. 916 Note that Send Indications are not authenticated and do not 917 contain a MESSAGE-INTEGRITY attribute. Just like non-relayed data 918 sent over UDP or TCP, the authenticity and integrity of this data 919 can only be assured using security mechanisms at higher layers. 921 6.6.2. Server Behavior 923 A Send Indication is sent by a client after it has completed its 924 Allocate transaction, in order to create permissions in the server 925 and send data to an external client. 927 If a Send Indication contains no REMOTE-ADDRESS, the indication is 928 discarded. If there is no DATA attribute, and the corresponding 929 allocation is for TCP, the indication is discarded. 931 If the allocation is a UDP allocation, the server creates a UDP 932 packet whose payload equals that content. The server sets the source 933 IP address of the packet equal to the allocated transport address. 934 The destination transport address is set to the contents of the 935 REMOTE-ADDRESS attribute. If a permission does not exist for this 936 destination the server creates one for this allocation. The server 937 then sends the UDP packet. Note that any retransmissions of this 938 packet which might be needed are not handled by the server. It is 939 the responsibility of the client to generate another Send indication 940 if needed. 942 If the allocation is a TCP allocation, the server checks if it has an 943 existing TCP connection open from the allocated transport address to 944 the address in the REMOTE-ADDRESS attribute. If so, the server 945 extracts the content of the DATA attribute and sends it over the 946 matching TCP connection. If the server doesn't have an existing TCP 947 connection to the destination, it adds the REMOTE-ADDRESS to the 948 permission list and discards the data. 950 6.7. Data Indication 952 6.7.1. Client Behavior 954 Once a client has obtained an allocation and created permissions for 955 a particular external client, the server can begin to relay packets 956 from that external client towards the client. If the external client 957 is not the active destination, this data is relayed towards the 958 client in encapsulated form using the Data Indication. 960 The Data Indication contains two attributes - DATA and REMOTE- 961 ADDRESS. The REMOTE-ADDRESS attribute indicates the source transport 962 address that the request came from, and it will equal the external 963 remote transport address of the external peer. When processing this 964 data, a client MUST treat the data as if it came from this address, 965 rather than the stun server itself. The DATA attribute contains the 966 data from the UDP packet or TCP segment that was received. Note that 967 the TURN server will not retransmit this indication over UDP. 969 Note that Data Indications are not authenticated and do not 970 contain a MESSAGE-INTEGRITY attribute. Just like non-relayed data 971 sent over UDP or TCP, the authenticity and integrity of this data 972 can only be assured using security mechanisms at higher layers. 974 6.7.2. Server Behavior 976 A server MUST send data packets towards the client using a Data 977 Indication under the conditions described in Section 10.1. Data 978 Indications MUST contain a DATA attribute containing the data to 979 send, and MUST contain a REMOTE-ADDRESS attribute indicating where 980 the data came from. 982 7. New Attributes 984 This STUN extension defines the following new attributes: 986 0x000D: LIFETIME 987 0x0010: BANDWIDTH 988 0x0012: REMOTE-ADDRESS 989 0x0013: DATA 990 0x0016: RELAY-ADDRESS 991 0x0018: REQUESTED-PORT-PROPS 992 0x0019: REQUESTED-TRANSPORT 993 0x0022: REQUESTED-IP 994 0x0021: TIMER-VAL 995 0x0023: CONNECT_STAT 997 7.1. LIFETIME 999 The lifetime attribute represents the duration for which the server 1000 will maintain an allocation in the absence of data traffic either 1001 from or to the client. It is a 32 bit value representing the number 1002 of seconds remaining until expiration. 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Lifetime | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 7.2. BANDWIDTH 1010 The bandwidth attribute represents the peak bandwidth, measured in 1011 kbits per second, that the client expects to use on the binding in 1012 each direction. 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Bandwidth | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 7.3. REMOTE-ADDRESS 1020 The REMOTE-ADDRESS specifies the address and port of the peer as seen 1021 from the TURN server. It is encoded in the same way as MAPPED- 1022 ADDRESS. 1024 7.4. DATA 1026 The DATA attribute is present in Send Indications and Data 1027 Indications. It contains raw payload data that is to be sent (in the 1028 case of a Send Request) or was received (in the case of a Data 1029 Indication). It is padded with zeros if its length is not divisible 1030 evenly by 4 octets 1032 7.5. RELAY-ADDRESS 1034 The RELAY-ADDRESS is present in Allocate responses. It specifies the 1035 address and port that the server allocated to the client. It is 1036 encoded in the same way as MAPPED-ADDRESS. 1038 7.6. REQUESTED-PORT-PROPS 1040 This attribute allows the client to request certain properties for 1041 the port that is allocated by the server. The attribute can be used 1042 with any transport protocol that has the notion of a 16 bit port 1043 space (including TCP and UDP). The attribute is 32 bits long. Its 1044 format is: 1046 0 1 2 3 1047 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Reserved = 0 | A | Specific Port Number | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 The two bits labeled A in the diagram above are for requested port 1053 alignment and have the following meaning: 1055 00 no specific port alignment 1056 01 odd port number 1057 10 even port number 1058 11 even port number; reserve next higher port 1060 If the Specific Port Number field is zero, this means that no 1061 specific port is requested. If a specific port number is requested 1062 the value will be in the two low order octets. All other bits in 1063 this attribute are reserved and MUST be set to zero. 1065 Even Port is a request to the server to allocate a port with even 1066 parity. The port filter is not used with this property. Odd Port is 1067 a request to the server to allocate a port with odd parity. The port 1068 filter is not used with this property. Even port, with a hold on the 1069 next higher port, is a request to the server to allocate an even 1070 port. Furthermore, the client indicates that it will want the next 1071 higher port as well. As such, the client requests that the server, 1072 if it can, not allocate the next higher port to anyone unless that 1073 port is explicitly requested, which the client will itself do. The 1074 port filter is not used with this property. Finally, the Specific 1075 Port property is a request for a specific port. The port that is 1076 requested is contained in the Port filter. 1078 7.7. REQUESTED-TRANSPORT 1080 This attribute is used by the client to request a specific transport 1081 protocol for the allocated transport address. It is a 32 bit 1082 unsigned integer. Its values are: 1084 0x0000 0000: UDP 1085 0x0000 0001: TCP 1087 If an Allocate request is sent over TCP and requests a UDP 1088 allocation, or an Allocate request is sent over TLS over TCP and 1089 requests a UDP or TCP allocation, the server will relay data between 1090 the two transports. 1092 Extensions to TURN can define additional transport protocols in an 1093 IETF-consensus RFC. 1095 7.8. REQUESTED-IP 1097 The REQUESTED-IP attribute is used by the client to request that a 1098 specific IP address be allocated to it. This attribute is needed 1099 since it is anticipated that TURN servers will be multi-homed so as 1100 to be able to allocate more than 64k transport addresses. As a 1101 consequence, a client needing a second transport address on the same 1102 interface as a previous one can make that request. 1104 The format of this attribute is identical to MAPPED-ADDRESS. 1105 However, the port component of the attribute is ignored by the 1106 server. If a client wishes to request a specific IP address and 1107 port, it uses both the REQUESTED-IP and REQUESTED-PORT-PROPS 1108 attributes. 1110 7.9. CONNECT_STAT 1112 This attribute is used by the server to convey the status of server- 1113 to-peer connections. It is a 32 bit unsigned integer. Its values 1114 are: 1116 0x0000 0000: LISTEN 1117 0x0000 0001: ESTABLISHED 1118 0x0000 0002: CLOSED 1120 8. New Error Response Codes 1122 This document defines the following new Error response codes: 1124 437 (No Binding): A request was received by the server that 1125 requires an allocation to be in place. However, there is none yet 1126 in place. 1128 439 (Active Destination Already Set): A Set Active Destination 1129 request was received by the server over UDP. However, the active 1130 destination is already set to another value. The client should 1131 reset the active destination, wait for the hold-down period, and 1132 set the active destination to the new value. 1134 442 (Unsupported Transport Protocol): The Allocate request asked 1135 for a transport protocol to be allocated that is not supported by 1136 the server. 1138 443 (Invalid IP Address): The Allocate request asked for a 1139 transport address to be allocated from a specific IP address that 1140 is not valid on the server. 1142 444 (Invalid Port): The Allocate request asked for a port to be 1143 allocated that is not available on the server. 1145 445 (Operation for TCP Only): The client tried to send a request 1146 to perform a TCP-only operation on an allocation, and allocation 1147 is UDP. 1149 446 (Connection Already Exists): The client tried to open a 1150 connection to a peer, but a connection to that peer already 1151 exists. 1153 486 (Allocation Quota Reached): The user or client is not 1154 authorized to request additional allocations. 1156 507 (Insufficient Capacity): The server cannot allocate a new port 1157 for this client as it has exhausted its relay capacity. 1159 9. Client Procedures 1161 9.1. Receiving and Sending Unencapsulated Data 1163 Once the active destination has been set, a client will receive both 1164 STUN and non-STUN data on the socket on which the Allocate Request 1165 was sent. The encapsulation behavior depends on the transport 1166 protocol used between the STUN client and the TURN server. 1168 9.1.1. Datagram Protocols 1170 If the allocation was over UDP, datagrams which contain the STUN 1171 magic cookie are treated as STUN requests. All other data is non- 1172 STUN data, which MUST be processed as if it had a source IP address 1173 and port equal to the value of the active destination. 1175 If the client wants to send data to the peer which contains the magic 1176 cookie in the same location as a STUN request, it MUST send that data 1177 encapsulated in a Send Indication, even if the active destination is 1178 set. 1180 In addition, once the active destination has been set, the client can 1181 send data to the active destination by sending the data 1182 unencapsulated on that same socket. Unencapsulated data MUST NOT be 1183 sent if no active destination is set. Of course, even if the active 1184 destination is set, the client can send data to that destination at 1185 any time by using the Send Indication. 1187 9.1.2. Stream Transport Protocols 1189 If the allocation was over TCP or TLS over TCP, the client will 1190 receive data framed as described in Section 5. The client MUST treat 1191 data encapsulated as data with this framing as if it originated from 1192 the active destination. 1194 For the any of the methods defined in this document, the client 1195 always sends data encapsulated using this framing scheme. It SHOULD 1196 frame data to the active destination as data or it MAY place the data 1197 inside a Send Indications and frame this as STUN traffic. 1199 10. Server Procedures 1201 Besides the processing of the request and indications described 1202 above, this specification defines rules for processing of data 1203 packets received by the STUN server. There are two cases - receipt 1204 of any packets on an allocated address, and receipt of non-STUN data 1205 on its internal local transport address. 1207 10.1. Receiving Data on Allocated Transport Addresses 1209 10.1.1. TCP Processing 1211 If a server receives a TCP connection request on an allocated TCP 1212 transport address, it checks the permissions associated with that 1213 allocation. If the source IP address of the TCP SYN packet matches 1214 one of the permissions (the source port does not need to match), the 1215 TCP connection is accepted. Otherwise, it is rejected. When a TCP 1216 connection is accepted, the server sends the corresponding client a 1217 Connect Status Indication with the CONNECT_STAT attribute set to 1218 ESTABLISHED. No information is passed to the client if the server 1219 rejects the connection because there is no corresponding permission. 1221 If a server receives data on a TCP connection that terminates on the 1222 allocated TCP transport address, the server checks the value of the 1223 active destination. If it equals the source IP address and port of 1224 the data packet (in other words, if the active destination identifies 1225 the other side of the TCP connection), the data is taken from the TCP 1226 connection and sent towards the client in unencapsulated form. 1227 Otherwise, the data is sent towards the client in a Data Indication, 1228 also known as encapsulated form. In this form, the server MUST add a 1229 REMOTE-ADDRESS which corresponds to the external remote transport 1230 address of the TCP connection, and MUST add a DATA attribute 1231 containing the data received on the TCP connection. 1233 Note that, because data is forwarded blindly across TCP bindings, 1234 TLS will successfully operate over a TURN allocated TCP port if 1235 the linkage to the client is also TCP. 1237 10.1.2. UDP Processing 1239 If a server receives a UDP packet on an allocated UDP transport 1240 address, it checks the permissions associated with that allocation. 1241 If the source IP address of the UDP packet matches one of the 1242 permissions (the source port does not need to match), the UDP packet 1243 is accepted. Otherwise, it is discarded. If the packet is accepted, 1244 it is forwarded to the client. It will be forwarded in either 1245 encapsulated or unencapsulated form. 1247 If the client to server communication is via UDP, the server looks 1248 for the existence of the STUN magic cookie in the data received from 1249 the peer. If the data contains the magic cookie, the server 1250 encapsulates the data in a Data Indication, sets the REMOTE_ADDRESS 1251 attribute, and forwards the indication to the client. If the magic 1252 cookie is not present, the server checks if the peer is the active 1253 destination. If so the data is forwarded unencapsulated, directly to 1254 the client. Otherwise the server encapsulates the data in a Data 1255 Indication, sets the REMOTE_ADDRESS and forwards to the client. 1257 If the client to server communication is via TCP or TLS, the server 1258 checks if the peer is the active destination. If so, the data from 1259 the peer is framed as Data and sent to the client over the client to 1260 server connection. Otherwise, the server encapsulates the data in a 1261 Data Indication, sets the REMOTE_ADDRESS attribute, frames the 1262 indication as STUN traffic, and sends the indication over the 1263 connection to the client. If the TCP connection generates an error 1264 (because, for example, the incoming UDP packet rate exceeds the 1265 throughput of the TCP connection), the data is discarded silently by 1266 the server. 1268 10.2. Receiving Data on Internal Local Transport Addresses 1270 If a server receives non-STUN UDP data from the client on its 1271 internal local transport address, and it is coming from an internal 1272 remote transport address associated with an existing allocation, it 1273 represents UDP data that the client wishes to forward. If there is 1274 no allocation associated with the source IP address and port number, 1275 or if there is an associated allocation but the active destination is 1276 not set, the server MUST discard the packet. If the active 1277 destination is set, the server places the data from the client in a 1278 UDP payload, and sets the destination address and port to the active 1279 destination. The UDP packet is then sent with a source IP address 1280 and port equal to the allocated transport address. Note that the 1281 server will not retransmit the UDP datagram. 1283 If a server receives framed data on a TCP connection from a client, 1284 the server retrieves the allocation bound to that connection. If the 1285 active destination for the allocation is not set, the server MUST 1286 discard the data and close the connection. If the active destination 1287 is set, and the allocated transport protocol is TCP, the server 1288 forwards the data over the connection to the active destination. The 1289 data is then sent over that connection. If the connection is not 1290 established or if the transmission fails due to a TCP error, the data 1291 is discarded silently by the server. If the active destination is 1292 set, and the allocated transport protocol is UDP, the server places 1293 the data from the client in a UDP payload, and sets the destination 1294 address and port to the active destination. The UDP packet is then 1295 sent with a source IP address and port equal to the allocated 1296 transport address. Note that the server will not retransmit the UDP 1297 datagram. 1299 If a TCP connection from a client is closed, the associated 1300 allocation is destroyed. This involves terminating any TCP 1301 connections from the allocated transport address to external peer 1302 (applicable only when the allocated transport address was TCP), and 1303 then freeing the allocated transport address (and all associated 1304 state maintained by the server) for use by other clients. 1306 10.3. Lifetime Expiration 1308 When the allocation expiration timer for a binding fires, the server 1309 MUST destroy the allocation. This involves terminating any TCP 1310 connections from the allocated transport address to external peers 1311 (applicable only when the allocated transport address was TCP), and 1312 then freeing the allocated transport address (and all associated 1313 state maintained by the server) for use by other clients. A 1314 suggested value for the allocation expiration timer is 10 minutes. 1316 The server is also expected to run a permission inactivity timer for 1317 each permission associated with an Allocation. If no traffic from 1318 the client is received, the permission inactivity timer will 1319 eventually expire and the server MUST delete the permission. A 1320 suggested value for the permission inactivity timer for UDP 1321 allocations is 60 seconds. 1323 11. Client Discovery of TURN Servers 1325 The STUN relay extensions differ from the binding requests defined in 1326 [1] in that they demands substantial resources from the STUN server. 1327 In addition, it seems likely that administrators might want to block 1328 connections from clients to the STUN server for relaying separately 1329 from connections for the purposes of binding discovery. As a 1330 consequence, TURN is expected to typically run on a separate port 1331 from basic STUN. The client discovers the address and port of the 1332 TURN server using the same DNS procedures defined in [1], but using 1333 an SRV service name of "stun-relay" instead of just "stun". 1335 For example, to find TURN servers in the example.com domain, the TURN 1336 client performs a lookup for '_stun-relay._udp.example.com', '_stun- 1337 relay._tcp.example.com', and '_stun-relay._tls.example.com' if the 1338 STUN client wants to communicate with the TURN server using UDP, TCP, 1339 or TLS over TCP, respectively. The client assumes that all 1340 permissable transport protocols are supported from the TURN server to 1341 the peer for the client to server protocol selected. 1343 The STUN server is designed so the relay usage can run on a 1344 separate source port from non-relay usages. Since the client 1345 looks up the port number for the relay usage separately, servers 1346 can be configured to rely on this property. The STUN server MAY 1347 accept both relay and non-relay usages on the same port number, in 1348 which case it uses framing hints and choice of STUN messages to 1349 detect the STUN usage in use by a specific client. 1351 12. Security Considerations 1353 STUN servers implementing the TURN extensions allocate bandwidth and 1354 port resources to clients, in contrast to the Binding method defined 1355 in [1]. Therefore, a STUN server providing the relay usage requires 1356 authentication and authorization of STUN requests. This 1357 authentication is provided by mechanisms defined in the STUN 1358 specification itself. In particular, digest authentication and the 1359 usage of short-term passwords, obtained through a digest exchange 1360 over TLS, are available. The usage of short-term passwords ensures 1361 that the Allocate Requests, which often do not run over TLS, are not 1362 susceptible to offline dictionary attacks that can be used to guess 1363 the long lived shared secret between the client and the server. 1365 Because TURN servers allocate resources, they can be susceptible to 1366 denial-of-service attacks. All Allocate Requests are authenticated, 1367 so that an unknown attacker cannot launch an attack. An 1368 authenticated attacker can generate multiple Allocate Requests, 1369 however. To prevent a single malicious user from allocating all of 1370 the resources on the server, it is RECOMMENDED that a server 1371 implement a modest per user cap on the amount of bandwidth that can 1372 be allocated. Such a mechanism does not prevent a large number of 1373 malicious users from each requesting a small number of allocations. 1374 Attacks as these are possible using botnets, and are difficult to 1375 detect and prevent. Implementors of TURN should keep up with best 1376 practices around detection of anomalous botnet attacks. 1378 A client will use the transport address learned from the RELAY- 1379 ADDRESS attribute of the Allocate Response to tell other users how to 1380 reach them. Therefore, a client needs to be certain that this 1381 address is valid, and will actually route to them. Such validation 1382 occurs through the message integrity checks provided in the Allocate 1383 response. They can guarantee the authenticity and integrity of the 1384 allocated addresses. Note that TURN is not susceptible to the 1385 attacks described in Section 12.2.3, 12.2.4, 12.2.5 or 12.2.6 of RFC 1386 3489 [[TODO: Update references once 3489bis is more stable]]. These 1387 attacks are based on the fact that a STUN server mirrors the source 1388 IP address, which cannot be authenticated. STUN does not use the 1389 source address of the Allocate Request in providing the RELAY- 1390 ADDRESS, and therefore, those attacks do not apply. 1392 TURN cannot be used by clients for subverting firewall policies. 1393 TURN has fairly limited applicability, requiring a user to send a 1394 packet to a peer before being able to receive a packet from that 1395 peer. This applies to both TCP and UDP. Thus, it does not provide a 1396 general technique for externalizing TCP and UDP sockets. Rather, it 1397 has similar security properties to the placement of an address- 1398 restricted NAT in the network, allowing messaging in from a peer only 1399 if the internal client has sent a packet out towards the IP address 1400 of that peer. This limitation means that TURN cannot be used to run 1401 web servers, email servers, SIP servers, or other network servers 1402 that service a large number of clients. Rather, it facilitates 1403 rendezvous of NATted clients that use some other protocol, such as 1404 SIP, to communicate IP addresses and ports for communications. 1406 Confidentiality of the transport addresses learned through Allocate 1407 requests does not appear to be that important, and therefore, this 1408 capability is not provided. 1410 Relay servers are useful even for users not behind a NAT. They can 1411 provide a way for truly anonymous communications. A user can cause a 1412 call to have its media routed through a STUN server, so that the 1413 user's IP addresses are never revealed. 1415 TCP transport addresses allocated by Allocate requests will properly 1416 work with TLS and SSL. However, any relay addresses learned through 1417 an Allcoate will not operate properly with IPSec Authentication 1418 Header (AH) [5] in transport mode. IPSec ESP [6] and any tunnel-mode 1419 ESP or AH should still operate. 1421 13. IANA Considerations 1423 This specification defines several new STUN messages, STUN 1424 attributes, and STUN response codes. This section directs IANA to 1425 add these new protocol elements to the IANA registry of STUN protocol 1426 elements. 1428 13.1. New STUN Requests, Responses, and Indications 1430 Request/Response Transactions 1431 0x003 : Allocate 1432 0x004 : Set Active Destination 1433 0x005 : Connect 1435 Indications 1436 0x006 : Send 1437 0x007 : Data 1438 0x008 : Connect Status 1440 13.2. New STUN Attributes 1442 0x000D: LIFETIME 1443 0x0010: BANDWIDTH 1444 0x0012: REMOTE-ADDRESS 1445 0x0013: DATA 1446 0x0016: RELAY-ADDRESS 1447 0x0018: REQUESTED-PORT-PROPS 1448 0x0019: REQUESTED-TRANSPORT 1449 0x0022: REQUESTED-IP 1450 0x0021: TIMER-VAL 1451 0x0023: CONNECT_STAT 1453 13.3. New STUN response codes 1455 437 No Binding 1456 439 Active Destination Already Set 1457 442 Unsupported Transport Protocol 1458 443 Invalid IP Address 1459 444 Invalid Port 1460 445 Operation for TCP Only 1461 446 Connection Already Exists 1462 486 Allocation Quota Reached 1463 507 Insufficient Capacity 1465 14. IAB Considerations 1467 The IAB has studied the problem of "Unilateral Self Address Fixing", 1468 which is the general process by which a client attempts to determine 1469 its address in another realm on the other side of a NAT through a 1470 collaborative protocol reflection mechanism RFC 3424 [7]. The TURN 1471 extension is an example of a protocol that performs this type of 1472 function. The IAB has mandated that any protocols developed for this 1473 purpose document a specific set of considerations. 1475 TURN is an extension of the STUN protocol. As such, the specific 1476 usages of STUN that use the TURN extensions need to specifically 1477 address these considerations. Currently the only STUN usage that 1478 uses TURN is ICE [8]. 1480 15. Example 1482 In this example, a client is behind a NAT. The client has a private 1483 address of 10.0.1.1. The STUN server is on the public side of the 1484 NAT, and is listening for TURN requests on 192.0.2.3:8776. The 1485 public side of the NAT has an IP address of 192.0.2.1. The client is 1486 attempting to send a SIP INVITE to a peer, and wishes to allocate an 1487 IP address and port for inclusion in the SDP of the INVITE. 1488 Normally, TURNs would be used in conjunction with ICE when applied to 1489 SIP. For simplicities sake, TURN is showed without ICE. 1491 The client communicates with a SIP user agent on the public network. 1492 This user agent uses a 192.0.2.17:12734 for receipt of its RTP 1493 packets. 1495 Client NAT STUN Server Peer 1496 | | | | 1497 |(1) Allocate | | | 1498 |S=10.0.1.1:4334 | | | 1499 |D=192.0.2.3:8776 | | | 1500 |------------------>| | | 1501 | | | | 1502 | |(2) Allocate | | 1503 | |S=192.0.2.1:63346 | | 1504 | |D=192.0.2.3:8776 | | 1505 | |------------------>| | 1506 | | | | 1507 | |(3) Error | | 1508 | |S=192.0.2.3:8776 | | 1509 | |D=192.0.2.1:63346 | | 1510 | |<------------------| | 1511 | | | | 1512 |(4) Error | | | 1513 |S=192.0.2.3:8776 | | | 1514 |D=10.0.1.1:4334 | | | 1515 |<------------------| | | 1516 | | | | 1517 |(5) Allocate | | | 1518 |S=10.0.1.1:4334 | | | 1519 |D=192.0.2.3:8776 | | | 1520 |------------------>| | | 1521 | | | | 1522 | |(6) Allocate | | 1523 | |S=192.0.2.1:63346 | | 1524 | |D=192.0.2.3:8776 | | 1525 | |------------------>| | 1526 | | | | 1527 | |(7) Response | | 1528 | |RA=192.0.2.3:32766 | | 1529 | |MA=192.0.2.1:63346 | | 1530 | |S=192.0.2.3:8776 | | 1531 | |D=192.0.2.1:63346 | | 1532 | |<------------------| | 1533 |(8) Response | | | 1534 |RA=192.0.2.3:32766 | | | 1535 |MA=192.0.2.1:63346 | | | 1536 |S=192.0.2.3:8776 | | | 1537 |D=10.0.1.1:4334 | | | 1538 |<------------------| | | 1539 | | | | 1540 | | | | 1541 |(9) INVITE | | | 1542 |SDP=192.0.2.3:32766| | | 1543 |---------------------------------------------------------->| 1544 | | | | 1545 | | | | 1546 |(10) 200 OK | | | 1547 |SDP=192.0.2.17:12734 | | 1548 |<----------------------------------------------------------| 1549 | | | | 1550 | | | | 1551 | | | | 1552 |(11) ACK | | | 1553 |---------------------------------------------------------->| 1554 | | | | 1555 |(12) Send | | | 1556 |DATA=RTP | | | 1557 |DA=192.0.2.17:12734| | | 1558 |S=10.0.1.1:4334 | | | 1559 |D=192.0.2.3:8776 | | | 1560 |------------------>| | | 1561 | | | | 1562 | |(13) Send | | 1563 | |DATA=RTP | | 1564 | |DA=192.0.2.17:12734| | 1565 | |S=192.0.2.1:63346 | | 1566 | |D=192.0.2.3:8776 | | 1567 | |------------------>| | 1568 | | | | 1569 | | |(14) RTP | 1570 | | |S=192.0.2.3:32766 | 1571 | | |D=192.0.2.17:12734 | 1572 | | |------------------>| 1573 | | | | 1574 | | |Permission | 1575 | | |Created | 1576 | | |192.0.2.17 | 1577 | | | | 1578 | | |(15) RTP | 1579 | | |S=192.0.2.17:12734 | 1580 | | |D=192.0.2.3:32766 | 1581 | | |<------------------| 1582 | | | | 1583 | |(16) DataInd | | 1584 | |DATA=RTP | | 1585 | |RA=192.0.2.17:12734| | 1586 | |S=192.0.2.3:8776 | | 1587 | |D=192.0.2.1:63346 | | 1588 | |<------------------| | 1589 |(17) DataInd | | | 1590 |DATA=RTP | | | 1591 |RA=192.0.2.17:12734| | | 1592 |S=192.0.2.3:8776 | | | 1593 |D=10.0.1.1:4334 | | | 1594 |<------------------| | | 1595 | | | | 1596 |(18) SetAct | | | 1597 |DA=192.0.2.17:12734| | | 1598 |S=10.0.1.1:4334 | | | 1599 |D=192.0.2.3:8776 | | | 1600 |------------------>| | | 1601 | | | | 1602 | |(19) SetAct | | 1603 | |DA=192.0.2.17:12734| | 1604 | |S=192.0.2.1:63346 | | 1605 | |D=192.0.2.3:8776 | | 1606 | |------------------>| | 1607 | | | | 1608 | |(20) Response | | 1609 | |S=192.0.2.3:8776 | | 1610 | |D=192.0.2.1:63346 | | 1611 | |<------------------| | 1612 | | | | 1613 |(21) Response | | | 1614 |S=192.0.2.3:8776 | | | 1615 |D=10.0.1.1:4334 | | | 1616 |<------------------| | | 1617 | | | | 1618 | | | | 1619 | | | after 3s| 1620 | | | | 1621 | | | | 1622 | | |(22) RTP | 1623 | | |S=192.0.2.17:12734 | 1624 | | |D=192.0.2.3:32766 | 1625 | | |<------------------| 1626 | | | | 1627 | |(23) RTP | | 1628 | |S=192.0.2.3:8776 | | 1629 | |D=192.0.2.1:63346 | | 1630 | |<------------------| | 1631 | | | | 1632 |(24) RTP | | | 1633 |S=192.0.2.3:8776 | | | 1634 |D=10.0.1.1:4334 | | | 1635 |<------------------| | | 1636 | | | | 1637 | | | | 1639 Figure 14 1641 The call flow is shown in Figure 14. The client allocates a port 1642 from the local operating system on its private interface, obtaining 1643 4334. It then attempts to secure a port for RTP traffic. RTCP 1644 processing is not shown. The client sends an Allocate request (1) 1645 with a source address (denoted by S) of 10.0.1.1:4334 and a 1646 destination (denoted by D) of 192.0.2.3:8776. This passes through 1647 the NAT (2), which creates a mapping from the 192.0.2.1:63346 to the 1648 source IP address and port of the request, 10.0.1.1:4334. This 1649 request is received at the STUN server, which challenges it (3), 1650 requesting credentials. This response is passed to the client (4). 1651 The client retries the request, this time with credentials (5). This 1652 arrives at the server (6). The request is now authenticated. The 1653 server provides a UDP allocation, 192.0.2.3:32766, and places it into 1654 the RELAY-ADDRESS (denoted by RA) in the response (7). It also 1655 reflects the source IP address and port of the request into the 1656 MAPPED-ADDRESS (denoted by MA) in the response. This passes through 1657 the NAT to the client (8). The client now proceeds to perform a 1658 basic SIP call setup. In message 9, it includes the relay address 1659 into the SDP of its INVITE. The called party responds with a 200 OK, 1660 and includes its IP address - 192.0.2.17:12734. The exchange 1661 completes with an ACK (11). 1663 Next, user A sends an RTP packet. Since the active destination has 1664 not been set, the client decides to use the Send indication. It does 1665 so, including the RTP packet as the contents of the DATA attribute. 1666 The REMOTE-ADDRESS attribute (denoted by DA) is set to 192.0.2.17: 1667 12734, learned from the 200 OK. This is sent through the NAT 1668 (message 12) and arrives at the STUN server (message 13). The server 1669 extracts the data contents, and sends the packet towards REMOTE- 1670 ADDRESS (message 14). Note how the source address and port in this 1671 packet is 192.0.2.3:32766, the allocated transport address given to 1672 the client. The act of sending the packet with Send causes the STUN 1673 server to install a permission for 192.0.2.17. 1675 Indeed, the called party now sends an RTP packet toward the client 1676 (message 15). This arrives at the STUN server. Since a permission 1677 has been set for the IP address in the source of this packet, it is 1678 accepted. As no active destination is set, the STUN server 1679 encapsulates the contents of the packet in a Data Indication (message 1680 16), and sends it towards the client. The REMOTE-ADDRESS attribute 1681 (denoted by RA) indicates the source of the packet - 192.0.2.17: 1682 12734. This is forwarded through the NAT to the client (message 17). 1684 The client decides to optimize the path for packets to and from 1685 192.0.2.17:12734. So, it issues a Set Active Destination request 1686 (message 18) with a REMOTE-ADDRESS of 192.0.2.17:12734. This passes 1687 through the NAT and arrives at the STUN server (message 19). This 1688 generates a successful response (message 20) which is passed to the 1689 client (message 21). At this point, the server and client are in the 1690 transitioning state. A little over 3 seconds later (by default), the 1691 state machines transition back to "Set". Until this point, packets 1692 from the called party would have been relayed back to the client in 1693 Data Indications. Now, the next RTP packet shows up at the STUN 1694 server (message 22). Since the source IP address and port match the 1695 active destination, the RTP packet is relayed towards the client 1696 without encapsulation (message 23 and 24). 1698 16. Acknowledgements 1700 The authors would like to thank Marc Petit-Huguenin for his comments 1701 and suggestions. 1703 17. References 1705 17.1. Normative References 1707 [1] Rosenberg, J., "Session Traversal Utilities for (NAT) (STUN)", 1708 draft-ietf-behave-rfc3489bis-06 (work in progress), March 2007. 1710 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1711 Levels", BCP 14, RFC 2119, March 1997. 1713 17.2. Informative References 1715 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1716 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1717 RFC 3550, July 2003. 1719 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1720 Session Description Protocol (SDP)", RFC 3264, June 2002. 1722 [5] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 1724 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1725 December 2005. 1727 [7] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1728 Address Fixing (UNSAF) Across Network Address Translation", 1729 RFC 3424, November 2002. 1731 [8] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1732 Protocol for Network Address Translator (NAT) Traversal for 1733 Offer/Answer Protocols", draft-ietf-mmusic-ice-16 (work in 1734 progress), June 2007. 1736 [9] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 1737 Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), 1738 October 2006. 1740 Authors' Addresses 1742 Jonathan Rosenberg 1743 Cisco Systems 1744 600 Lanidex Plaza 1745 Parsippany, NJ 07054 1746 US 1748 Phone: +1 973 952-5000 1749 Email: jdrosen@cisco.com 1750 URI: http://www.jdrosen.net 1752 Rohan Mahy 1753 Plantronics 1755 Email: rohan@ekabal.com 1757 Christian Huitema 1758 Microsoft 1759 One Microsoft Way 1760 Redmond, WA 98052-6399 1761 US 1763 Email: huitema@microsoft.com 1765 Full Copyright Statement 1767 Copyright (C) The IETF Trust (2007). 1769 This document is subject to the rights, licenses and restrictions 1770 contained in BCP 78, and except as set forth therein, the authors 1771 retain all their rights. 1773 This document and the information contained herein are provided on an 1774 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1775 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1776 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1777 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1778 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1779 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1781 Intellectual Property 1783 The IETF takes no position regarding the validity or scope of any 1784 Intellectual Property Rights or other rights that might be claimed to 1785 pertain to the implementation or use of the technology described in 1786 this document or the extent to which any license under such rights 1787 might or might not be available; nor does it represent that it has 1788 made any independent effort to identify any such rights. Information 1789 on the procedures with respect to rights in RFC documents can be 1790 found in BCP 78 and BCP 79. 1792 Copies of IPR disclosures made to the IETF Secretariat and any 1793 assurances of licenses to be made available, or the result of an 1794 attempt made to obtain a general license or permission for the use of 1795 such proprietary rights by implementers or users of this 1796 specification can be obtained from the IETF on-line IPR repository at 1797 http://www.ietf.org/ipr. 1799 The IETF invites any interested party to bring to its attention any 1800 copyrights, patents or patent applications, or other proprietary 1801 rights that may cover technology that may be required to implement 1802 this standard. Please address the information to the IETF at 1803 ietf-ipr@ietf.org. 1805 Acknowledgment 1807 Funding for the RFC Editor function is provided by the IETF 1808 Administrative Support Activity (IASA).