idnits 2.17.1 draft-ietf-behave-turn-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1971. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1977. 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 (March 4, 2007) is 6263 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: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 Summary: 1 error (**), 0 flaws (~~), 4 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: September 5, 2007 Plantronics 6 C. Huitema 7 Microsoft 8 March 4, 2007 10 Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN) 11 draft-ietf-behave-turn-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 5, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This specification defines a usage of the Simple Traversal Underneath 45 NAT (STUN) Protocol for asking the STUN server to relay packets 46 towards a client. This usage is useful for elements behind NATs 47 whose mapping behavior is address and port dependent. The extension 48 purposefully restricts the ways in which the relayed address can be 49 used. In particular, it prevents users from running general purpose 50 servers from ports obtained from the STUN server. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.2. Tuple Terminology . . . . . . . . . . . . . . . . . . . . 8 60 4.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 9 61 5. New Framing Mechanism for Stream-Oriented Transports . . . . . 10 62 6. New STUN Requests and Indications . . . . . . . . . . . . . . 10 63 6.1. Allocate Request . . . . . . . . . . . . . . . . . . . . . 11 64 6.1.1. Client Behavior . . . . . . . . . . . . . . . . . . . 11 65 6.1.2. Server Behavior . . . . . . . . . . . . . . . . . . . 13 66 6.2. Procedures for all other Requests and Indications . . . . 17 67 6.3. Set Active Destination Request . . . . . . . . . . . . . . 18 68 6.3.1. Client Behavior . . . . . . . . . . . . . . . . . . . 18 69 6.3.2. Server Behavior . . . . . . . . . . . . . . . . . . . 19 70 6.4. Connect Request . . . . . . . . . . . . . . . . . . . . . 19 71 6.4.1. Server Behavior . . . . . . . . . . . . . . . . . . . 19 72 6.5. Connection Status Indication . . . . . . . . . . . . . . . 20 73 6.6. Send Indication . . . . . . . . . . . . . . . . . . . . . 20 74 6.6.1. Client Behavior . . . . . . . . . . . . . . . . . . . 20 75 6.6.2. Server Behavior . . . . . . . . . . . . . . . . . . . 21 76 6.7. Data Indication . . . . . . . . . . . . . . . . . . . . . 21 77 6.7.1. Client Behavior . . . . . . . . . . . . . . . . . . . 21 78 6.7.2. Server Behavior . . . . . . . . . . . . . . . . . . . 22 79 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 22 80 7.1. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 7.2. BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . 23 82 7.3. REMOTE-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 23 83 7.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 7.5. RELAY-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 23 85 7.6. REQUESTED-PORT-PROPS . . . . . . . . . . . . . . . . . . . 23 86 7.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 24 87 7.8. REQUESTED-IP . . . . . . . . . . . . . . . . . . . . . . . 25 88 7.9. CONNECT_STAT . . . . . . . . . . . . . . . . . . . . . . . 25 89 8. New Error Response Codes . . . . . . . . . . . . . . . . . . . 25 90 9. Client Procedures . . . . . . . . . . . . . . . . . . . . . . 26 91 9.1. Receiving and Sending Unencapsulated Data . . . . . . . . 26 92 9.1.1. Datagram Protocols . . . . . . . . . . . . . . . . . . 26 93 9.1.2. Stream Transport Protocols . . . . . . . . . . . . . . 27 94 10. Server Procedures . . . . . . . . . . . . . . . . . . . . . . 27 95 10.1. Receiving Data on Allocated Transport Addresses . . . . . 27 96 10.1.1. TCP Processing . . . . . . . . . . . . . . . . . . . . 27 97 10.1.2. UDP Processing . . . . . . . . . . . . . . . . . . . . 28 98 10.2. Receiving Data on Internal Local Transport Addresses . . . 28 99 10.3. Lifetime Expiration . . . . . . . . . . . . . . . . . . . 29 100 11. Formal Definition of STUN Usage . . . . . . . . . . . . . . . 29 101 11.1. Applicability Statement . . . . . . . . . . . . . . . . . 29 102 11.2. Client Discovery of Server . . . . . . . . . . . . . . . . 30 103 11.3. Server Determination of Usage . . . . . . . . . . . . . . 31 104 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 105 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 106 13.1. New STUN Requests, Responses, and Indications . . . . . . 33 107 13.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 33 108 13.3. New STUN response codes . . . . . . . . . . . . . . . . . 34 109 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 34 110 14.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 34 111 14.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 35 112 14.3. Brittleness Introduced by STUN relays . . . . . . . . . . 35 113 14.4. Requirements for a Long Term Solution . . . . . . . . . . 36 114 14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 36 115 15. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 116 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 117 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 118 17.1. Normative References . . . . . . . . . . . . . . . . . . . 41 119 17.2. Informative References . . . . . . . . . . . . . . . . . . 42 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 121 Intellectual Property and Copyright Statements . . . . . . . . . . 44 123 1. Introduction 125 The Simple Traversal Underneath NAT (STUN) [1] provides a suite of 126 tools for facilitating the traversal of NAT. Specifically, it 127 defines the Binding Request, which is used by a client to determine 128 its reflexive transport address towards the STUN server. The 129 reflexive transport address can be used by the client for receiving 130 packets from peers, but only when the client is behind "good" NATs. 131 In particular, if a client is behind a NAT whose mapping behavior 132 [10] is address or address and port dependent (sometimes called "bad" 133 NATs), the reflexive transport address will not be usable for 134 communicating with a peer. 136 The only way to obtain a transport address that can be used for 137 corresponding with a peer through such a NAT is to make use of a 138 relay. The relay sits on the public side of the NAT, and allocates 139 transport addresses to clients reaching it from behind the private 140 side of the NAT. These allocated addresses are from interfaces on 141 the relay. When the relay receives a packet on one of these 142 allocated addresses, the relay forwards it toward the client. 144 This specification defines a usage of STUN, called the relay usage, 145 that allows a client to request an address on the STUN server itself, 146 so that the STUN server acts as a relay. To accomplish that, this 147 usage defines a handful of new STUN requests and indications. The 148 Allocate request is the most fundamental component of this usage. It 149 is used to provide the client with a transport address that is 150 relayed through the STUN server. A transport address which relays 151 through an intermediary is called a relayed transport address. 153 Though a relayed address is highly likely to work when corresponding 154 with a peer, it comes at high cost to the provider of the relay 155 service. As a consequence, relayed transport addresses should only 156 be used as a last resort. Protocols using relayed transport 157 addresses should make use of mechanisms to dynamically determine 158 whether such an address is actually needed. One such mechanism, 159 defined for multimedia session establishment protocols, based on the 160 offer/answer protocol in RFC 3264 [5], is Interactive Connectivity 161 Establishment (ICE) [9]. 163 The mechanism defined here was previously a standalone protocol 164 called Traversal Using Relay NAT (TURN), and is now defined as a 165 usage of STUN. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [2]. 173 3. Definitions 175 Relayed Transport Address: A transport address that terminates on a 176 server, and is forwarded towards the client. The STUN Allocate 177 Request can be used to obtain a relayed transport address, for 178 example. 180 STUN relay client: A STUN client that implements this specification. 181 It obtains a relayed transport address that it provides to a small 182 number of peers (usually one). 184 STUN relay server: A STUN server that implements this specification. 185 It relays data between a STUN relay client and its peer. 187 5-tuple: A combination of the source IP address and port, 188 destination IP address and port, and transport protocol (UDP, TCP, 189 or TLS over TCP). It uniquely identifies a TCP connection, TLS 190 channel, or bi-directional flow of UDP datagrams. 192 permission: TBD 194 4. Overview of Operation 196 In a typical configuration, a STUN relay client is connected to a 197 private network and through one or more NATs to the public Internet. 198 On the public Internet is a STUN relay server. The STUN Relay usage 199 defines several new messages and a new framing mechanism that add the 200 ability for a STUN server to act as a packet relay. The text in this 201 section 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 the STUN relay usage happen in the context of an 207 allocation. 209 A successful Allocate Request just reserves an address on the STUN 210 relay server. Data does not flow through an allocated port until the 211 STUN relay client asks the STUN relay server to open a permission. 212 It can do this by sending data to the far end with a Send Indication 213 for UDP allocations, by sending a ConnectRequest for TCP allocations, 214 or by setting the default destination for either transport. While 215 the client can request more than one permission per allocation, it 216 needs to request each permission explicitly and one at a time. This 217 insures that a client can't use a STUN relay server to run a 218 traditional server, and partially protects the client from DoS 219 attacks. 221 Once a permission is open, the client can then receive data flowing 222 back from its peer. Initially this data is wrapped in a STUN Data 223 Indication. Since multiple permissions can be open simultaneously, 224 the Data Indication contains the Remote Address attribute so the STUN 225 relay client knows which peer sent the data. The client can send 226 data to any of its peers with the Send Indication. 228 Once the client wants to primarily receive from one peer, it can send 229 a SetActiveDestination request. All subsequent data received from 230 the active peer is forwarded directly to the client and vice versa, 231 except that it is wrapped or framed according to the protocol used 232 between the STUN relay client and STUN relay server. The client can 233 send subsequent SetActiveDestination requests to change or remove the 234 active destination. 236 When the STUN relay client to server communication is over a datagram 237 protocol (UDP), any datagram received from the active peer that has 238 the STUN magic cookie is wrapped in a Data Indication. Likewise any 239 datagram sent by the client that has the STUN magic cookie and is 240 intended for the active peer is wrapped in a Send Indication. This 241 wrapping prevents the STUN relay server from inappropriately 242 interpreting end-to-end data. 244 Over stream-based transports (TCP and TLS over TCP), the STUN relay 245 client and server always use some additional framing (defined in 246 Section 5) so that end-to-end data is distinguishable from STUN 247 control messages. This additional framing just has a type and a 248 length field. The value of the type field was chosen so it is always 249 distinguishable from an unframed STUN request or response. 251 The SetActiveDestination Request does not close other bindings. Data 252 to and from other peers is still wrapped in Send and Data indications 253 respectively. 255 Allocations can also request specific attributes such as the desired 256 Lifetime of the allocation, and the maximum Bandwidth. Clients can 257 also request specific port assignment behavior, for example, a 258 specific port number, odd or even port numbers, or pairs of 259 sequential port numbers. 261 4.1. Transports 263 STUN relay clients can communicate with a STUN relay server using 264 UDP, TCP, or TLS over TCP. A STUN relay can even relay traffic 265 between two different transports with certain restrictions. A STUN 266 relay can never relay from an unreliable transport (client to server) 267 to a reliable transport to the peer. Note that a STUN relay server 268 never has a TLS relationship with a client's peer, since the STUN 269 relay server does not interpret data above the TCP layer. When 270 relaying data sent from a stream-based protocol to a UDP peer, the 271 STUN relay server emits datagrams which are the same length as the 272 length field in the STUN TCP framing or the length field in a Send 273 Indication. Likewise, when a UDP datagram is relayed from a peer 274 over a stream-based transport, the length of the datagram is the 275 length of the TCP framing or Data Indication. 277 +----------------------+--------------------+ 278 | client to STUN relay | STUN relay to peer | 279 +----------------------+--------------------+ 280 | UDP | UDP | 281 | TCP | TCP | 282 | TCP | UDP | 283 | TLS | TCP | 284 | TLS | UDP | 285 +----------------------+--------------------+ 287 For STUN relay clients, using TLS over TCP provides two benefits. 288 When using TLS, the client can be assured that the address of the 289 client's peers are not visible to an attacker except by traffic 290 analysis downstream of the STUN relay server. Second, the client may 291 be able to communicate with STUN relay servers using TLS that it 292 would not be able to communicate with using TCP or UDP due to the 293 configuration of a firewall between the STUN relay client and its 294 server. TLS between the client and STUN relay server in this case 295 just facilitates traversal. 297 For TCP connections, the Connection Request allows the client to ask 298 the server to open a connection to the peer. This also adds a 299 permission to accept an incoming TCP connection from the remote 300 address of the peer. When the server and the peer try to open a TCP 301 connection at the same time, this is called TCP simultaneous open. 303 When the STUN relay-to-peer leg is TCP, the STUN relay client needs 304 to be aware of the status of these TCP connections. The STUN relay 305 extension defines application states for a TCP connection as follows: 306 LISTEN, ESTABLISHED, and CLOSED. Consequently, the STUN relay server 307 sends a ConnectionState Indication for a binding whenever the relay 308 connection status changes for one of the client's bindings, except 309 when the status changes due to a STUN relay client request (ex: an 310 explicit binding deallocation). 312 4.2. Tuple Terminology 314 To relay data to and from the correct location, the STUN relay server 315 maintains an association between an internal address (called a 316 5-tuple) and one or more external 5-tuples, as shown in Figure 1. 317 The internal 5-tuple identifies the path between the STUN relay 318 client and the STUN relay server. It consists of the protocol (UDP, 319 TCP, or TLS over TCP), the internal local IP address and port number 320 and the source IP address and port number of the STUN client, as seen 321 by the relay server. For example, for UDP, the internal 5-tuple is 322 the combination of the IP address and port from which the STUN client 323 sent its Allocate Request, with the IP address and port from which 324 the corresponding Allocate Response was sent. 326 The external local transport address is the IP address and port 327 allocated to the STUN relay client (the allocated transport address). 328 The external 5-tuple is the combination of the external local 329 transport address and the IP address and port of an external client 330 that the STUN client is communicating with through the STUN server. 331 Initially, there aren't any external 5-tuples, since the STUN client 332 hasn't communicated with any other hosts yet. As packets are 333 received on or sent from the allocated transport address, external 334 5-tuples are created. 336 While the terminology used in this document refers to 5-tuples, 337 the STUN relay server can store whatever identifier it likes that 338 yields identical results. Specifically, many implementations may 339 use a file-descriptor in place of a 5-tuple to represent a TCP 340 connection. 342 +---------+ 343 | | 344 | External| 345 / | Client | 346 // | | 347 / | | 348 // +---------+ 349 / 350 // 351 +-+ / 352 | | / 353 | | // 354 +---------+ | | +---------+ / +---------+ 355 | | |N| | | // | | 356 | STUN | | | | |/ | External| 357 | Client |----|A|----------| STUN |------------------| Client | 358 | | | |^ ^| Server |^ ^| | 359 | | |T|| || || || | 360 +---------+ | || |+---------+| |+---------+ 361 ^ | || | | | 362 | | || | | | 363 | +-+| | | | 364 | | | | | 365 | 366 Internal Internal External External 367 Client Remote Local Local Remote 368 Performing Transport Transport Transport Transport 369 Allocations Address Address Address Address 371 | | | | 372 +-----+----+ +--------+-------+ 373 | | 374 | | 376 Internal External 377 5-Tuple 5-tuple 379 Figure 1 381 4.3. Keepalives 383 Since the main purpose of STUN and the relay extension are to 384 traverse NATs, it is natural to consider which elements are 385 responsible for generating sufficient periodic traffic to insure that 386 NAT bindings stay alive. Relay clients need to send data frequently 387 enough to keep both NAT bindings and the STUN relay server internal 388 permissions fresh. Like NAT bindings, the STUN relay server bindings 389 are refreshed by ordinary data traffic relayed to and from the peer. 391 Unlike permissions, allocations on the STUN relay server have an 392 explicit expiration time and need to be refreshed explicitly by the 393 client. When an allocation expires, all permissions associated with 394 that allocation are automatically deleted. 396 5. New Framing Mechanism for Stream-Oriented Transports 398 Over stream-based transports, the STUN relay client and server need 399 to use additional framing so that end-to-end data is distinguishable 400 from STUN control messages, and so that the relay server can perform 401 conversion from streams to datagrams and vice versa. This additional 402 framing has a one octet type, one reserved octet, and a 2 octet 403 length field. The first octet of this framing is 0x02 to indicate 404 STUN messages or 0x03 to indicate end-to-end data to or from the 405 active destination. Note that the first octet is always 406 distinguishable from an unframed STUN request or response (which is 407 always 0x00 or 0x01). The second octet is reserved and MUST be set 408 to zero. The length field counts the number of octets immediately 409 after the length field itself. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type | Reserved = 0 | Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Use of this framing mechanism is discussed in Section 9 and 418 Section 10. 420 6. New STUN Requests and Indications 422 This usage defines three new requests (along with their success and 423 error responses) and three indications. It also defines processing 424 rules for the STUN server and client on receipt of non-STUN messages. 425 See Section 9 and Section 10 427 The new messages are: 429 Request/Response Transactions 430 0x003 : Allocate 431 0x004 : Set Active Destination 432 0x005 : Connect 434 Indications 435 0x001 : Send 436 0x002 : Data 437 0x003 : Connect Status 439 In addition to STUN Messages (Requests, Responses, and Indications), 440 STUN relay clients and servers send and receive non-STUN packets on 441 the same ports used for STUN messages. How these entities 442 distinguish STUN and non-STUN traffic is discussed in Section 9 and 443 Section 10. 445 6.1. Allocate Request 447 6.1.1. Client Behavior 449 Client behavior for Allocate requests depends on whether the request 450 is an initial one, for the purposes of obtaining a new relayed 451 transport address, or a subsequent one, used for refreshing an 452 existing allocation. 454 6.1.1.1. Initial Requests 456 When a client wishes to obtain a transport address, it sends an 457 Allocate Request to the server. This request is constructed and sent 458 using the general procedures defined in [1]. The server will 459 challenge the request for credentials. The client MAY either provide 460 its credentials to the server directly, or it MAY obtain a short-term 461 set of credentials using the Shared Secret request and then use those 462 as the credentials in the Allocate request. 464 The client SHOULD include a BANDWIDTH attribute, which indicates the 465 maximum bandwidth that will be used with this binding. If the 466 maximum is unknown, the attribute is not included in the request. 468 The client MAY request a particular lifetime for the allocation by 469 including it in the LIFETIME attribute in the request. The default 470 lifetime is 10 minutes. 472 The client MAY include a REQUESTED-PORT-PROPS, REQUESTED-TRANSPORT, 473 or REQUESTED-IP attribute in the request to obtain specific types of 474 transport addresses. Whether these are needed depends on the 475 application using the relay usage. As an example, the Real Time 476 Transport Protocol (RTP) [3] requires that RTP and RTCP ports be an 477 adajacent pair, even and odd respectively, for compatibility with a 478 previous version of that specification. The REQUESTED-PORT-PROPS 479 attribute allows the client to ask the relay for those properties. 480 The client MUST NOT request the TCP transport in an Allocate request 481 sent to the STUN relay server over UDP. 483 Processing of the response follows the general procedures of [1]. A 484 successful response will include both a RELAY-ADDRESS and an XOR- 485 MAPPED-ADDRESS attribute, providing both a relayed transport address 486 and a reflexive transport address, respectively, to the client. The 487 server will expire the allocation after LIFETIME seconds have passed 488 if not refreshed by another Allocate request. The server will allow 489 the user to send and receive at least the amount of data indicated in 490 the BANDWIDTH attribute per allocation. (At its discretion the 491 server can optionally discard data above this threshold.) 493 If the response is an error response and contains a 442, 443 or 444 494 error code, the client knows that its requested properties could not 495 be met. The client MAY retry with different properties, with the 496 same properties (in a hope that something has changed on the server), 497 or give up, depending on the needs of the application. However, if 498 the client retries, it SHOULD wait 500ms, and if the request fails 499 again, wait 1 second, then 2 seconds, and so on, exponentially 500 backing off. 502 6.1.1.2. Subsequent Requests 504 Before 3/4 of the lifetime of the allocation has passed (the lifetime 505 of the allocation is conveyed in the LIFETIME attribute of the 506 Allocate Response), the client SHOULD refresh the allocation with 507 another Allocate Request if it wishes to keep the allocation. 509 To perform a refresh, the client generates an Allocate Request as 510 described in Section 6.1.1.1. If the initial request was 511 authenticated with a shared secret P that the client holds with the 512 server, or using a short term password derived from P through a 513 Shared Secret request, the client MUST use shared secret P, or a 514 short-term password derived from it, in the subsequent request. 516 In a successful response, the RELAY-ADDRESS contains the same 517 transport address as previously obtained, indicating that the binding 518 has been refreshed. The LIFETIME attribute indicates the amount of 519 additional time the binding will live without being refreshed. Note 520 that an error response does not imply that the binding has been 521 expired, just that the refresh has failed. 523 If a client no longer needs an allocation, it SHOULD perform an 524 explict deallocation. If the client wishes to explicitly remove the 525 allocation because it no longer needs it, it generates a subsequent 526 Allocate request, but sets the LIFETIME attribute to zero. This will 527 cause the server to remove the allocation, and all associated 528 bindings. For connection-oriented transports such as TCP, the client 529 can also remove the allocation (and all associated bindings) by 530 closing the relevant connection with the STUN relay server. 532 6.1.2. Server Behavior 534 The server first processes the request according to the general 535 request processing rules in [1]. This includes performing 536 authentication, and checking for mandatory unknown attributes. Due 537 to the fact that the STUN server is allocating resources for 538 processing the request, Allocate requests MUST be authenticated, and 539 furthermore, MUST be authenticated using either a shared secret known 540 between the client and server, or a short term password derived from 541 it. 543 Note that Allocate requests, like most other STUN requests, can be 544 sent to the STUN server over UDP, TCP, or TCP/TLS. 546 The behavior of the server when receiving an Allocate Request depends 547 on whether the request is an initial one, or a subsequent one. An 548 initial request is one whose source and destination transport address 549 do not match the internal remote and local transport addresses of an 550 existing internal 5-tuple. A subsequent request is one whose source 551 and destination transport address matches the internal remote and 552 local transport address of an existing internal 5-tuple. 554 6.1.2.1. Initial Requests 556 The server attempts to allocate transport addresses. It first looks 557 for the BANDWIDTH attribute for the request. If present, the server 558 determines whether or not it has sufficient capacity to handle a 559 binding that will generate the requested bandwidth. 561 If it does, the server attempts to allocate a transport address for 562 the client. The Allocate request can contain several additional 563 attributes that allow the client to request specific characteristics 564 of the transport address. First, the server checks for the 565 REQUESTED-TRANSPORT attribute. This indicates the transport protocol 566 requested by the client. This specification defines values for UDP 567 and TCP. 569 As a consequence of the REQUESTED-TRANSPORT attribute, it is 570 possible for a client to connect to the server over TCP or TLS 571 over TCP and request a UDP transport address. In this case, the 572 server will relay data between the transports. 574 If the requested transport is supported, the server allocates a port 575 using the requested transport protocol. If the REQUESTED-TRANSPORT 576 attribute contains a value of the transport protocol unknown to the 577 server, or known to the server but not supported by the server in the 578 context of this request, the server MUST reject the request and 579 include a 442 (Unsupported Transport Protocol) in the response, or 580 redirect the request. If the request did not contain a REQUESTED- 581 TRANSPORT attribute, the server MUST use the same transport protocol 582 as the request arrived on. 584 Next, the server checks for the REQUESTED-IP attribute. If present, 585 it indicates a specific interface from which the client would like 586 its transport address allocated. If this interface is not a valid 587 one for allocations on the server, the server MUST reject the request 588 and include a 443 (Invalid IP Address) error code in the response, or 589 else redirect the request to a server that is known to support this 590 IP address. If the IP address is one that is valid for allocations 591 (presumably, the server is configured to know the set of IP addresses 592 from which it performs allocations), the server MUST provide an 593 allocation from that IP address. If the attribute is not present, 594 the selection of an IP address is at the discretion of the server. 596 Finally, the server checks for the REQUESTED-PORT-PROPS attribute. 597 If present, it indicates specific port properties desired by the 598 client. This attribute is split into two portions: one portion for 599 port behavior and the other for requested port alignment (whether the 600 allocated port is odd, even, reserved as a pair, or at the discretion 601 of the server). 603 If the port behavior requested is for a Specific Port, the server 604 MUST attempt to allocate that specific port for the client. If the 605 port is allocated to a different internal 5-tuple associated with the 606 same STUN long-term credentials, the client is requesting a move. 607 The server SHOULD replace the old internal 5-tuple with the new tuple 608 over which this Allocate request arrived. The server MUST reject the 609 move request if any of the attributes other than LIFETIME have 610 changed (BANDWIDTH, REQUESTED-TRANSPORT, etc.). 612 If the specific port is not available (in use or reserved), the 613 server MUST reject the request with a 444 (Invalid Port) response or 614 redirect to an alternate server. For example, the STUN server could 615 reject a request for a Specific Port because the port is temporarily 616 reserved as part of an adjacent pair of ports, or because the 617 requested port is a well-known port (1-1023). 619 If the client requests "even" port alignment, the server MUST attempt 620 to allocate an even port for the client. If an even port cannot be 621 obtained, the server MUST reject the request with a 444 (Invalid 622 Port) response or redirect to an alternate server. If the client 623 requests odd port alignment, the server MUST attempt to allocate an 624 odd port for the client. If an odd port cannot be obtained, the 625 server MUST reject the request with a 444 (Invalid Port) response or 626 redirect to an alternate server. Finally, the "Even port with hold 627 of the next higher port" alignment is similar to requesting an even 628 port. It is a request for an even port, and MUST be rejected by the 629 server if an even port cannot be provided, or redirected to an 630 alternate server. However, it is also a hint from the client that 631 the client will request the next higher port with a separate Allocate 632 request. As such, it is a request for the server to allocate an even 633 port whose next higher port is also available, and furthermore, a 634 request for the server to not allocate that one higher port to any 635 other request except for one that asks for that port explicitly. The 636 server can honor this request for adjacency at its discretion. The 637 only constraint is that the allocated port has to be even. 639 Port alignment requests exist for compatibility with 640 implementations of RTP which pre-date RFC 3550. These 641 implementations use the port numbering conventions in (now 642 obsolete) RFC 1889. 644 If any of the requested or desired constraints cannot be met, whether 645 it be bandwidth, transport protocol, IP address or port, instead of 646 rejecting the request, the server can alternately redirect the client 647 to a different server that may be able to fulfill the request. This 648 is accomplished using the 300 error response and ALTERNATE-SERVER 649 attribute. If the server does not redirect and cannot service the 650 request because the server has reached capacity, it sends a 507 651 (Insufficient Capacity) response. The server can also reject the 652 request with a 486 (Allocation Quota Reached) if the user or client 653 is not authorized to request additional allocations. 655 The server SHOULD only allocate ports in the range 1024-65535. This 656 is one of several ways to prohibit relayed transport addresses from 657 being used to attempt to run standard services. These guidelines are 658 meant to be consistent with [10], since the relay is effectively a 659 NAT. 661 Once the port is allocated, the server associates it with the 662 internal 5-tuple and fills in that 5-tuple. The internal remote 663 transport address of the internal 5-tuple is set to the source 664 transport address of the Allocate Request. The internal local 665 transport address of the internal 5-tuple is set to the destination 666 transport address of the Allocate Request. For TCP, this amounts to 667 associating the TCP connection from the STUN relay client with the 668 allocated transport address. 670 If the Allocate request was authenticated using a shared secret 671 between the client and server, this credential MUST be associated 672 with the allocation. If the request was authenticated using a short 673 term password derived from a shared secret, that shared secret MUST 674 be associated with the allocation. This is used in all subsequent 675 requests and indications to ensure that only the same client can use 676 or modify the allocation it was given. 678 The allocation created by the Allocate request is also associated 679 with a transport address, called the active destination. This 680 transport address is used for forwarding data through the STUN relay 681 server, and is described in more detail later. It is initially set 682 to null when the allocation is created. In addition, the allocation 683 created by the server is associated with a set of permissions. Each 684 permission is a specific IP address identifying an external client. 685 Initially, this list is null. 687 If the LIFETIME attribute was present in the request, and the value 688 is larger than the maximum duration the server is willing to use for 689 the lifetime of the allocation, the server MAY lower it to that 690 maximum. However, the server MUST NOT increase the duration 691 requested in the LIFETIME attribute. If there was no LIFETIME 692 attribute, the server may choose a default duration at its 693 discretion. In either case, the resulting duration is added to the 694 current time, and a timer, called the allocation expiration timer, is 695 set to fire at or after that time. Section 10.3 discusses behavior 696 when the timer fires. Note that the LIFETIME attribute in the 697 request can be zero. This typically happens for subsequent 698 Allocations, and provides a mechanism to delete the allocation. It 699 will force the immediate deletion of the allocation. 701 Once the port has been obtained and the activity timer started for 702 the port binding, the server generates an Allocate Response using the 703 general procedures defined in [1]. The transport address allocated 704 to the client MUST be included in the RELAY-ADDRESS attribute in the 705 response. In addition, this response MUST contain the XOR-MAPPED- 706 ADDRESS attribute. This allows the client to determine its reflexive 707 transport address in addition to a relayed transport address, from 708 the same Allocate request. 710 The server MUST add a LIFETIME attribute to the Allocate Response. 711 This attribute contains the duration, in seconds, of the allocation 712 expiration timer associated with this allocation. 714 The server MUST add a BANDWIDTH attribute to the Allocate Response. 715 This MUST be equal to the attribute from the request, if one was 716 present. Otherwise, it indicates a per-binding cap that the server 717 is placing on the bandwidth usage on each binding. Such caps are 718 needed to prevent against denial-of-service attacks (See Section 12). 720 The server MUST add, as the final attribute of the request, a 721 MESSAGE-INTEGRITY attribute. The key used in the HMAC MUST be the 722 same as that used to validate the request. 724 6.1.2.2. Subsequent Requests 726 A subsequent Allocate request is one received whose source and 727 destination IP address and ports match the internal 5-tuple of an 728 existing allocation. The request is processed using the general 729 server procedures in [1] and is processed identically to 730 Section 6.1.2.1, with a few important exceptions. 732 First, the request MUST be authenticated using the same shared secret 733 as the one associated with the allocation, or be authenticated using 734 a short term password derived from that shared secret. If the 735 request was authenticated but not with such a matching credential, 736 the server MUST generate an Allocate Error Response with an 737 appropriate error response code. 739 Secondly, if the allocated transport address given out previously to 740 the client still matches the constraints in the request (in terms of 741 request ports, IP addresses and transport protocols), the same 742 allocation granted previously MUST be returned. However, if one of 743 the constraints is not met any longer, because the client changed 744 some aspect of the request, the server MUST free the previous 745 allocation and allocate a new request to the client. 747 Finally, a subsequent Allocate request will set a new allocation 748 expiration timer for the allocation, effectively canceling the 749 previous lifetime expiration timer. 751 6.2. Procedures for all other Requests and Indications 753 Other than initial Allocate Requests, all requests and indications 754 defined by the relay usage need to be sent in the context of a valid 755 allocation. The source and destination IP address and ports for 756 these STUN messages MUST match the internal 5-tuple of an existing 757 allocation. These processed using the general server procedures in 758 [1] with a few important additions. For requests, if there is no 759 matching allocation, the server MUST generate a 437 (No Binding) Send 760 Error Response. For indications, if there is no matching allocation, 761 the indication is silently discarded. 763 All requests and indications MUST be authenticated using the same 764 shared secret as the one associated with the allocation, or be 765 authenticated using a short term password derived from that shared 766 secret. If the request was authenticated but not with such a 767 matching credential, the server MUST generate an Allocate Error 768 Response with an appropriate error response code, such as a 431 769 (Integrity Failure) or 436 (Unknown User). 771 6.3. Set Active Destination Request 773 6.3.1. Client Behavior 775 The Set Active Destination request allows the client to create an 776 optimized relay function between the client and the server. When the 777 server receives packets from a particular preferred external peer, 778 the server will forward those packets towards the client without 779 encapsulating them in a Data Indication. Similarly, the client can 780 send non-STUN packets to the server without encapsulation, and these 781 are forwarded to the external peer. Sending and receiving data in 782 unencapsulated form is critical for efficiency purposes. One of the 783 primary use cases for the STUN relay usage is in support of Voice 784 over IP (VoIP), which uses very small UDP packets to begin with. The 785 extra overhead of an additional layer of encapsulation is considered 786 unacceptable. 788 The Set Active Destination request is used by the client to provide 789 the identity of this preferred external peer. The Set Active 790 Destination address MAY contain a REMOTE-ADDRESS attribute. This 791 attribute, when present, provides the address of the preferred 792 external peer to the server. When absent, it clears the value of the 793 preferred external peer. As a convenience, if the client sets the 794 REMOTE-ADDRESS attribute to a peer without a permission, the server 795 will add the corresponding permission. 797 The client MUST NOT send a Set Active Destination request with a 798 REMOTE-ADDRESS attribute over an unreliable link (ex: UDP) if an 799 active destination is already set for that allocation. If the client 800 wishes to set a new active destination, it MUST wait until 5 seconds 801 after a successful response is received to a Set Destination Request 802 removing the active destination. Failure to wait could cause the 803 client to receive and attribute late data forwarded by the STUN relay 804 server to the wrong peer. 806 Consider the case where the active destination is set, and the 807 server is relaying packets towards the client. The client knows 808 the IP address and port where the packets came from - the current 809 value of the active destination. The client issues a Set Active 810 Destination Request to change the active destination, and receives 811 a response. A moment later, a data packet is received, not 812 encapsulated in a STUN Data Indication. What is the source if 813 this packet? Is it the active destination that existed prior to 814 the Set Active Destination request, or the one after? If the 815 transport between the client and the STUN server is not reliable, 816 there is no way to know. 818 6.3.2. Server Behavior 820 The Set Active Destination Request is used by a client to set the 821 forwarding destination of all data that is not encapsulated in STUN 822 Send Indications. In addition, when a matching permission is 823 present, all data received from that external peer will be forwarded 824 to the STUN client without being encapsulated in a Data Indication. 826 If the Set Active Destination request does not contain a REMOTE- 827 ADDRESS attribute, the value of the active destination is cleared. 828 If the Set Active Destination request contains a REMOTE-ADDRESS 829 attribute, and the active destination is not set, the active 830 destination is set to that IP address and port. If an active 831 destination is already set, and the request was received over a 832 reliable transport, the active destination is changed to the new 833 value. If the active destination is already set and the request was 834 received over UDP, the Set Active Destination request is rejected 835 with a 439 Active Destination Already Set error response. This 836 prevents the race condition described in the previous section. 838 If the server sets the active destination and there is no permission 839 associated with the REMOTE-ADDRESS, the server adds the corresponding 840 permission. Note that if the permission associated with the active 841 destination becomes invalid, the server does not reset the active 842 destination. The client is expected to do this explicitly. 844 6.4. Connect Request 846 The Connect Request is used by a client when it has obtained an 847 allocated transport address that is TCP. The client can use the 848 Connect Request to ask the server to open a TCP connection to a 849 specified destination address included in the request. 851 6.4.1. Server Behavior 853 If the allocation is for a UDP port, the server MUST reject the 854 request with a 445 (Operation for TCP Only) response. If the request 855 does not contain a REMOTE-ADDRESS attribute, the server sends a 400 856 (Bad Request) Connect error response,. 858 If the request contains a REMOTE-ADDRESS attribute, the IP address 859 contained within it is added to the permissions for this allocation, 860 if it was not already present. This happens regardless of whether 861 the subsequent TCP connection attempt succeeds or not. 863 If a connection already exists for this address and port, the server 864 returns a 446 (Connection Already Exists) Connect error response. 865 Otherwise the server tries to establish the corresponding TCP 866 connection and returns a Connect Success Response. This just 867 indicates that the server added the permission and is attempting to 868 establish a TCP connection. The server does not wait for the 869 connection attempt to succeed or fail. The status of the connection 870 attempt is returned via the Connect Status Indication. 872 Note that the server needs to use the same source connection 873 address for all connections/permissions associated with an 874 allocation. For servers written using Berkeley sockets, the 875 SO_REUSEADDR flag is typically used to use the same local address 876 with multiple sockets. 878 6.5. Connection Status Indication 880 TODO: Expand this text. 882 When the STUN relay to peer leg is TCP, the STUN relay client needs 883 to be aware of the status of these TCP connections. The STUN relay 884 extension defines application states for a TCP connection as follows: 885 LISTEN, ESTABLISHED, CLOSED. Consequently, the STUN relay server 886 sends a Connection State Indication for a TCP permission whenever the 887 relay connection status changes for one of the client's permissions 888 except when the status changes due to a STUN relay client request 889 (ex: an explicit binding close or deallocation). 891 A STUN relay can only relay to a peer over TCP if the client 892 communicates with the server over TCP or TLS over TCP. Because of 893 this, the server can be assured that Connection Status Indications 894 are received reliably. 896 6.6. Send Indication 898 6.6.1. Client Behavior 900 The Send Indication is used to ask the relay to forward data to a 901 peer. It is typically used to send to a peer other than the active 902 destination. For TCP allocated transport addresses, the client needs 903 to wait for the peer to open a connection to the STUN relay server 904 before it can send data. Data sent with a Send request prior to the 905 opening of a TCP connection is discarded silently by the server. 907 The Send Indication MUST contain a REMOTE-ADDRESS attribute, which 908 contains the IP address and port that the data is being sent to. The 909 DATA attribute MAY be present, and contains the data that is to be 910 sent towards REMOTE-ADDRESS. If absent, the server will send an 911 empty UDP packet in the case of UDP. In the case of TCP, the server 912 will do nothing. 914 Since Send is an Indication, it generates no response. The client 915 must rely on application layer mechanisms to determine if the data 916 was received by the peer. 918 Note that Send Indications are not authenticated and do not 919 contain a MESSAGE-INTEGRITY attribute. Just like non-relayed data 920 sent over UDP or TCP, the authenticity and integrity of this data 921 can only be assured using security mechanisms at higher layers. 923 6.6.2. Server Behavior 925 A Send Indication is sent by a client after it has completed its 926 Allocate transaction, in order to create permissions in the server 927 and send data to an external client. 929 If a Send Indication contains no REMOTE-ADDRESS, the indication is 930 discarded. If there is no DATA attribute, and the corresponding 931 allocation is for TCP, the indication is discarded. 933 If the allocation is a UDP allocation, the server creates a UDP 934 packet whose payload equals that content. The server sets the source 935 IP address of the packet equal to the allocated transport address. 936 The destination transport address is set to the contents of the 937 REMOTE-ADDRESS attribute. If a permission does not exist for this 938 destination the server creates one for this allocation. The server 939 then sends the UDP packet. Note that any retransmissions of this 940 packet which might be needed are not handled by the server. It is 941 the responsibility of the client to generate another Send indication 942 if needed. 944 If the allocation is a TCP allocation, the server checks if it has an 945 existing TCP connection open from the allocated transport address to 946 the address in the REMOTE-ADDRESS attribute. If so, the server 947 extracts the content of the DATA attribute and sends it over the 948 matching TCP connection. If the server doesn't have an existing TCP 949 connection to the destination, it adds the REMOTE-ADDRESS to the 950 permission list and discards the data. 952 6.7. Data Indication 954 6.7.1. Client Behavior 956 Once a client has obtained an allocation and created permissions for 957 a particular external client, the server can begin to relay packets 958 from that external client towards the client. If the external client 959 is not the active destination, this data is relayed towards the 960 client in encapsulated form using the Data Indication. 962 The Data Indication contains two attributes - DATA and REMOTE- 963 ADDRESS. The REMOTE-ADDRESS attribute indicates the source transport 964 address that the request came from, and it will equal the external 965 remote transport address of the external peer. When processing this 966 data, a client MUST treat the data as if it came from this address, 967 rather than the stun server itself. The DATA attribute contains the 968 data from the UDP packet or TCP segment that was received. Note that 969 the STUN relay server will not retransmit this indication over UDP. 971 Note that Data Indications are not authenticated and do not 972 contain a MESSAGE-INTEGRITY attribute. Just like non-relayed data 973 sent over UDP or TCP, the authenticity and integrity of this data 974 can only be assured using security mechanisms at higher layers. 976 6.7.2. Server Behavior 978 A server MUST send data packets towards the client using a Data 979 Indication under the conditions described in Section 10.1. Data 980 Indications MUST contain a DATA attribute containing the data to 981 send, and MUST contain a REMOTE-ADDRESS attribute indicating where 982 the data came from. 984 7. New Attributes 986 The STUN relay usage defines the following new attributes: 988 0x000D: LIFETIME 989 0x0010: BANDWIDTH 990 0x0012: REMOTE-ADDRESS 991 0x0013: DATA 992 0x0016: RELAY-ADDRESS 993 0x0018: REQUESTED-PORT-PROPS 994 0x0019: REQUESTED-TRANSPORT 995 0x0022: REQUESTED-IP 996 0x0021: TIMER-VAL 997 0x0023: CONNECT_STAT 999 7.1. LIFETIME 1001 The lifetime attribute represents the duration for which the server 1002 will maintain an allocation in the absence of data traffic either 1003 from or to the client. It is a 32 bit value representing the number 1004 of seconds remaining until expiration. 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Lifetime | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 7.2. BANDWIDTH 1012 The bandwidth attribute represents the peak bandwidth, measured in 1013 kbits per second, that the client expects to use on the binding in 1014 each direction. 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Bandwidth | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 7.3. REMOTE-ADDRESS 1022 The REMOTE-ADDRESS specifies the address and port of the peer as seen 1023 from the STUN relay server. It is encoded in the same way as MAPPED- 1024 ADDRESS. 1026 7.4. DATA 1028 The DATA attribute is present in Send Indications and Data 1029 Indications. It contains raw payload data that is to be sent (in the 1030 case of a Send Request) or was received (in the case of a Data 1031 Indication). It is padded with zeros if its length is not divisible 1032 evenly by 4 octets 1034 7.5. RELAY-ADDRESS 1036 The RELAY-ADDRESS is present in Allocate responses. It specifies the 1037 address and port that the server allocated to the client. It is 1038 encoded in the same way as MAPPED-ADDRESS. 1040 7.6. REQUESTED-PORT-PROPS 1042 This attribute allows the client to request certain properties for 1043 the port that is allocated by the server. The attribute can be used 1044 with any transport protocol that has the notion of a 16 bit port 1045 space (including TCP and UDP). The attribute is 32 bits long. Its 1046 format is: 1048 0 1 2 3 1049 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 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Reserved = 0 | A | Specific Port Number | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 The two bits labeled A in the diagram above are for requested port 1055 alignment and have the following meaning: 1057 00 no specific port alignment 1058 01 odd port number 1059 10 even port number 1060 11 even port number; reserve next higher port 1062 If the Specific Port Number field is zero, this means that no 1063 specific port is requested. If a specific port number is requested 1064 the value will be in the two low order octets. All other bits in 1065 this attribute are reserved and MUST be set to zero. 1067 Even Port is a request to the server to allocate a port with even 1068 parity. The port filter is not used with this property. Odd Port is 1069 a request to the server to allocate a port with odd parity. The port 1070 filter is not used with this property. Even port, with a hold on the 1071 next higher port, is a request to the server to allocate an even 1072 port. Furthermore, the client indicates that it will want the next 1073 higher port as well. As such, the client requests that the server, 1074 if it can, not allocate the next higher port to anyone unless that 1075 port is explicitly requested, which the client will itself do. The 1076 port filter is not used with this property. Finally, the Specific 1077 Port property is a request for a specific port. The port that is 1078 requested is contained in the Port filter. 1080 7.7. REQUESTED-TRANSPORT 1082 This attribute is used by the client to request a specific transport 1083 protocol for the allocated transport address. It is a 32 bit 1084 unsigned integer. Its values are: 1086 0x0000 0000: UDP 1087 0x0000 0001: TCP 1089 If an Allocate request is sent over TCP and requests a UDP 1090 allocation, or an Allocate request is sent over TLS over TCP and 1091 requests a UDP or TCP allocation, the server will relay data between 1092 the two transports. 1094 Extensions to the relay usage can define additional transport 1095 protocols in an IETF-consensus RFC. 1097 7.8. REQUESTED-IP 1099 The REQUESTED-IP attribute is used by the client to request that a 1100 specific IP address be allocated to it. This attribute is needed 1101 since it is anticipated that STUN relays will be multi-homed so as to 1102 be able to allocate more than 64k transport addresses. As a 1103 consequence, a client needing a second transport address on the same 1104 interface as a previous one can make that request. 1106 The format of this attribute is identical to MAPPED-ADDRESS. 1107 However, the port component of the attribute is ignored by the 1108 server. If a client wishes to request a specific IP address and 1109 port, it uses both the REQUESTED-IP and REQUESTED-PORT-PROPS 1110 attributes. 1112 7.9. CONNECT_STAT 1114 This attribute us used by the server to convey the status of server- 1115 to-peer connections. It is a 32 bit unsigned integer. Its values 1116 are: 1118 0x0000 0000: LISTEN 1119 0x0000 0001: ESTABLISHED 1120 0x0000 0002: CLOSED 1122 8. New Error Response Codes 1124 The STUN relay usage defines the following new Error response codes: 1126 437 (No Binding): A request was received by the server that 1127 requires an allocation to be in place. However, there is none yet 1128 in place. 1130 439 (Active Destination Already Set): A Set Active Destination 1131 request was received by the server over UDP. However, the active 1132 destination is already set to another value. The client should 1133 reset the active destination, wait for 5 seconds and set the 1134 active destination to the new value. 1136 442 (Unsupported Transport Protocol): The Allocate request asked 1137 for a transport protocol to be allocated that is not supported by 1138 the server. 1140 443 (Invalid IP Address): The Allocate request asked for a 1141 transport address to be allocated from a specific IP address that 1142 is not valid on the server. 1144 444 (Invalid Port): The Allocate request asked for a port to be 1145 allocated that is not available on the server. 1147 445 (Operation for TCP Only): The client tried to send a request 1148 to perform a TCP-only operation on an allocation, and allocation 1149 is UDP. 1151 446 (Connection Already Exists): The client tried to open a 1152 connection to a peer, but a connection to that peer already 1153 exists. 1155 486 (Allocation Quota Reached): The user or client is not 1156 authorized to request additional allocations. 1158 507 (Insufficient Capacity): The server cannot allocate a new port 1159 for this client as it has exhausted its relay capacity. 1161 9. Client Procedures 1163 9.1. Receiving and Sending Unencapsulated Data 1165 Once the active destination has been set, a client will receive both 1166 STUN and non-STUN data on the socket on which the Allocate Request 1167 was sent. The encapsulation behavior depends on the transport 1168 protocol used between the STUN client and the STUN relay server. 1170 9.1.1. Datagram Protocols 1172 If the allocation was over UDP, datagrams which contain the STUN 1173 magic cookie are treated as STUN requests. All other data is non- 1174 STUN data, which MUST be processed as if it had a source IP address 1175 and port equal to the value of the active destination. 1177 If the client wants to send data to the peer which contains the magic 1178 cookie in the same location as a STUN request, it MUST send that data 1179 encapsulated in a Send Indication, even if the active destination is 1180 set. 1182 In addition, once the active destination has been set, the client can 1183 send data to the active destination by sending the data 1184 unencapsulated on that same socket. Unencapsulated data MUST NOT be 1185 sent if no active destination is set. Of course, even if the active 1186 destination is set, the client can send data to that destination at 1187 any time by using the Send Indication. 1189 9.1.2. Stream Transport Protocols 1191 If the allocation was over TCP or TLS over TCP, the client will 1192 receive data framed as described in Section 5. The client MUST treat 1193 data encapsulated as data with this framing as if it originated from 1194 the active destination. 1196 For the STUN relay usage, the client always sends data encapsulated 1197 using this framing scheme. It SHOULD frame data to the active 1198 destination as data or it MAY place the data inside a Send 1199 Indications and frame this as STUN traffic. 1201 10. Server Procedures 1203 Besides the processing of the request and indications described 1204 above, this specification defines rules for processing of data 1205 packets received by the STUN server. There are two cases - receipt 1206 of any packets on an allocated address, and receipt of non-STUN data 1207 on its internal local transport address. 1209 10.1. Receiving Data on Allocated Transport Addresses 1211 10.1.1. TCP Processing 1213 If a server receives a TCP connection request on an allocated TCP 1214 transport address, it checks the permissions associated with that 1215 allocation. If the source IP address of the TCP SYN packet matches 1216 one of the permissions, the TCP connection is accepted. Otherwise, 1217 it is rejected. When a TCP connection is accepted, the server sends 1218 the corresponding client a Connect Status Indication with the 1219 CONNECT_STAT attribute set to ESTABLISHED. No information is passed 1220 to the client if the server rejects the connection because there is 1221 no corresponding permission. 1223 If a server receives data on a TCP connection that terminates on the 1224 allocated TCP transport address, the server checks the value of the 1225 active destination. If it equals the source IP address and port of 1226 the data packet (in other words, if the active destination identifies 1227 the other side of the TCP connection), the data is taken from the TCP 1228 connection and sent towards the client in unencapsulated form. 1229 Otherwise, the data is sent towards the client in a Data Indication, 1230 also known as encapsulated form. In this form, the server MUST add a 1231 REMOTE-ADDRESS which corresponds to the external remote transport 1232 address of the TCP connection, and MUST add a DATA attribute 1233 containing the data received on the TCP connection. 1235 Note that, because data is forwarded blindly across TCP bindings, 1236 TLS will successfully operate over a STUN relay allocated TCP port 1237 if the linkage to the client is also TCP. 1239 10.1.2. UDP Processing 1241 If a server receives a UDP packet on an allocated UDP transport 1242 address, it checks the permissions associated with that allocation. 1243 If the source IP address of the UDP packet matches one of the 1244 permissions, the UDP packet is accepted. Otherwise, it is discarded. 1245 If the packet is accepted, it is forwarded to the client. It will be 1246 forwarded in either encapsulated or unencapsulated form. 1248 If the client to server communication is via UDP, the server looks 1249 for the existence of the STUN magic cookie in the data received from 1250 the peer. If the data contains the magic cookie, the server 1251 encapsulates the data in a Data Indication, sets the REMOTE_ADDRESS 1252 attribute, and forwards the indication to the client. If the magic 1253 cookie is not present, the server checks if the peer is the active 1254 destination. If so the data is forwarded unencapsulated, directly to 1255 the client. Otherwise the server encapsulates the data in a Data 1256 Indication, sets the REMOTE_ADDRESS and forwards to the client. 1258 If the client to server communication is via TCP or TLS, the server 1259 checks if the peer is the active destination. If so, the data from 1260 the peer is framed as Data and sent to the client over the client to 1261 server connection. Otherwise, the server encapsulates the data in a 1262 Data Indication, sets the REMOTE_ADDRESS attribute, frames the 1263 indication as STUN traffic, and sends the indication over the 1264 connection to the client. If the TCP connection generates an error 1265 (because, for example, the incoming UDP packet rate exceeds the 1266 throughput of the TCP connection), the data is discarded silently by 1267 the server. 1269 10.2. Receiving Data on Internal Local Transport Addresses 1271 If a server receives non-STUN UDP data from the client on its 1272 internal local transport address, and it is coming from an internal 1273 remote transport address associated with an existing allocation, it 1274 represents UDP data that the client wishes to forward. If the active 1275 destination is not set, the server MUST discard the packet. If the 1276 active destination is set, the server places the data from the client 1277 in a UDP payload, and sets the destination address and port to the 1278 active destination. The UDP packet is then sent with a source IP 1279 address and port equal to the allocated transport address. Note that 1280 the server will not retransmit the UDP datagram. 1282 If a server receives framed data on a TCP connection from a client, 1283 the server retrieves the allocation bound to that connection. If the 1284 active destination for the allocation is not set, the server MUST 1285 discard the data and close the connection. If the active destination 1286 is set, and the allocated transport protocol is TCP, the server 1287 forwards the data over the connection to the active destination. The 1288 data is then sent over that connection. If the connection is not 1289 established or if the transmission fails due to a TCP error, the data 1290 is discarded silently by the server. If the active destination is 1291 set, and the allocated transport protocol is UDP, the server places 1292 the data from the client in a UDP payload, and sets the destination 1293 address and port to the active destination. The UDP packet is then 1294 sent with a source IP address and port equal to the allocated 1295 transport address. Note that the server will not retransmit the UDP 1296 datagram. 1298 If a TCP connection from a client is closed, the associated 1299 allocation is destroyed. This involves terminating any TCP 1300 connections from the allocated transport address to external peer 1301 (applicable only when the allocated transport address was TCP), and 1302 then freeing the allocated transport address (and all associated 1303 state maintained by the server) for use by other clients. 1305 10.3. Lifetime Expiration 1307 When the allocation expiration timer for a binding fires, the server 1308 MUST destroy the allocation. This involves terminating any TCP 1309 connections from the allocated transport address to external peers 1310 (applicable only when the allocated transport address was TCP), and 1311 then freeing the allocated transport address (and all associated 1312 state maintained by the server) for use by other clients. A 1313 suggested value for the allocation expiration timer is 10 minutes. 1315 The server is also expected to run a permission inactivity timer for 1316 each permission associated with an Allocation. If no traffic from 1317 the client is received, the permission inactivity timer will 1318 eventually expire and the server MUST delete the permission. A 1319 suggested value for the permission inactivity timer is 60 seconds. 1321 11. Formal Definition of STUN Usage 1323 11.1. Applicability Statement 1325 STUN requires all usages to define the applicability of the usage 1326 [1]. This section contains that information for the relay usage. 1328 The relayed transport address obtained from the Allocate request has 1329 specific properties which limit its applicability. The transport 1330 address will only be useful for applications that require a client to 1331 place a transport address into a protocol message, with the 1332 expectation that the client will be able to receive packets from a 1333 small number of hosts (typically one). Data from the peer is only 1334 relayed to the client after the client sends packets towards the 1335 peer. Because of this limitation, relayed transport addresses 1336 obtained from an Allocate request are only useful when combined with 1337 rendezvous protocols of some sort, which allow the client to discover 1338 the addresses of the hosts it will be corresponding with. Examples 1339 of such protocols include the Session Initiation Protocol (SIP) [4]. 1341 This limitation is purposeful. Relayed transport addresses obtained 1342 from the Allocate request can not be used to run general purpose 1343 servers, such as a web or email server. This means that the relay 1344 usage can be safely permitted to pass through NATs and firewalls 1345 without fear of compromising the purpose of having them there in the 1346 first place. Indeed, a relayed transport address obtained from a 1347 STUN relay has many of the properties of a transport address obtained 1348 from a NAT whose filtering policies are address dependent, but whose 1349 mapping properties are endpoint independent [10], and thus "good" 1350 NATs. Indeed, to some degree, the relay turns a bad NAT into a good 1351 NAT by, quite ironically, adding another NAT function - the relay 1352 itself. 1354 11.2. Client Discovery of Server 1356 STUN requires all usages to define the mechanism by which a client 1357 discovers the server [1]. This section contains that information for 1358 the relay usage. 1360 The relay usage differs from the other usages defined in [1] in that 1361 it demands substantial resources from the STUN server. In addition, 1362 it seems likely that administrators might want to block connections 1363 from clients to the STUN server for relaying separately from 1364 connections for the purposes of binding discovery. As a consequence, 1365 the relay usage is expected to typically run on a separate port from 1366 other usages. The client discovers the address and port of the STUN 1367 server for the relay usage using the same DNS procedures defined in 1368 [1], but using an SRV service name of "stun-relay" instead of just 1369 "stun". 1371 For example, to find STUN relay servers in the example.com domain, 1372 the STUN relay client performs a lookup for '_stun- 1373 relay._udp.example.com', '_stun-relay._tcp.example.com', and '_stun- 1374 relay._tls.example.com' if the STUN client wants to communicate with 1375 the STUN relay server using UDP, TCP, or TLS over TCP, respectively. 1376 The client assumes that all permissable transport protocols are 1377 supported from the STUN relay server to the peer for the client to 1378 server protocol selected. 1380 11.3. Server Determination of Usage 1382 STUN requires all usages to define the mechanism by which the server 1383 determines the usage [1]. This section contains that information for 1384 the relay usage. 1386 The STUN server is designed so the relay usage can run on a separate 1387 source port from non-relay usages. Since the client looks up the 1388 port number for the relay usage separately, servers can be configured 1389 to rely on this property. The STUN server MAY accept both relay and 1390 non-relay usages on the same port number, in which case it uses 1391 framing hints and choice of STUN messages to detect the STUN usage in 1392 use by a specific client. 1394 The relay usage is defined by a specific set of requests and 1395 indications. As a consequence, the server knows that this usage is 1396 being used because those request and indications were used. Over 1397 UDP, once an active destination has been set, the server also needs 1398 to check the source address and port of a datagram to determine if 1399 that source tuple is allocated for the relay usage. For stream-based 1400 protocols, the server can recognize STUN relay traffic from other 1401 usages, since STUN relay traffic on these transports always uses the 1402 framing described in the next section (Section 5). 1404 12. Security Considerations 1406 TODO: Need to spend more time on this. 1408 STUN servers implementing this relay usage allocate bandwidth and 1409 port resources to clients, in contrast to the usages defined in [1]. 1410 Therefore, a STUN server providing the relay usage requires 1411 authentication and authorization of STUN requests. This 1412 authentication is provided by mechanisms defined in the STUN 1413 specification itself. In particular, digest authentication and the 1414 usage of short-term passwords, obtained through a digest exchange 1415 over TLS, are available. The usage of short-tem passwords ensures 1416 that the Allocate Requests, which often do not run over TLS, are not 1417 susceptible to offline dictionary attacks that can be used to guess 1418 the long lived shared secret between the client and the server. 1420 Because STUN servers implementing the relay usage allocate resources, 1421 they can be susceptible to denial-of-service attacks. All Allocate 1422 Requests are authenticated, so that an unknown attacker cannot launch 1423 an attack. An authenticated attacker can generate multiple Allocate 1424 Requests, however. To prevent a single malicious user from 1425 allocating all of the resources on the server, it is RECOMMENDED that 1426 a server implement a modest per user cap on the amount of bandwidth 1427 that can be allocated. Such a mechanism does not prevent a large 1428 number of malicious users from each requesting a small number of 1429 allocations. Attacks as these are possible using botnets, and are 1430 difficult to detect and prevent. Implementors of the STUN relay 1431 usage should keep up with best practices around detection of 1432 anomalous botnet attacks. 1434 A client will use the transport address learned from the RELAY- 1435 ADDRESS attribute of the Allocate Response to tell other users how to 1436 reach them. Therefore, a client needs to be certain that this 1437 address is valid, and will actually route to them. Such validation 1438 occurs through the message integrity checks provided in the Allocate 1439 response. They can guarantee the authenticity and integrity of the 1440 allocated addresses. Note that the STUN relay usage is not 1441 susceptible to the attacks described in Section 12.2.3, 12.2.4, 1442 12.2.5 or 12.2.6 of RFC 3489 [[TODO: Update references once 3489bis 1443 is more stable]]. These attacks are based on the fact that a STUN 1444 server mirrors the source IP address, which cannot be authenticated. 1445 STUN does not use the source address of the Allocate Request in 1446 providing the RELAY-ADDRESS, and therefore, those attacks do not 1447 apply. 1449 The relay usage cannot be used by clients for subverting firewall 1450 policies. The relay usage has fairly limited applicability, 1451 requiring a user to send a packet to a peer before being able to 1452 receive a packet from that peer. This applies to both TCP and UDP. 1453 Thus, it does not provide a general technique for externalizing TCP 1454 and UDP sockets. Rather, it has similar security properties to the 1455 placement of an address-restricted NAT in the network, allowing 1456 messaging in from a peer only if the internal client has sent a 1457 packet out towards the IP address of that peer. This limitation 1458 means that the relay usage cannot be used to run web servers, email 1459 servers, SIP servers, or other network servers that service a large 1460 number of clients. Rather, it facilitates rendezvous of NATted 1461 clients that use some other protocol, such as SIP, to communicate IP 1462 addresses and ports for communications. 1464 Confidentiality of the transport addresses learned through Allocate 1465 requests does not appear to be that important, and therefore, this 1466 capability is not provided. 1468 Relay servers are useful even for users not behind a NAT. They can 1469 provide a way for truly anonymous communications. A user can cause a 1470 call to have its media routed through a STUN server, so that the 1471 user's IP addresses are never revealed. 1473 TCP transport addresses allocated by Allocate requests will properly 1474 work with TLS and SSL. However, any relay addresses learned through 1475 an Allcoate will not operate properly with IPSec Authentication 1476 Header (AH) [6] in transport mode. IPSec ESP [7] and any tunnel-mode 1477 ESP or AH should still operate. 1479 13. IANA Considerations 1481 This specification defines several new STUN messages, STUN 1482 attributes, and STUN response codes. This section directs IANA to 1483 add these new protocol elements to the IANA registry of STUN protocol 1484 elements. 1486 13.1. New STUN Requests, Responses, and Indications 1488 Request/Response Transactions 1489 0x003 : Allocate 1490 0x004 : Set Active Destination 1491 0x005 : Connect 1493 Indications 1494 0x001 : Send 1495 0x002 : Data 1496 0x003 : Connect Status 1498 13.2. New STUN Attributes 1500 0x000D: LIFETIME 1501 0x0010: BANDWIDTH 1502 0x0012: REMOTE-ADDRESS 1503 0x0013: DATA 1504 0x0016: RELAY-ADDRESS 1505 0x0018: REQUESTED-PORT-PROPS 1506 0x0019: REQUESTED-TRANSPORT 1507 0x0022: REQUESTED-IP 1508 0x0021: TIMER-VAL 1509 0x0023: CONNECT_STAT 1511 13.3. New STUN response codes 1513 437 No Binding 1514 439 Active Destination Already Set 1515 441 -- Wrong User -- 1516 442 Unsupported Transport Protocol 1517 443 Invalid IP Address 1518 444 Invalid Port 1519 445 Operation for TCP Only 1520 446 Connection Already Exists 1521 447 -- 1522 486 Allocation Quota Reached 1523 507 Insufficient Capacity 1525 14. IAB Considerations 1527 The IAB has studied the problem of ``Unilateral Self Address 1528 Fixing'', which is the general process by which a client attempts to 1529 determine its address in another realm on the other side of a NAT 1530 through a collaborative protocol reflection mechanism RFC 3424 [8]. 1531 The STUN relay extension is an example of a protocol that performs 1532 this type of function. The IAB has mandated that any protocols 1533 developed for this purpose document a specific set of considerations. 1534 This section meets those requirements. 1536 14.1. Problem Definition 1538 >From RFC 3424 [8], any UNSAF proposal must provide: 1540 Precise definition of a specific, limited-scope problem that is to 1541 be solved with the UNSAF proposal. A short term fix should not be 1542 generalized to solve other problems; this is why "short term fixes 1543 usually aren't". 1545 The specific problem being solved by the STUN relay extension is for 1546 a client, which may be located behind a NAT of any type, to obtain an 1547 IP address and port on the public Internet, useful for applications 1548 that require a client to place a transport address into a protocol 1549 message, with the expectation that the client will be able to receive 1550 packets from a single host that will send to this address. Both UDP 1551 and TCP are addressed. It is also possible to send packets so that 1552 the recipient sees a source address equal to the allocated address. 1553 STUN relays, by design, does not allow a client to run a server (such 1554 as a web or SMTP server) using a STUN relay address. STUN relays are 1555 useful even when NAT is not present, to provide anonymity services. 1557 14.2. Exit Strategy 1559 From [8], any UNSAF proposal must provide: 1561 Description of an exit strategy/transition plan. The better short 1562 term fixes are the ones that will naturally see less and less use 1563 as the appropriate technology is deployed. 1565 It is expected that STUN relays will be useful indefinitely, to 1566 provide anonymity services. When used to facilitate NAT traversal, 1567 STUN relay does not itself provide an exit strategy. That is 1568 provided by the Interactive Connectivity Establishment (ICE) [9] 1569 mechanism. ICE allows two cooperating clients to interactively 1570 determine the best addresses to use when communicating. ICE uses 1571 STUN-allocated relay addresses as a last resort, only when no other 1572 means of connectivity exists. As a result, as NATs phase out, and as 1573 IPv6 is deployed, ICE will increasingly use other addresses (host 1574 local addresses). Therefore, clients will allocate STUN relay 1575 addresses, but not use them, and therefore, de-allocate them. 1576 Servers will see a decrease in usage. Once a provider sees that its 1577 STUN relay servers are not being used at all (that is, no media flows 1578 through them), they can simply remove them. ICE will operate without 1579 STUN-allocated relay addresses. 1581 14.3. Brittleness Introduced by STUN relays 1583 From [8], any UNSAF proposal must provide: 1585 Discussion of specific issues that may render systems more 1586 "brittle". For example, approaches that involve using data at 1587 multiple network layers create more dependencies, increase 1588 debugging challenges, and make it harder to transition. 1590 The STUN relay extension introduces brittleness in a few ways. 1591 First, it adds another server element to any system, which adds 1592 another point of failure. It requires clients to demultiplex STUN 1593 relay packets and data based on hunting for a MAGIC-COOKIE in the 1594 STUN messages. It is possible (with extremely small probabilities) 1595 that this cookie could appear within a data stream, resulting in mis- 1596 classification. That might introduce errors into the data stream 1597 (they would appear as lost packets), and also result in loss of a 1598 binding. STUN relay relies on any NAT bindings existing for the 1599 duration of the bindings held by the STUN relay server. Neither the 1600 client nor the STUN relay server have a way of reliably determining 1601 this lifetime (STUN can provide a means, but it is heuristic in 1602 nature and not reliable). Therefore, if there is no activity on an 1603 address learned from STUN for some period, the address might become 1604 useless spontaneously. 1606 STUN relays will result in potentially significant increases in 1607 packet latencies, and also increases in packet loss probabilities. 1608 That is because it introduces an intermediary on the path of a packet 1609 from point A to B, whose location is determined by application-layer 1610 processing, not underlying routing topologies. Therefore, a packet 1611 sent from one user on a LAN to another on the same LAN may do a trip 1612 around the world before arriving. When combined with ICE, some of 1613 the most problematic cases are avoided (such as this example) by 1614 avoiding the usage of STUN relay addresses. However, when used, this 1615 problem will exist. 1617 Note that STUN relay does not suffer from many of the points of 1618 brittleness introduced by the STUN binding or discovery usages. STUN 1619 relay will work with all existing NAT types known at the time of 1620 writing, and for the forseeable future. STUN relay does not 1621 introduce any topological constraints. STUN relay does not rely on 1622 any heuristics for NAT type classification. 1624 14.4. Requirements for a Long Term Solution 1626 >From [8]}, any UNSAF proposal must provide: 1628 Identify requirements for longer term, sound technical solutions 1629 -- contribute to the process of finding the right longer term 1630 solution. 1632 Our experience with STUN relay continues to validate our belief in 1633 the requirements outlined in Section 14.4 of STUN. 1635 14.5. Issues with Existing NAPT Boxes 1637 >From [8], any UNSAF proposal must provide: 1639 Discussion of the impact of the noted practical issues with 1640 existing, deployed NA[P]Ts and experience reports. 1642 A number of NAT boxes are now being deployed into the market which 1643 try and provide "generic" ALG functionality. These generic ALGs hunt 1644 for IP addresses, either in text or binary form within a packet, and 1645 rewrite them if they match a binding. This usage avoids that problem 1646 by using the XOR-MAPPED-ADDRESS attribute instead of the MAPPED- 1647 ADDRESS 1649 15. Example 1651 In this example, a client is behind a NAT. The client has a private 1652 address of 10.0.1.1. The STUN server is on the public side of the 1653 NAT, and is listening for STUN relay requests on 192.0.2.3:8776. The 1654 public side of the NAT has an IP address of 192.0.2.1. The client is 1655 attempting to send a SIP INVITE to a peer, and wishes to allocate an 1656 IP address and port for inclusion in the SDP of the INVITE. 1657 Normally, STUN relays would be used in conjunction with ICE when 1658 applied to SIP. For simplicities sake, STUN relay is showed without 1659 ICE. 1661 The client communicates with a SIP user agent on the public network. 1662 This user agent uses a 192.0.2.17:12734 for receipt of its RTP 1663 packets. 1665 Client NAT STUN Server Peer 1666 | | | | 1667 |(1) Allocate | | | 1668 |S=10.0.1.1:4334 | | | 1669 |D=192.0.2.3:8776 | | | 1670 |------------------>| | | 1671 | | | | 1672 | |(2) Allocate | | 1673 | |S=192.0.2.1:63346 | | 1674 | |D=192.0.2.3:8776 | | 1675 | |------------------>| | 1676 | | | | 1677 | |(3) Error | | 1678 | |S=192.0.2.3:8776 | | 1679 | |D=192.0.2.1:63346 | | 1680 | |<------------------| | 1681 | | | | 1682 |(4) Error | | | 1683 |S=192.0.2.3:8776 | | | 1684 |D=10.0.1.1:4334 | | | 1685 |<------------------| | | 1686 | | | | 1687 |(5) Allocate | | | 1688 |S=10.0.1.1:4334 | | | 1689 |D=192.0.2.3:8776 | | | 1690 |------------------>| | | 1691 | | | | 1692 | |(6) Allocate | | 1693 | |S=192.0.2.1:63346 | | 1694 | |D=192.0.2.3:8776 | | 1695 | |------------------>| | 1696 | | | | 1697 | |(7) Response | | 1698 | |RA=192.0.2.3:32766 | | 1699 | |MA=192.0.2.1:63346 | | 1700 | |S=192.0.2.3:8776 | | 1701 | |D=192.0.2.1:63346 | | 1702 | |<------------------| | 1703 |(8) Response | | | 1704 |RA=192.0.2.3:32766 | | | 1705 |MA=192.0.2.1:63346 | | | 1706 |S=192.0.2.3:8776 | | | 1707 |D=10.0.1.1:4334 | | | 1708 |<------------------| | | 1709 | | | | 1710 | | | | 1711 |(9) INVITE | | | 1712 |SDP=192.0.2.3:32766| | | 1713 |---------------------------------------------------------->| 1714 | | | | 1715 | | | | 1716 |(10) 200 OK | | | 1717 |SDP=192.0.2.17:12734 | | 1718 |<----------------------------------------------------------| 1719 | | | | 1720 | | | | 1721 | | | | 1722 |(11) ACK | | | 1723 |---------------------------------------------------------->| 1724 | | | | 1725 |(12) Send | | | 1726 |DATA=RTP | | | 1727 |DA=192.0.2.17:12734| | | 1728 |S=10.0.1.1:4334 | | | 1729 |D=192.0.2.3:8776 | | | 1730 |------------------>| | | 1731 | | | | 1732 | |(13) Send | | 1733 | |DATA=RTP | | 1734 | |DA=192.0.2.17:12734| | 1735 | |S=192.0.2.1:63346 | | 1736 | |D=192.0.2.3:8776 | | 1737 | |------------------>| | 1738 | | | | 1739 | | |(14) RTP | 1740 | | |S=192.0.2.3:32766 | 1741 | | |D=192.0.2.17:12734 | 1742 | | |------------------>| 1743 | | | | 1744 | | |Permission | 1745 | | |Created | 1746 | | |192.0.2.17 | 1747 | | | | 1748 | | |(15) RTP | 1749 | | |S=192.0.2.17:12734 | 1750 | | |D=192.0.2.3:32766 | 1751 | | |<------------------| 1752 | | | | 1753 | |(16) DataInd | | 1754 | |DATA=RTP | | 1755 | |RA=192.0.2.17:12734| | 1756 | |S=192.0.2.3:8776 | | 1757 | |D=192.0.2.1:63346 | | 1758 | |<------------------| | 1759 |(17) DataInd | | | 1760 |DATA=RTP | | | 1761 |RA=192.0.2.17:12734| | | 1762 |S=192.0.2.3:8776 | | | 1763 |D=10.0.1.1:4334 | | | 1764 |<------------------| | | 1765 | | | | 1766 |(18) SetAct | | | 1767 |DA=192.0.2.17:12734| | | 1768 |S=10.0.1.1:4334 | | | 1769 |D=192.0.2.3:8776 | | | 1770 |------------------>| | | 1771 | | | | 1772 | |(19) SetAct | | 1773 | |DA=192.0.2.17:12734| | 1774 | |S=192.0.2.1:63346 | | 1775 | |D=192.0.2.3:8776 | | 1776 | |------------------>| | 1777 | | | | 1778 | |(20) Response | | 1779 | |S=192.0.2.3:8776 | | 1780 | |D=192.0.2.1:63346 | | 1781 | |<------------------| | 1782 | | | | 1783 |(21) Response | | | 1784 |S=192.0.2.3:8776 | | | 1785 |D=10.0.1.1:4334 | | | 1786 |<------------------| | | 1787 | | | | 1788 | | | | 1789 | | | after 3s| 1790 | | | | 1791 | | | | 1792 | | |(22) RTP | 1793 | | |S=192.0.2.17:12734 | 1794 | | |D=192.0.2.3:32766 | 1795 | | |<------------------| 1796 | | | | 1797 | |(23) RTP | | 1798 | |S=192.0.2.3:8776 | | 1799 | |D=192.0.2.1:63346 | | 1800 | |<------------------| | 1801 | | | | 1802 |(24) RTP | | | 1803 |S=192.0.2.3:8776 | | | 1804 |D=10.0.1.1:4334 | | | 1805 |<------------------| | | 1806 | | | | 1807 | | | | 1809 Figure 14 1811 The call flow is shown in Figure 14. The client allocates a port 1812 from the local operating system on its private interface, obtaining 1813 4334. It then attempts to secure a port for RTP traffic. RTCP 1814 processing is not shown. The client sends an Allocate request (1) 1815 with a source address (denoted by S) of 10.0.1.1:4334 and a 1816 destination (denoted by D) of 192.0.2.3:8776. This passes through 1817 the NAT (2), which creates a mapping from the 192.0.2.1:63346 to the 1818 source IP address and port of the request, 10.0.1.1:4334. This 1819 request is received at the STUN server, which challenges it (3), 1820 requesting credentials. This response is passed to the client (4). 1821 The client retries the request, this time with credentials (5). This 1822 arrives at the server (6). The request is now authenticated. The 1823 server provides a UDP allocation, 192.0.2.3:32766, and places it into 1824 the RELAY-ADDRESS (denoted by RA) in the response (7). It also 1825 reflects the source IP address and port of the request into the 1826 MAPPED-ADDRESS (denoted by MA) in the response. This passes through 1827 the NAT to the client (8). The client now proceeds to perform a 1828 basic SIP call setup. In message 9, it includes the relay address 1829 into the SDP of its INVITE. The called party responds with a 200 OK, 1830 and includes its IP address - 192.0.2.17:12734. The exchange 1831 completes with an ACK (11). 1833 Next, user A sends an RTP packet. Since the active destination has 1834 not been set, the client decides to use the Send indication. It does 1835 so, including the RTP packet as the contents of the DATA attribute. 1836 The REMOTE-ADDRESS attribute (denoted by DA) is set to 192.0.2.17: 1837 12734, learned from the 200 OK. This is sent through the NAT 1838 (message 12) and arrives at the STUN server (message 13). The server 1839 extracts the data contents, and sends the packet towards REMOTE- 1840 ADDRESS (message 14). Note how the source address and port in this 1841 packet is 192.0.2.3:32766, the allocated transport address given to 1842 the client. The act of sending the packet with Send causes the STUN 1843 server to install a permission for 192.0.2.17. 1845 Indeed, the called party now sends an RTP packet toward the client 1846 (message 15). This arrives at the STUN server. Since a permission 1847 has been set for the IP address in the source of this packet, it is 1848 accepted. As no active destination is set, the STUN server 1849 encapsulates the contents of the packet in a Data Indication (message 1850 16), and sends it towards the client. The REMOTE-ADDRESS attribute 1851 (denoted by RA) indicates the source of the packet - 192.0.2.17: 1852 12734. This is forwarded through the NAT to the client (message 17). 1854 The client decides to optimize the path for packets to and from 1855 192.0.2.17:12734. So, it issues a Set Active Destination request 1856 (message 18) with a REMOTE-ADDRESS of 192.0.2.17:12734. This passes 1857 through the NAT and arrives at the STUN server (message 19). This 1858 generates a successful response (message 20) which is passed to the 1859 client (message 21). At this point, the server and client are in the 1860 transitioning state. A little over 3 seconds later (by default), the 1861 state machines transition back to "Set". Until this point, packets 1862 from the called party would have been relayed back to the client in 1863 Data Indications. Now, the next RTP packet shows up at the STUN 1864 server (message 22). Since the source IP address and port match the 1865 active destination, the RTP packet is relayed towards the client 1866 without encapsulation (message 23 and 24). 1868 16. Acknowledgements 1870 The authors would like to thank Marc Petit-Huguenin for his comments 1871 and suggestions. 1873 17. References 1875 17.1. Normative References 1877 [1] Rosenberg, J., "Simple Traversal Underneath Network Address 1878 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 1879 (work in progress), October 2006. 1881 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1882 Levels", BCP 14, RFC 2119, March 1997. 1884 17.2. Informative References 1886 [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1887 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1888 RFC 3550, July 2003. 1890 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1891 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1892 Session Initiation Protocol", RFC 3261, June 2002. 1894 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1895 Session Description Protocol (SDP)", RFC 3264, June 2002. 1897 [6] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 1899 [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1900 December 2005. 1902 [8] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 1903 Address Fixing (UNSAF) Across Network Address Translation", 1904 RFC 3424, November 2002. 1906 [9] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1907 Methodology for Network Address Translator (NAT) Traversal for 1908 Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in 1909 progress), January 2007. 1911 [10] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 1912 Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), 1913 October 2006. 1915 Authors' Addresses 1917 Jonathan Rosenberg 1918 Cisco Systems 1919 600 Lanidex Plaza 1920 Parsippany, NJ 07054 1921 US 1923 Phone: +1 973 952-5000 1924 Email: jdrosen@cisco.com 1925 URI: http://www.jdrosen.net 1926 Rohan Mahy 1927 Plantronics 1929 Email: rohan@ekabal.com 1931 Christian Huitema 1932 Microsoft 1933 One Microsoft Way 1934 Redmond, WA 98052-6399 1935 US 1937 Email: huitema@microsoft.com 1939 Full Copyright Statement 1941 Copyright (C) The IETF Trust (2007). 1943 This document is subject to the rights, licenses and restrictions 1944 contained in BCP 78, and except as set forth therein, the authors 1945 retain all their rights. 1947 This document and the information contained herein are provided on an 1948 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1949 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1950 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1951 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1952 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1953 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1955 Intellectual Property 1957 The IETF takes no position regarding the validity or scope of any 1958 Intellectual Property Rights or other rights that might be claimed to 1959 pertain to the implementation or use of the technology described in 1960 this document or the extent to which any license under such rights 1961 might or might not be available; nor does it represent that it has 1962 made any independent effort to identify any such rights. Information 1963 on the procedures with respect to rights in RFC documents can be 1964 found in BCP 78 and BCP 79. 1966 Copies of IPR disclosures made to the IETF Secretariat and any 1967 assurances of licenses to be made available, or the result of an 1968 attempt made to obtain a general license or permission for the use of 1969 such proprietary rights by implementers or users of this 1970 specification can be obtained from the IETF on-line IPR repository at 1971 http://www.ietf.org/ipr. 1973 The IETF invites any interested party to bring to its attention any 1974 copyrights, patents or patent applications, or other proprietary 1975 rights that may cover technology that may be required to implement 1976 this standard. Please address the information to the IETF at 1977 ietf-ipr@ietf.org. 1979 Acknowledgment 1981 Funding for the RFC Editor function is provided by the IETF 1982 Administrative Support Activity (IASA).