idnits 2.17.1 draft-ietf-behave-turn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2202. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2208. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1214 has weird spacing: '...ed with an ex...' == Line 1670 has weird spacing: '...freeing the a...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6645 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 2112, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2116, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2133, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2136, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2139, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-03 ** Obsolete normative reference: RFC 2617 (ref. '4') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '8') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '9') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '11') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '12') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-08 == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-udp-07 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: August 5, 2006 R. Mahy 5 Plantronics 6 C. Huitema 7 Microsoft 8 February 2006 10 Obtaining Relay Addresses from Simple Traversal of UDP Through NAT 11 (STUN) 12 draft-ietf-behave-turn-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 5, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This specification defines a usage of the Simple Traversal of UDP 46 Through NAT (STUN) Protocol for asking the STUN server to relay 47 packets towards a client. This usage is useful for elements behind 48 NATs whose mapping behavior is address and port dependent. The 49 extension purposefully restricts the ways in which the relayed 50 address can be used. In particular, it prevents users from running 51 general purpose servers from ports obtained from the STUN server. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 59 4.1 Normal Allocations . . . . . . . . . . . . . . . . . . . . 5 60 4.2 Doors . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.3 Transports . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.4 Tuple Terminology . . . . . . . . . . . . . . . . . . . . 8 63 5. Applicability Statement . . . . . . . . . . . . . . . . . . 9 64 6. Client Discovery of Server . . . . . . . . . . . . . . . . . 10 65 7. Server Determination of Usage . . . . . . . . . . . . . . . 11 66 8. New Framing Mechanism for Stream-Oriented Transports . . . . 11 67 9. New Requests and Indications . . . . . . . . . . . . . . . . 11 68 9.1 Allocate Request . . . . . . . . . . . . . . . . . . . . . 12 69 9.1.1 Server Behavior . . . . . . . . . . . . . . . . . . . 12 70 9.1.2 Client Behavior . . . . . . . . . . . . . . . . . . . 17 71 9.2 Set Active Destination Request . . . . . . . . . . . . . . 19 72 9.2.1 Server Behavior . . . . . . . . . . . . . . . . . . . 19 73 9.2.2 Client Behavior . . . . . . . . . . . . . . . . . . . 22 74 9.3 Open Binding Request . . . . . . . . . . . . . . . . . . . 25 75 9.3.1 Server Behavior . . . . . . . . . . . . . . . . . . . 26 76 9.3.2 Client Behavior . . . . . . . . . . . . . . . . . . . 26 77 9.4 Close Binding Request . . . . . . . . . . . . . . . . . . 26 78 9.4.1 Server Behavior . . . . . . . . . . . . . . . . . . . 26 79 9.4.2 Client Behavior . . . . . . . . . . . . . . . . . . . 27 80 9.5 Connection Status Indication . . . . . . . . . . . . . . . 27 81 9.6 Send Indication . . . . . . . . . . . . . . . . . . . . . 27 82 9.6.1 Server Behavior . . . . . . . . . . . . . . . . . . . 27 83 9.6.2 Client Behavior . . . . . . . . . . . . . . . . . . . 28 84 9.7 Data Indication . . . . . . . . . . . . . . . . . . . . . 29 85 9.7.1 Server Behavior . . . . . . . . . . . . . . . . . . . 29 86 9.7.2 Client Behavior . . . . . . . . . . . . . . . . . . . 29 87 10. New Attributes . . . . . . . . . . . . . . . . . . . . . . . 29 88 10.1 LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 30 89 10.2 BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . 30 90 10.3 REMOTE-ADDRESS . . . . . . . . . . . . . . . . . . . . . 30 91 10.4 DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 10.5 RELAY-ADDRESS . . . . . . . . . . . . . . . . . . . . . 31 93 10.6 REQUESTED-PORT-PROPS . . . . . . . . . . . . . . . . . . 31 94 10.7 REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 32 95 10.8 REQUESTED-IP . . . . . . . . . . . . . . . . . . . . . . 32 96 10.9 TIMER-VAL . . . . . . . . . . . . . . . . . . . . . . . 32 98 11. New Error Response Codes . . . . . . . . . . . . . . . . . . 33 99 12. Client Procedures . . . . . . . . . . . . . . . . . . . . . 34 100 12.1 Receiving and Sending Unencapsulated Data . . . . . . . 34 101 12.2 Datagram Protocols . . . . . . . . . . . . . . . . . . . 34 102 12.3 Stream Transport Protocols . . . . . . . . . . . . . . . 34 103 13. Server Procedures . . . . . . . . . . . . . . . . . . . . . 34 104 13.1 Receiving Data on Allocated Transport Addresses . . . . 35 105 13.1.1 TCP Processing . . . . . . . . . . . . . . . . . . . 35 106 13.1.2 UDP Processing . . . . . . . . . . . . . . . . . . . 35 107 13.2 Receiving Data on Internal Local Transport Addresses . . 36 108 13.3 Lifetime Expiration . . . . . . . . . . . . . . . . . . 37 109 14. Security Considerations . . . . . . . . . . . . . . . . . . 37 110 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 111 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 39 112 16.1 Problem Definition . . . . . . . . . . . . . . . . . . . 39 113 16.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . 40 114 16.3 Brittleness Introduced by TURN . . . . . . . . . . . . . 40 115 16.4 Requirements for a Long Term Solution . . . . . . . . . 41 116 16.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . 41 117 17. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 42 118 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 119 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 120 19.1 Normative References . . . . . . . . . . . . . . . . . . 46 121 19.2 Informative References . . . . . . . . . . . . . . . . . 47 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48 123 Intellectual Property and Copyright Statements . . . . . . . 49 125 1. Introduction 127 The Simple Traversal of UDP Through NAT (STUN) [1] provides a suite 128 of tools for facilitating the traversal of NAT. Specifically, it 129 defines the Binding Request, which is used by a client to determine 130 its reflexive transport address towards the STUN server. The 131 reflexive transport address can be used by the client for receiving 132 packets from peers, but only when the client is behind "good" NATs. 133 In particular, if a client is behind a NAT whose mapping behavior 134 [15] is address or address and port dependent (sometimes called "bad" 135 NATs), the reflexive transport address will not be usable for 136 communicating with a peer. 138 The only way to obtain a transport address that can be used for 139 corresponding with a peer through such a NAT is to make use of a 140 relay. The relay sits on the public side of the NAT, and allocates 141 transport addresses to clients reaching it from behind the private 142 side of the NAT. These allocated addresses are from interfaces on 143 the relay. When the relay receives a packet on one of these 144 allocated addresses, the relay forwards it towards the client. 146 This specification defines a usage of STUN, called the relay usage, 147 that allows a client to request an address on the STUN server itself, 148 so that the STUN server acts as a relay. To accomplish that, this 149 usage defines a handful of new STUN requests and indications. The 150 Allocate request is the most fundamental component of this usage. It 151 is used to provide the client with a transport address that is 152 relayed through the STUN server. A transport address which relays 153 through an intermediary is called a relayed transport address. 155 Though a relayed address is highly likely to work when corresponding 156 with a peer, it comes at high cost to the provider of the relay 157 service. As a consequence, relayed transport addresses should only 158 be used as a last resort. Protocols using relayed transport 159 addresses should make use of mechanisms to dynamically determine 160 whether such an address is actually needed. One such mechanism, 161 defined for multimedia session establishment protocols based on the 162 offer/answer protocol [7] is Interactive Connectivity Establishment 163 (ICE) [14]. 165 The mechanism defined here was previously a standalone protocol 166 called Traversal Using Relay NAT (TURN), and is now defined as a 167 usage of STUN. 169 2. Terminology 171 In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, 172 SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to 173 be interpreted as described in RFC 2119 [2] and indicate requirement 174 levels for compliant TURN implementations. 176 3. Definitions 178 Relayed Transport Address: A transport address that terminates on a 179 server, and is forwarded towards the client. The STUN Allocate 180 Request can be used to obtain a relayed transport address, for 181 example. 183 STUN relay client: A STUN client that implements this specification. 184 It obtains a relayed transport address that it provides to a small 185 number of peers (usually one). 187 STUN relay server: A STUN server that implements this specification. 188 It relays data between a STUN relay client and its peer. 190 5-tuple: A combination of the source IP address and port, destination 191 IP address and port, and transport protocol (UDP, TCP, or TLS over 192 TCP). It uniquely identifies a TCP connection, TLS channel, or 193 bi-directional flow of UDP datagrams. 195 4. Overview of Operation 197 In a typical configuration, a STUN relay client is connected to a 198 private network and through one or more NATs to the public Internet. 199 On the public Internet is a STUN relay server. The STUN Relay usage 200 defines several new messages and a new framing mechanism that add the 201 ability for a STUN server to act as a packet relay. The text in this 202 section explains the typical usage of this relay extension. 204 4.1 Normal Allocations 206 The client sends an Allocate request to the server, which the server 207 authenticates. The server generates an Allocate response with the 208 allocated address port and and target transport. 210 A successful Allocate Request just reserves an address on the STUN 211 relay server. Except for allocations with "doors" (described later 212 in this section), data does not flow through an allocated port until 213 the STUN relay client asks the STUN relay server to open a binding, 214 either by sending data to the far end with a Send Indication, or by 215 explicitly issuing an OpenBinding Request. This insures that a 216 client can't use a STUN relay server to run a traditional server and 217 partially protects the client from DoS attacks. 219 Once a binding is open, the client can then receive data flowing back 220 from its peer. Initially this data is wrapped in a STUN Data 221 Indication. Since multiple bindings can be open simultaneously, the 222 Data Indication contains the Remote Address attribute so the STUN 223 relay client knows which peer sent the data. The client can send 224 data to any of its peers with the Send Indication. 226 Once the client wants to primarily receive from one peer, it can send 227 a SetDestination request. All subsequent data received from the 228 active peer is forwarded directly to the client and vice versa, 229 except that it is wrapped or framed according to the protocol used 230 between the STUN relay client and STUN relay server. 232 When the STUN relay client to server protocol is a datagram protocol 233 (UDP), any datagram received from the active peer that has the STUN 234 magic cookie is wrapped in a Data Indication. Likewise any datagram 235 sent by the client that has the STUN magic cookie and is intended for 236 the active peer is wrapped in a Send Indication. This wrapping 237 prevents the STUN relay server from inappropriately interpreting end- 238 to-end data. 240 Over stream-based transports (TCP and TLS over TLS), once there is an 241 active destination set, the STUN relay client and server need to use 242 some additional framing so that end-to-end data is distinguishable 243 from STUN control messages. This additional framing just has a type 244 and a length field. The value of the type field was chosen so it is 245 always distinguishable from an unframed STUN request or response. 247 The SetDestination Request does not close other bindings. Data to 248 and from other peers is still wrapped in Send and Data indications 249 respectively. If the client does not want to receive data from a 250 peer, it can also explicitly squelch data from a specific peer by 251 sending a CloseBinding request. A CloseBinding request leaves the 252 port allocated, so it can be reused. A CloseBinding request which 253 deletes the active destination, also unsets the active destination. 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, pairs of sequential 259 port numbers. Allocations can also request the "door" property. 261 4.2 Doors 263 Sometimes the client does not have a valid address for its peer to 264 provide to a STUN relay server to open a binding. This is often the 265 case when the client and the peer want to establish a TCP connection, 266 but both are behind a NAT or firewall and they cannot perform TCP 267 simultaneous open. (This is also the case for example if the peer is 268 behind an address or address and port dependent NAT.) To address 269 this shortcoming, the client can ask the STUN relay server to 270 Allocate an address with the "door" property, which accepts data only 271 from the first node to send the allocated address a UDP datagram or a 272 TCP SYN (depending on the allocated transport). Once a node has sent 273 to the allocated address, the STUN relay server opens the appropriate 274 binding, and the door "closes". Data can flow over the established 275 bindings, but subsequent new datagrams or connections do not cause 276 the server to create any more new bindings. Clients are not allowed 277 to request both a specific port number and the door property for a 278 single allocation, so that clients cannot run a traditional server 279 using a STUN relay. 281 Like any other open binding, data from the peer (including an initial 282 datagram which forms a new binding) is wrapped in a Data Indication 283 until the client sends a SetDestination request. 285 4.3 Transports 287 STUN relay clients can communicate with a STUN relay server using 288 UDP, TCP, or TLS over TCP. A STUN relay can even relay traffic 289 between two different transports with certain restrictions. A STUN 290 relay can never relay from an unreliable transport (client to server) 291 to a reliable transport to the peer. Note that a STUN relay server 292 never has a TLS relationship with a client's peer, since the STUN 293 relay server does not interpret data above the TCP layer. When 294 relaying data sent from a stream-based protocol to a UDP peer, the 295 STUN relay server emits datagrams which the same length as the length 296 field in the STUN TCP framing or the length field in Send Indication. 297 Likewise, when a UDP datagram is relayed from a peer over a stream- 298 based transport, the length of the datagram is the length of the TCP 299 framing or Data Indication. 301 +----------------------+--------------------+ 302 | client to STUN relay | STUN relay to peer | 303 +----------------------+--------------------+ 304 | UDP | UDP | 305 | TCP | TCP | 306 | TCP | UDP | 307 | TLS | TCP | 308 | TLS | UDP | 309 +----------------------+--------------------+ 311 For STUN relay clients, using TLS over TCP provides two benefits. 312 When using TLS, the client can be assured that the address of the 313 client's peers are not visible to an attacker except by traffic 314 analysis downstream of the STUN relay server. Second, the client may 315 be able communicate with STUN relay servers using TLS that it would 316 not be able to communicate with using TCP or UDP due to the 317 configuration of a firewall between the STUN relay client and its 318 server. TLS between the client and STUN relay server in this case 319 just facilitates traversal. 321 When the STUN relay to peer leg is TCP, the STUN relay client needs 322 to be aware of the status of these TCP connections. The STUN relay 323 extension defines application states for a TCP connection as follows: 324 LISTEN, ESTABLISHED, CLOSED. Consequently, the STUN relay server 325 sends a ConnectionState Indication for a binding whenever the relay 326 connection status changes for one of the client's bindings except 327 when the status changes due to a STUN relay client request (ex: an 328 explicit binding close or deallocation). 330 4.4 Tuple Terminology 332 To relay data to and from the correct location, the STUN relay server 333 maintains a binding between an internal address (called a 5-tuple) 334 and one or more external 5-tuples, as shown in Figure 1. The 335 internal 5-tuple identifies the path between the STUN relay client 336 and the STUN relay server. It consists of the protocol (UDP, TCP, or 337 TLS over TCP), the internal local IP address and port number and the 338 source IP address and port number of the STUN client, as seen by the 339 relay server. For example, for UDP, the internal 5-tuple is the 340 combination of the IP address and port from which the STUN client 341 sent its Allocate Request, with the IP address and port to which that 342 Allocate Request was sent. 344 The external local transport address is the IP address and port 345 allocated to the STUN relay client (the allocated transport address). 346 The external 5-tuple is the combination of the external local 347 transport address and the IP address and port of an external client 348 that the STUN client is communicating with through the STUN server. 349 Initially, there aren't any external 5-tuples, since the STUN client 350 hasn't communicated with any other hosts yet. As packets are 351 received on or sent from the allocated transport address, external 352 5-tuples are created. 354 While the terminology used in this document refers to 5-tuples, 355 the STUN relay server can store whatever identifier it likes that 356 yields identical results. Specifically, many implementations may 357 use a file-descriptor in place of a 5-tuple to represent a TCP 358 connection. 360 +---------+ 361 | | 362 | External| 363 / | Client | 364 // | | 365 / | | 366 // +---------+ 367 / 368 // 369 +-+ / 370 | | / 371 | | // 372 +---------+ | | +---------+ / +---------+ 373 | | |N| | | // | | 374 | STUN | | | | |/ | External| 375 | Client |----|A|----------| STUN |------------------| Client | 376 | | | |^ ^| Server |^ ^| | 377 | | |T|| || || || | 378 +---------+ | || |+---------+| |+---------+ 379 ^ | || | | | 380 | | || | | | 381 | +-+| | | | 382 | | | | | 383 | 384 Internal Internal External External 385 Client Remote Local Local Remote 386 Performing Transport Transport Transport Transport 387 Allocations Address Address Address Address 389 | | | | 390 +-----+----+ +--------+-------+ 391 | | 392 | | 394 Internal External 395 5-Tuple 5-tuple 397 Figure 1 399 5. Applicability Statement 401 STUN requires all usages to define the applicability of the usage 402 [1]. This section contains that information for the relay usage. 404 The relayed transport address obtained from the Allocate request has 405 specific properties which limit its applicability. The transport 406 address will only be useful for applications that require a client to 407 place a transport address into a protocol message, with the 408 expectation that the client will be able to receive packets from a 409 small number of hosts (typically one). Data from the peer is only 410 relayed to the client after the client sends packets towards the 411 peer, or for the first peer to send to an open door. Furthermore, a 412 client can only request an allocation of a door once, since 413 requesting a specific port number and a door simultaneously is 414 invalid. Because of these limitations, relayed transport addresses 415 obtained from an Allocate request are only useful when combined with 416 rendezvous protocols of some sort, which allow the client to discover 417 the addresses of the hosts it will be corresponding with. Examples 418 of such protocols include the Session Initiation Protocol (SIP) [6]. 420 This limitation is purposeful. Relayed transport addresses obtained 421 from the Allocate request can not be used to run general purpose 422 servers, such as a web or email server. This means that the relay 423 usage can be safely permitted to pass through NATs and firewalls 424 without fear of compromising the purpose of having them there in the 425 first place. Indeed, a relayed transport address obtained from TURN 426 has many of the properties of a transport address obtained from a NAT 427 whose filtering policies are address dependent, but whose mapping 428 properties are endpoint independent [15], and thus "good" NATs. 429 Indeed, to some degree, the relay turns a bad NAT into a good NAT by, 430 quite ironically, adding another NAT function - the relay itself. 432 6. Client Discovery of Server 434 STUN requires all usages to define the mechanism by which a client 435 discovers the server [1]. This section contains that information for 436 the relay usage. 438 The relay usage differs from the other usages defined in [1] in that 439 it demands substantial resources from the STUN server. In addition, 440 it seems likely that administrators might want to block connections 441 from clients to the STUN server for relaying separated from 442 connections for the purposes of binding discovery. As a consequence, 443 the relay usage is defined to run on a separate port from other 444 usages. The client discovers the address and port of the STUN server 445 for the relay usage using the same DNS procedures defined in [1], but 446 using an SRV service name of "stun-relay" instead of just "stun". 448 For example, to find STUN relay servers in the example.com domain, 449 the STUN relay client performs a lookup for '_stun- 450 relay._udp.example.com', '_stun-relay._tcp.example.com', and '_stun- 451 relay-tls._tcp.example.com' if the STUN client wants to communicate 452 with the STUN relay server using UDP, TCP, or TLS over TCP, 453 respectively. The client assumes that all permissable transport 454 protocols are supported from the STUN relay server to the peer for 455 the client to server protocol selected. 457 7. Server Determination of Usage 459 STUN requires all usages to define the mechanism by which the server 460 determines the usage [1]. This section contains that information for 461 the relay usage. 463 The relay usage is defined by a specific set of requests and 464 indications. As a consequence, the server knows that this usage in 465 being used because those request and indications were used. 467 8. New Framing Mechanism for Stream-Oriented Transports 469 Over stream-based transports, the STUN relay client and server need 470 to use some additional framing so that end-to-end data is 471 distinguishable from STUN control messages, and so that the relay 472 server can perform conversion from streams to datagrams and vice 473 versa. This additional framing has a one octet type, one reserved 474 octet, and a 2 octet length field. The first octet of this framing 475 is 0x02 to indicate STUN messages or 0x03 to indicate end-to-end data 476 to or from the active destination. Note that the first octet is 477 always distinguishable from an unframed STUN request or response 478 (which is always 0x00 or 0x01). The second octet is reserved and 479 MUST be set to zero. The length field counts the number of octets 480 immediately after the length field itself. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Type | Reserved = 0 | Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 This framing is only used after an active destination is set. Use of 489 this framing mechanism is discussed in Section 12 and Section 13. 491 9. New Requests and Indications 493 This usage defines four new requests (along with their success and 494 error responses) and three indications. It also defines processing 495 rules for the STUN server and client on receipt of non-STUN messages. 496 See Section 12 and Section 13 498 The new messages are: 500 0x0003 : Allocate Request 501 0x0103 : Allocate Response 502 0x0113 : Allocate Error Response 503 0x0004 : Send Indication 504 0x0115 : Data Indication 505 0x0006 : Set Active Destination Request 506 0x0106 : Set Active Destination Response 507 0x0116 : Set Active Destination Error Response 508 0x0117 : Connect Status Indication 509 0x0008 : Open Binding Request 510 0x0108 : Open Binding Response 511 0x0118 : Open Binding Error Response 512 0x0009 : Close Binding Request 513 0x0109 : Close Binding Response 514 0x0119 : Close Binding Error Response 516 In addition to STUN Requests and Responses, STUN relay clients and 517 servers send and receive non-STUN packets on the same ports used for 518 STUN messages. How these entities distinguish STUN and non-STUN 519 traffic is discussed in Section 12 and Section 13. 521 9.1 Allocate Request 523 9.1.1 Server Behavior 525 The server first processes the request according to the general 526 request processing rules in [1]. This includes performing 527 authentication and checking for mandatory unknown attributes. Due to 528 the fact that the STUN server is allocating resources for processing 529 the request, Allocate requests MUST be authenticated, and 530 furthermore, MUST be authenticated using either a shared secret known 531 between the client and server, or a short term password derived from 532 it. 534 Note that Allocate requests, like all other STUN requests, can be 535 sent to the STUN server over UDP, TCP, or TCP/TLS. 537 The behavior of the server when receiving an Allocate Request depends 538 on whether the request is an initial one, or a subsequent one. An 539 initial request is one whose source and destination transport address 540 do not match the internal remote and local transport addresses of an 541 existing internal 5-tuple. A subsequent request is one whose source 542 and destination transport address matches the internal remote and 543 local transport address of an existing internal 5-tuple. 545 9.1.1.1 Initial Requests 547 [[TODO: First add short summary of what are we trying to do here]] 548 The server attempts to allocate transport addresses. It first looks 549 for the BANDWIDTH attribute for the request. If present, the server 550 determines whether or not it has sufficient capacity to handle a 551 binding that will generate the requested bandwidth. 553 If it does, the server attempts to allocate a transport address for 554 the client. The Allocate request can contain several additional 555 attributes that allow the client to request specific characteristics 556 of the transport address. First, the server checks for the 557 REQUESTED-TRANSPORT attribute. This indicates the transport protocol 558 requested by the client. This specification defines values for UDP 559 and TCP. The server MUST allocate a port using the requested 560 transport protocol. If the REQUESTED-TRANSPORT attribute contains a 561 value of the transport protocol unknown to the server, or known to 562 the server but not supported by the server in the context of this 563 request, the server MUST reject the request and include a 442 564 (Unsupported Transport Protocol) in the response, or else redirect 565 the request. [[OPEN ISSUE: Should we include a list of supported 566 ones? Is this really an issue? If its just ever TCP and UDP its not 567 needed. Can always add it later, as the hooks are here. Proposal: 568 Do not incldue a list of supported transports.]]. If the request did 569 not contain a REQUESTED-TRANSPORT attribute, the server MUST use the 570 same transport protocol as the request arrived on. 572 As a consequence of the REQUESTED-TRANSPORT attribute, it is possible 573 for a client to connect to the server over TCP or TLS over TCP and 574 request a UDP transport address. In this case, the server will relay 575 data between the transports. 577 Next, the server checks for the REQUESTED-IP attribute. If present, 578 it indicates a specific interface from which the client would like 579 its transport address allocated. If this interface is not a valid 580 one for allocations on the server, the server MUST reject the request 581 and include a 443 (Invalid IP Address) error code in the response, or 582 else redirect the request to a server that is known to support this 583 IP address. If the IP address is one that is valid for allocations 584 (presumably, the server is configured to know the set of IP addresses 585 from which it performs allocations), the server MUST provide an 586 allocation from that IP address. If the attribute is not present, 587 the selection of an IP address is at the discretion of the server. 589 Finally, the server checks for the REQUESTED-PORT-PROPS attribute. 590 If present, it indicates specific port properties desired by the 591 client. This attribute is split into two portions: one portion for 592 port behavior and the other for requested port alignment (whether the 593 allocated port is odd, even, reserved as a pair, or at the discretion 594 of the server). 596 If the port behavior requested is for a Specific Port, the server 597 MUST attempt to allocate that specific port for the client. If the 598 port is allocated to a different internal 5-tuple associated with the 599 same STUN long-term credentials, the client is requesting a move. 600 The server SHOULD replace the old internal 5-tuple with the new one 601 over which this Allocate request arrived. The server MUST reject the 602 move request if any of the attributes other than LIFETIME have 603 changed (BANDWIDTH, REQUESTED_TRANSPORT, etc.). 605 If the specific port is not available (in use or reserved), the 606 server MUST reject the request with a 444 (Invalid Port) response or 607 redirect to an alternate server. For example, the STUN server could 608 reject a request for a Specific Port because the port is temporarily 609 reserved as part of an adjacent pair of ports, or because the 610 requested port is a well-known port (1-1023). 612 If the port behavior requested is for a Door, the server opens the 613 allocated port for receiving so that the first incoming datagram (for 614 UDP allocations) or connection request (for TCP allocations) creates 615 a new binding and then "closes" so that datagrams or connection 616 request from other addresses are silently dropped. Requests for a 617 port with door behavior can still include port alignment requests 618 which MUST still be honored. Requests for a port with the door 619 property MUST NOT be allocated from the well-known port range 620 (1-1023). 622 If the client requests even port alignment, the server MUST attempt 623 to allocate an even port for the client. If an even port cannot be 624 obtained, the server MUST reject the request with a 444 (Invalid 625 Port) response or redirect to an alternate server. If the client 626 request odd port alignment, the server MUST attempt to allocate an 627 odd port for the client. If an odd port cannot be obtained, the 628 server MUST reject the request with a 444 (Invalid Port) response or 629 redirect to an alternate server. Finally, the Even port with hold of 630 the next higher port is similar to Even port. It is a request for an 631 even port, and MUST be rejected by the server if an even port cannot 632 be provided, or redirected to an alternate server. However, it is 633 also a hint from the client that the client will request the next 634 higher port with a separate Allocate request. As such, it is a 635 request for the server to allocate an even port whose next higher 636 port is also available, and furthermore, a request for the server to 637 not allocate that one higher port to any other request except for one 638 that asks for that port explicitly. The server can honor this 639 request for adjacency at its discretion. The only constraint is that 640 the allocated port has to be even. 642 Port alignment requests exist for compatibility with 643 implementations of RTP which pre-date RFC 3550. These 644 implementations use the port numbering conventions in (now 645 obsolete) RFC 1889. 647 If any of the requested or desired constraints cannot be met, whether 648 it be bandwidth, transport protocol, IP address or port, instead of 649 rejecting the request, the server can alternately redirect the client 650 to a different server that may be able to fulfill the request. This 651 is accomplished using the 300 error response and ALTERNATE-SERVER 652 attribute. 654 The server SHOULD only allocate ports in the range 1024-65535. This 655 is one of several ways to prohibit relayed transport addresses from 656 being used to attempt to run standard services. These guidelines are 657 meant to be consistent with [15], since the relay is effectively a 658 NAT. 660 Once the port is allocated, the server associates it with the 661 internal 5-tuple and fills in that 5-tuple. The internal remote 662 transport address of the internal 5-tuple is set to the source 663 transport address of the Allocate Request. The internal local 664 transport address of the internal 5-tuple is set to the destination 665 transport address of the Allocate Request. For TCP, this amounts to 666 associating the TCP connection from the TURN client with the 667 allocated transport address. 669 If the Allocate request was authenticated using a shared secret 670 between the client and server, this credential MUST be associated 671 with the allocation. If the request was authenticated using a short 672 term password derived from a shared secret, that shared secret MUST 673 be associated with the allocation. This is used in subsequent 674 Allocate requests to ensure that only the same client can refresh or 675 modify the characteristics of the allocation it was given. 677 The allocation created by the Allocate request is also associated 678 with a transport address, called the active destination. This 679 transport address is used for forwarding data through the TURN 680 server, and is described in more detail later. It is initially set 681 to null when the allocation is created. In addition, the allocation 682 created by the server is associated with a set of permissions. Each 683 permission is a specific IP address identifying an external client. 684 Initially, this list is null. Send Indications, Connect requests and 685 Set Active Destination requests add values to this list. 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 13.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 deleting of the allocation. 701 Once the port has been obtained from the operating system and the 702 activity timer started for the port binding, the server generates an 703 Allocate Response using the general procedures defined in [1]. The 704 transport address allocated to the client MUST be included in the 705 RELAY-ADDRESS attribute in the response. In addition, this response 706 MUST contain the XOR-MAPPED-ADDRESS attribute. This allows the 707 client to determine its reflexive transport address in addition to a 708 relayed transport address, from 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 14. 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 If the allocated port was for TCP, the server MUST be prepared to 725 receive a TCP connection request on that port. 727 9.1.1.2 Subsequent Requests 729 A subsequent Allocate request is one received whose source and 730 destination IP address and ports match the internal 5-tuple of an 731 existing allocation. The request is processed using the general 732 server procedures in [1] and is processed identically to 733 Section 9.1.1.1, with a few important exceptions. 735 First, the request MUST be authenticated using the same shared secret 736 as the one associated with the allocation, or be authenticated using 737 a short term password derived from that shared secret. If the 738 request was authenticated but not with such a matching credential, 739 the server MUST generate an Allocate Error Response with a 441 740 response code. 742 Secondly, if the allocated transport address given out previously to 743 the client still matches the constraints in the request (in terms of 744 request ports, IP addresses and transport protocols), the same 745 allocation granted previously MUST be returned. However, if one of 746 the constraints is not met any longer, because the client changed 747 some aspect of the request, the server MUST free the previous 748 allocation and allocate a new request to the client. Note that a 749 subsequent Allocate request cannot request an allocation with door 750 properties if the allocation is associated with any external 751 5-tuples. 753 Finally, a subsequent Allocate request will set a new allocation 754 expiration timer for the allocation, effectively canceling the 755 previous lifetime expiration timer. 757 9.1.2 Client Behavior 759 Client behavior for Allocate requests depends on whether the request 760 is an initial one, for the purposes of obtaining a new relayed 761 transport address, or a subsequent one, used for refreshing an 762 existing allocation. 764 9.1.2.1 Initial Requests 766 When a client wishes to obtain a transport address, it sends an 767 Allocate Request to the server. This request is constructed and sent 768 using the general procedures defined in [1]. The server will 769 challenge the request for credentials. The client MAY either provide 770 its credentials to the server directly, or it MAY obtain a short-term 771 set of credentials using the Shared Secret request and then use those 772 as the credentials in the Allocate request. 774 The client SHOULD include a BANDWIDTH attribute, which indicates the 775 maximum bandwidth that will be used with this binding. If the 776 maximum is unknown, the attribute is not included in the request. 778 The client MAY request a particular lifetime for the allocation by 779 including it in the LIFETIME attribute in the request. 781 The client MAY include a REQUESTED-PORT-PROPS, REQUESTED-TRANSPORT, 782 or REQUESTED-IP attribute in the request to obtain specific types of 783 transport addresses. Whether these are needed depends on the 784 application using the relay usage. As an example, the Real Time 785 Transport Protocol (RTP) [5] requires that RTP and RTCP ports be an 786 adajacent pair, even and odd respectively, for compatibility with a 787 previous version of that specification. The REQUESTED-PORT attribute 788 allows the client to ask the relay for those properties. The client 789 MUST NOT request TCP transport in an Allocate request sent to the 790 STUN relay server over UDP. 792 The client MAY ask for a port with the door property. Since the door 793 only creates a binding for the first datagram or connection request 794 it receives, a client needs to use this feature judiciously. For 795 example, a client is most likely to use this feature if wants to 796 establish a TCP connection to its peer, where both the client and the 797 peer are behind a NAT or firewall that only allows outgoing TCP 798 connections. While the client may be able to communicate with its 799 peer using TCP simultaneous open, simultaneous open requires rather 800 sophisticated behavior on the client, the peer, and both NATs or 801 firewalls to work. 803 Processing of the response follows the general procedures of [1]. A 804 successful response will include both a RELAY-ADDRESS and an XOR- 805 MAPPED-ADDRESS attribute, providing both a relayed transport address 806 and a reflexive transport address, respectively, to the client. The 807 server will expire the allocation after LIFETIME seconds have passed 808 if not refreshed by another Allocate request. The server will allow 809 the user to send and receive no more than the amount of data 810 indicated in the BANDWIDTH attribute. 812 If the response is an error response and contains a 442, 443 or 444 813 error code, the client knows that its requested properties could not 814 be met. The client MAY retry with different properties, with the 815 same properties (in a hope that something has changed on the server), 816 or give up, depending on the needs of the application. However, if 817 the client retries, it SHOULD wait 500ms, and if the request fails 818 again, wait 1 second, then 2 seconds, and so on, exponentially 819 backing off. 821 9.1.2.2 Subsequent Requests 823 Before 3/4 of the lifetime of the allocation has passed (the lifetime 824 of the allocation is conveyed in the LIFETIME attribute of the 825 Allocate Response), the client SHOULD refresh the allocation with 826 another Allocate Request if it wishes to keep the allocation. 828 To perform a refresh, the client generates an Allocate Request as 829 described in Section 9.1.2.1. If the initial request was 830 authenticated with a shared secret P that the client holds with the 831 server, or using a short term password derived from P through a 832 Shared Secret request, the client MUST use shared secret P, or a 833 short-term password derived from it, in the subsequent request. 835 In a successful response, the RELAY-ADDRESS contains the same 836 transport address as previously obtained, indicating that the binding 837 has been refreshed. The LIFETIME attribute indicates the amount of 838 additional time the binding will live without being refreshed. Note 839 that an error response does not imply that the binding has been 840 expired, just that the refresh has failed. 842 If a client no longer needs a binding, it SHOULD tear it down. If 843 the client wishes to explicitly remove the allocation because it no 844 longer needs it, it generates a subsequent Allocate request, but sets 845 the LIFETIME attribute to zero. This will cause the server to remove 846 the allocation. For TCP, the client can also remove the binding by 847 closing connection with the STUN relay server. 849 9.2 Set Active Destination Request 851 9.2.1 Server Behavior 853 The Set Active Destination Request is used by a client to set an 854 existing external binding that will be used as the forwarding 855 destination of all data that is not encapsulated in STUN Send 856 Indications. In addition, all data received from that external 857 client will be forwarded to the STUN client without encapsulation in 858 a Data Indication. 860 Once the server has identified a request as a Set Active Destination 861 request, the server verifies that it has arrived with a source and 862 destination transport address that matches the internal remote and 863 local transport address of an internal 5-tuple associated with an 864 existing allocation. If there is no matching allocation, the server 865 MUST generate a 437 (No Binding) Send Error Response. 867 The request MUST be authenticated using the same shared secret as the 868 one associated with the allocation, or be authenticated using a short 869 term password derived from that shared secret. If the request was 870 authenticated but not with such a matching credential, the server 871 MUST generate an error response with a 441 response code. 873 [[OPEN ISSUE: Can we eliminate the whole race condition, by requiring 874 the client to close the binding and wait 5 seconds (with no server 875 verification of this requirement) before issuing a new Set Active 876 Destination request? Proposed text follows:]] If an active 877 destination is already set, the Set Active Destination request is 878 rejected with a 439 Active Destination Already Set error response. 880 If the Set Active Destination request contains a REMOTE-ADDRESS 881 attribute, the IP address contained within it is added to the 882 permissions for this allocation, if it was not already present. 884 [[OPEN ISSUE: When do you ever want to set active for a destination 885 you have never sent to?]] 887 Unfortunately, there is a race condition associated with the active 888 destination concept. Consider the case where the active destination 889 is set, and the server is relaying packets towards the client. The 890 client knows the IP address and port where the packets came from - 891 the current value of the active destination. The client issues a Set 892 Active Destination Request to change the active destination, and 893 receives a response. A moment later, a data packet is received, not 894 encapsulated in a STUN Data Indication. What is the source if this 895 packet? Is it the active destination that existed prior to the Set 896 Active Destination request, or the one after? If the transport 897 between the client and the STUN server is not reliable, there is no 898 way to know. 900 To deal with this problem, a small state machine is used to force a 901 "cooldown" period during which the server will not relay packets 902 towards the client without encapsulating them. This cooldown period 903 gives enough time for the client to be certain that any old data 904 packets have left the network. Once the cooldown period ends, the 905 server can begin relaying packets without encapsulation. There is an 906 instance of this state machine for each allocation. 908 +-----+ 909 | | Req Recvd, DA absent 910 | | 911 | | 912 | | 913 | V 914 +-----------+ 915 | | timer fires 916 | | ----------- 917 | None | active=null 918 | Set |<--------------------------------+ 919 | | | 920 | | | 921 +-----------+ | 922 | | Req Recvd 923 | | --------- 924 | Req Recvd, DA present | 439 925 | ---------------------- | +----+ 926 | active = DA | | | 927 | | | | 928 | | | | 929 V Req Recvd, | | V 930 +-----------+ DA!=active,absent +-----------+ 931 | | ----------------- | | 932 | | Set timer | | 933 | Set |------------------------------>| Trans- | 934 | | | itioning | 935 | |<------------------------------| | 936 | | timer fires | | 937 +-----------+ ----------- +-----------+ 938 | ^ active=DA 939 | | 940 | | 941 | | 942 +-----+ 943 Req Recvd, DA=active 945 Figure 4 947 When the allocation is originally created, the active destination is 948 null, and the server sets the state to "None Set". In this state, 949 the server will relay all received packets in encapsulated form 950 towards the client. If the server receives a Set Active Destination 951 request, but the request contained no REMOTE-ADDRESS attribute, the 952 state machine stays in the same state. The request is responded to 953 with a Set Active Destination Response. If, however, the Set Active 954 Destination request contained a REMOTE-ADDRESS, the server sets the 955 active destination to the transport address from the REMOTE-ADDRESS 956 attribute, and enters the "Set" state. The request is responded to 957 with a Set Active Destination Response. In this state, the server 958 will relay packets from that transport address towards the client in 959 unencapsulated form. 961 If the server receives another Set Active Destination request while 962 in this state, and the REMOTE-ADDRESS is present, but has a value 963 equal to the current active destination, the request causes no 964 change. The request is responded to with a Set Active Destination 965 Response. If, however, the request contained a REMOTE-ADDRESS which 966 did not match the existing active destination, or omitted the active 967 destination, the server enters the "transitioning" state. The 968 request is responded to with a Set Active Destination Response. In 969 this state, the server will forward all packets to the client in 970 encapsulated form. In addition, when this state is entered, the 971 client sets a timer to fire in Ta seconds. If the connection between 972 the client and server is unreliable, this timer SHOULD be 973 configurable. It is RECOMMENDED that it be set to three seconds. If 974 the connection between the client and server is reliable, the timer 975 SHOULD be set to 0 seconds, causing it to fire immediately. This 976 makes the transitioning state transient for reliable transports. The 977 value of the timer used by the server, regardless of the transport 978 protocol, MUST be included in a TIMER-VAL attribute in the Set Active 979 Destination response. 981 If, while in the "transitioning" state, the server receives a Set 982 Active Destination Request, it generates a Set Active Destination 983 Error Response that includes a 439 (Transitioning) response code. 984 Once the timer fires, the server transitions to the "Set" state if 985 the Set Active Destination request that caused the server to enter 986 "transitioning" had contained the REMOTE-ADDRESS. In this case, the 987 active destination is set to this transport address. If the Set 988 Active Destination request had not contained a REMOTE-ADDRESS 989 attribute, the server enters the "Not Set" state and sets the active 990 destination to null. 992 9.2.2 Client Behavior 994 The Set Active Destination address allows the client to create an 995 optimized relay function between it and the server. When the server 996 receives packets from a particular preferred external client, the 997 server will forward those packets towards the client without 998 encapsulating them in a Data Indication. Similarly, the client can 999 send non-STUN packets to the server without encapsulation, and these 1000 are forwarded to the external client. Sending and receiving data in 1001 unencapsulated form is critical for efficiency purposes. One of the 1002 primary use cases for the STUN relay usage is in support of Voice 1003 over IP (VoIP), which uses very small UDP packets to begin with. The 1004 extra overhead of an additional layer of encapsulation is considered 1005 unacceptable. 1007 The Set Active Destination request is used by the client to provide 1008 the identity of this preferred external client. The request also has 1009 the side effect of adding a permission for the target of the REMOTE- 1010 ADDRESS. [[OPEN ISSUE: is this necessary?]] 1012 The Set Active Destination address MAY contain a REMOTE-ADDRESS 1013 attribute. This attribute, when present, provides the address of the 1014 preferred external client to the server. When absent, it clears the 1015 value of the preferred external client. 1017 [[OPEN ISSUE: Proposed wording to eliminate the Set Active 1018 Destination transitioning state machine follows.]] The client MUST 1019 NOT send a Set Active Destination request with a REMOTE-ADDRESS 1020 attribute over an unreliable link (ex: UDP) if an active destination 1021 is already set for that allocation. If the client wishes to set a 1022 new active destination, it MUST wait until 5 seconds after a 1023 successful response is received to a Set Destination Request removing 1024 the active destination. Failure to wait could cause the client to 1025 receive and attribute late data forwarded by the STUN relay server to 1026 the wrong peer. 1028 In order for the client to know where incoming non-STUN packets were 1029 sent from, and to be sure where non-STUN packets sent to the server 1030 will go to, it is necessary to coordinate the value of the active 1031 destination between the client and the server. As discussed above, 1032 there is a race condition involved in this coordination which 1033 requires a state machine to execute on both the client and the 1034 server. 1036 +-----+ 1037 | | OK Recvd, DA absent 1038 | | 1039 | | 1040 | | 1041 | V 1042 +-----------+ 1043 439 Recvd| | timer fires 1044 +------| | ----------- 1045 | | None | active=null 1046 | | Set |<--------------------------------+ 1047 +----->| | | 1048 | | | 1049 +-----------+ | 1050 | | 1051 | | 1052 | OK Recvd, DA present | 1053 | ---------------------- | 1054 | active = DA | 1055 | | 1056 | | 1057 V OK Recvd, | 1058 +-----------+ DA!=active,absent +-----------+ 1059 | | ----------------- | | 1060 | | Set timer | | 1061 | Set |------------------------------>| Trans- | 1062 | | | itioning | 1063 | |<------------------------------| | 1064 | | timer fires | | 1065 +-----------+ ----------- +-----------+ 1066 | ^ active=DA 1067 | | 1068 | | 1069 | | 1070 +-----+ 1071 439 Recvd, 1072 OK Recvd, DA=active 1074 Figure 5 1076 The state machine is shown in Figure 5. The client starts in the 1077 "None Set" state. When the client is in either the "None Set" or 1078 "Set" state, it can send Set Active Destination requests. The 1079 transitions in the state machines are governed by responses to those 1080 requests. Only success and 439 responses cause changes in state. A 1081 437 response implies that the allocation has been removed, and thus 1082 the state machine destroyed. A client MUST NOT send a new Set Active 1083 Destination request prior to the receipt of a response to the 1084 previous. The state machine will further limit the transmission of 1085 subsequent Set Active Destination requests. 1087 If, while in the "None Set" state, the client sent a Set Active 1088 Destination request without a REMOTE-ADDRESS, and got a successful 1089 response, there is no change in state. If a successful response was 1090 received, but there was a REMOTE-ADDRESS in the request, the state 1091 machine transitions to the "Set" state, and the client sets the 1092 active destination to the value of the REMOTE-ADDRESS attribute that 1093 was in the request. 1095 If, while in the "Set" state, the client sends a Set Active 1096 Destination request and received a 439 response, it means that there 1097 was a temporal misalignment in the states between client and server. 1098 The client thought that the active destination was updated on the 1099 server, but the server was still in its transitioning state. When 1100 this error is received, the client remains in the "Set" state. The 1101 client SHOULD retry its Set Active Destination request, but no sooner 1102 than 500ms after receipt of the 439 response. In addition, if, while 1103 in the "Set" state, the client sends a Set Active Destination request 1104 whose REMOTE-ADDRESS attribute equals the current active destination, 1105 and that request generates a success response, the client remains in 1106 the "Set" state. 1108 However, if, while in the "Set" state, the client sends a Set Active 1109 Destination request whose REMOTE-ADDRESS was either absent or not 1110 equal to the current active destination, and receives a success 1111 response, the client enters the "Transitioning" state. While in this 1112 state, the client MUST NOT send a new Set Active Destination request. 1113 The value of the active destination remains unchanged. In addition, 1114 the client sets a timer. This timer MUST have a value equal to the 1115 value of the TIMER-VAL attribute from the Set Active Destination 1116 response. This is necessary for coordinating the state machines 1117 between client and server. 1119 Once the timer fires, if the REMOTE-ADDRESS was not absent from the 1120 Set Active Destination request which caused the client to start the 1121 timer, the client moves back to the "Set" state, and then updates the 1122 value of the active destination to the value of REMOTE-ADDRESS. If 1123 REMOTE-ADDRESS was absent, the client sets the active destination to 1124 null and enders the "None Set" state. 1126 9.3 Open Binding Request 1128 The Open Binding Request is used to create a binding between an 1129 internal 5-tuple and an external 5-tuple, without actually sending 1130 any data to the peer. It is included for completeness, but could be 1131 used to open bindings for multiple TCP peers that are capable of TCP 1132 simultaneous open. [[OPEN ISSUE: do we want to include an explicit 1133 Open Binding request or not?]] 1135 9.3.1 Server Behavior 1137 When the server receives an Open Binding request, it verifies that 1138 the requester authenticated and used the same credentials as used in 1139 the corresponding Allocate request. The server looks for a binding 1140 with an external 5-tuple that matches the value of the REMOTE-ADDRESS 1141 attribute. As long as the binding does not already exist, the server 1142 creates the binding as if it received a Send Indication to the peer. 1143 If the binding already exists, the server rejects the request with a 1144 444 (Invalid Port) error. 1146 9.3.2 Client Behavior 1148 The client MAY send an Open Binding request to the STUN relay server 1149 to open a binding without sending data with an explicit Send 1150 Indication. To do so, it places the IP address and port number of 1151 the target peer in a REMOTE-ADDRESS attribute and sends the request. 1153 9.4 Close Binding Request 1155 The Close Binding Request is designed to squelch possibly undesirable 1156 traffic relayed to the client. For example, the client may receive 1157 multiple streams of early media or may be the victim of a limited DoS 1158 attack, or the wrong peer may have accidentally sent a packet to a 1159 door allocated by the client. [[OPEN ISSUE: do we want to include an 1160 explicit Close Binding request or not?]] 1162 9.4.1 Server Behavior 1164 When the server receives a Close Binding request, it verifies that 1165 the requester authenticated and used the same credentials as used in 1166 the corresponding Allocate request. The server looks for a binding 1167 with an external 5-tuple that matches the value of the REMOTE-ADDRESS 1168 attribute. If the binding exists, the server immediately removes the 1169 binding. If the external transport is TCP, the server closes the TCP 1170 connection. If the active destination was set to the deleted 1171 binding, the client to server link reverts to the state where no 1172 active destination is set. A Close Binding request does NOT 1173 deallocate the port assigned using the Allocate request. 1175 If the binding does not exist, the server rejects the request with a 1176 444 (Invalid Port) error. 1178 9.4.2 Client Behavior 1180 If the client wants to explicitly remove a binding to a peer, without 1181 performing a deallocation, it MAY send a Close Binding Request. To 1182 do so, it places the IP address and port number of the binding it 1183 wants to remove in a REMOTE-ADDRESS attribute and sends the request. 1185 9.5 Connection Status Indication 1187 TODO: Expand this text. 1189 When the STUN relay to peer leg is TCP, the STUN relay client needs 1190 to be aware of the status of these TCP connections. The STUN relay 1191 extension defines application states for a TCP connection as follows: 1192 LISTEN, ESTABLISHED, CLOSED. Consequently, the STUN relay server 1193 sends a ConnectionState Indication for a binding whenever the relay 1194 connection status changes for one of the client's bindings except 1195 when the status changes due to a STUN relay client request (ex: an 1196 explicit binding close or deallocation). 1198 A STUN relay can only relay to a peer over TCP if the client 1199 communicates with the server over TCP or TLS over TCP. Because of 1200 this, the server can be assured that Connection Status Indications 1201 are received reliably. 1203 9.6 Send Indication 1205 9.6.1 Server Behavior 1207 A Send Indication is sent by a client after it has completed its 1208 Allocate transaction, in order to create permissions in the server 1209 and send data to an external client. 1211 Once the server has identified a message as a Send Indication, the 1212 server verifies that it has arrived with a source and destination 1213 transport address that matches the internal remote and local 1214 transport address of an internal 5-tuple associated with an existing 1215 allocation. If there is no matching allocation, the indication is 1216 discarded. If there was no REMOTE-ADDRESS, the indication is 1217 discarded. If there was no DATA attribute, the indication is 1218 discarded. 1220 Note that Send Indications are not authenticated and do not 1221 contain a MESSAGE-INTEGRITY attribute. Just like non-relayed data 1222 sent over UDP or TCP, the authenticity and integrity of this data 1223 can only be assured using security mechanisms at higher layers. 1225 The server takes the contents of the DATA attribute present in the 1226 indication. If the allocation was a UDP allocation, the server 1227 creates a UDP packet whose payload equals that content. The server 1228 sets the source IP address of the packet equal to the allocated 1229 transport address. The destination transport address is set to the 1230 contents of the REMOTE-ADDRESS attribute. The server then sends the 1231 UDP packet. Note that any retransmissions of this packet which might 1232 be needed are not handled by the server. It is the clients 1233 responsibility to generate another Send indication if needed. If the 1234 STUN relay client hasn't previously sent to this destination IP 1235 address and port, an external 5-tuple is instantiated in the server. 1236 Its local and remote transport addresses, respectively, are set to 1237 the source and destination transport addresses of the UDP packet. 1239 The server then adds the IP address of the REMOTE-ADDRESS attribute 1240 to the permission list for this allocation. 1242 In the case of a TCP allocation, the server checks if it has an 1243 existing TCP connection open from the allocated transport address to 1244 the address in the REMOTE-ADDRESS attribute. If so, the server 1245 extracts the content of the DATA attribute and sends it on the 1246 matching TCP connection. If the server doesn't have an existing TCP 1247 connection to the destination, it adds the REMOTE-ADDRESS to the 1248 permission list and discards the data. The peer must first open a 1249 TCP connection to the STUN relay server before it can receive data 1250 sent by the client. 1252 9.6.2 Client Behavior 1254 Before receiving any UDP or TCP data, a client has to send first. 1255 Prior to the establishment of an active destination, or while the 1256 client is in the transitioning state, transmission of data towards a 1257 peer through the relay is done using the Send Indication. Indeed, if 1258 the client is in the transitioning state, and it wishes to send data 1259 through the relay, it MUST use a Send indication. 1261 For TCP allocated transport addresses, the client needs to wait for 1262 the peer to open a connection to the STUN relay server before it can 1263 send data. Data sent with a Send request prior to the opening of a 1264 TCP connection is discarded silently by the server. 1266 The Send Indication MUST contain a REMOTE-ADDRESS attribute, which 1267 contains the IP address and port that the data is being sent to. The 1268 DATA attribute MAY be present, and contains the data that is to be 1269 sent towards REMOTE-ADDRESS. If absent, the server will send an 1270 empty UDP packet in the case of UDP. In the case of TCP, the server 1271 will do nothing. 1273 Since Send is an Indication, it generates no response. The client 1274 must rely on application layer mechanisms to determine if the data 1275 was received by the peer. 1277 9.7 Data Indication 1279 Note that Data Indications are not authenticated and do not 1280 contain a MESSAGE-INTEGRITY attribute. Just like non-relayed data 1281 sent over UDP or TCP, the authenticity and integrity of this data 1282 can only be assured using security mechanisms at higher layers. 1284 9.7.1 Server Behavior 1286 A server MUST send data packets towards the client using a Data 1287 Indication under the conditions described in Section 13.1. Data 1288 Indications MUST contain a DATA attribute containing the data to 1289 send, and MUST contain a REMOTE-ADDRESS attribute indicating where 1290 the data came from. 1292 9.7.2 Client Behavior 1294 Once a client has obtained an allocation and created permissions for 1295 a particular external client, the server can begin to relay packets 1296 from that external client towards the client. If the external client 1297 is not the active destination, this data is relayed towards the 1298 client in encapsulated form using the Data Indication. 1300 The Data Indication contains two attributes - DATA and REMOTE- 1301 ADDRESS. The REMOTE-ADDRESS attribute indicates the source transport 1302 address that the request came from, and it will equal the external 1303 remote transport address of the external client. When processing 1304 this data, a client MUST treat the data as if it came from this 1305 address, rather than the stun server itself. The DATA attribute 1306 contains the data from the UDP packet or TCP segment that was 1307 received. Note that the TURN server will not retransmit this 1308 indication over UDP. 1310 10. New Attributes 1312 The STUN relay usage defines the following new attributes: 1314 0x000D: LIFETIME 1315 0x0010: BANDWIDTH 1316 0x0012: REMOTE-ADDRESS 1317 0x0013: DATA 1318 0x0016: RELAY-ADDRESS 1319 0x0018: REQUESTED-PORT 1320 0x0019: REQUESTED-TRANSPORT 1321 0x0022: REQUESTED-IP 1322 0x0021: TIMER-VAL 1324 10.1 LIFETIME 1326 The lifetime attribute represents the duration for which the server 1327 will maintain an allocation in the absence of data traffic either 1328 from or to the client. It is a 32 bit value representing the number 1329 of seconds remaining until expiration. 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Lifetime | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 10.2 BANDWIDTH 1337 The bandwidth attribute represents the peak bandwidth, measured in 1338 kbits per second, that the client expects to use on the binding. The 1339 value represents the sum in the receive and send directions. 1340 [[Editors note: Need to define leaky bucket parameters for this.]] 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Bandwidth | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 10.3 REMOTE-ADDRESS 1348 The REMOTE-ADDRESS specifies the address and port of the peer as seen 1349 from the STUN relay server. It is encoded in the same way as MAPPED- 1350 ADDRESS. 1352 10.4 DATA 1354 The DATA attribute is present in Send Indications and Data 1355 Indications. It contains raw payload data that is to be sent (in the 1356 case of a Send Request) or was received (in the case of a Data 1357 Indication). 1359 10.5 RELAY-ADDRESS 1361 The RELAY-ADDRESS is present in Allocate responses. It specifies the 1362 address and port that the server allocated to the client. It is 1363 encoded in the same way as MAPPED-ADDRESS. 1365 10.6 REQUESTED-PORT-PROPS 1367 This attribute allows the client to request certain properties for 1368 the port that is allocated by the server. The attribute can be used 1369 with any transport protocol that has the notion of a 16 bit port 1370 space (including TCP and UDP). The attribute is 32 bits long. Its 1371 format is: 1373 0 1 2 3 1374 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 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | Reserved = 0 | B | A | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 The lower two bits (labeled A in the diagram) are for requested port 1380 alignment. 1382 00 no specific port alignment 1383 01 odd port number 1384 10 even port number 1385 11 even port number; reserve next higher port 1387 The next higher two bits (labeled B in the diagram) are for requested 1388 port allocation behavior. 1390 00 no special behavior requested 1391 01 specific port requested 1392 10 door requested 1393 11 reserved - invalid 1395 All other bits in this attribute are reserved and MUST be set to 1396 zero. 1398 Even Port is a request to the server to allocate a port with even 1399 parity. The port filter is not used with this property. Odd Port is 1400 a request to the server to allocate a port with odd parity. The port 1401 filter is not used with this property. Even port, with a hold on the 1402 next higher port, is a request to the server to allocate an even 1403 port. Furthermore, the client indicates that it will want the next 1404 higher port as well. As such, the client requests that the server, 1405 if it can, not allocate the next higher port to anyone unless that 1406 port is explicitly requested, which the client will itself do. The 1407 port filter is not used with this property. Finally, the Specific 1408 Port property is a request for a specific port. The port that is 1409 requested is contained in the Port filter. 1411 Extensions to the relay usage can define additional port properties. 1412 [[TODO: Add IANA registry]] 1414 10.7 REQUESTED-TRANSPORT 1416 This attribute is used by the client to request a specific transport 1417 protocol for the allocated transport address. It is a 32 bit 1418 unsigned integer. Its values are: 1420 0x0000 0000: UDP 1421 0x0000 0001: TCP 1423 If an Allocate request is sent over TCP and requests a UDP 1424 allocation, or an Allocate request is sent over TLS over TCP and 1425 requests a UDP or TCP allocation, the server will relay data between 1426 the two transports. 1428 Extensions to the relay usage can define additional transport 1429 protocols. [[TODO: Add IANA registry]] 1431 10.8 REQUESTED-IP 1433 The REQUESTED-IP attribute is used by the client to request that a 1434 specific IP address be allocated to it. This attribute is needed 1435 since it is anticipated that STUN relays will be multi-homed so as to 1436 be able to allocate more than 64k transport addresses. As a 1437 consequence, a client needing a second transport address on the same 1438 interface as a previous one can make that request. 1440 The format of this attribute is identical to MAPPED-ADDRESS. 1441 However, the port component of the attribute is ignored by the 1442 server. If a client wishes to request a specific IP address and 1443 port, it uses both the REQUESTED-IP and REQUESTED-PORT attributes. 1445 10.9 TIMER-VAL 1447 The TIMER-VAL attribute is used only in conjunction with the Set 1448 Active Destination response. It conveys from the server, to the 1449 client, the value of the timer used in the server state machine. 1451 Coordinated values are needed for proper operation of the mechanism. 1453 The attribute is a 32 bit unsigned integer representing the number if 1454 milliseconds used by the server for its timer. 1456 11. New Error Response Codes 1458 The STUN relay usage defines the following new Error response codes: 1460 437 (No Binding): A request was received by the server that 1461 requires an allocation to be in place. However, there is none yet 1462 in place. 1464 439 (Transitioning): A Set Active Destination request was received 1465 by the server. However, a previous request was sent within the 1466 last few seconds, and the server is still transitioning to that 1467 active destination. Please repeat the request later. 1469 441 (Wrong Username): A TURN request was received for an allocated 1470 binding, but it did not use the same username and password that 1471 were used in the allocation. The client must supply the proper 1472 credentials, and if it cannot, it should teardown its binding, 1473 allocate a new one time password, and try again. 1475 442 (Unsupported Transport Protocol): The Allocate request asked 1476 for a transport protocol to be allocated that is not supported by 1477 the server. 1479 443 (Invalid IP Address): The Allocate request asked for a 1480 transport address to be allocated from a specific IP address that 1481 is not valid on the server. 1483 444 (Invalid Port): The Allocate request asked for a port to be 1484 allocated that is not available on the server. 1486 445 (Operation for TCP Only): The client tried to send a request 1487 to perform a TCP-only operation on an allocation, and allocation 1488 is UDP. 1490 446 (Connection Failure): The attempt by the server to open the 1491 connection failed. 1493 447 (Connection Timeout): The attempt by the server to open the 1494 connection could not be completed, and is still in progress. 1496 12. Client Procedures 1498 12.1 Receiving and Sending Unencapsulated Data 1500 Once the active destination has been set, a client will receive both 1501 STUN and non-STUN data on the socket on which the Allocate Request 1502 was sent. The encapsulation behavior depends on the protocol used 1503 between the STUN client and the STUN relay server. 1505 12.2 Datagram Protocols 1507 If the allocation was over UDP, datagrams which contain the STUN 1508 magic cookie are treated as STUN requests. All other data is non- 1509 STUN data, which MUST be processed as if it had a source IP address 1510 and port equal to the value of the active destination. 1512 If the client wants to send data to the peer which contains the magic 1513 cookie in the same location as a STUN request, it MUST send that data 1514 encapsulated in a Send Indication, even if the active destination is 1515 set. 1517 In addition, once the active destination has been set, if the client 1518 is in the "Set" state, it MAY send data to the active destination by 1519 sending data on that same socket. Unencapsulated data MUST NOT be 1520 sent while in the "Not Set" or "Transitioning" states. However, it 1521 is RECOMMENDED that the client not send unencapsulated data for 1522 approximately 500 milliseconds after the client enters the "Set" 1523 state. This eliminates any synchronization problems resulting from 1524 network delays. Of course, even if the active destination is set, 1525 the client can send data to that destination at any time by using the 1526 Send Indication. 1528 12.3 Stream Transport Protocols 1530 If the allocation was over TCP or TLS over TCP, once the active 1531 destination is set, the client will receive data framed as described 1532 in Section 8. The client MUST treat data encapsulated as data with 1533 this framing as if it originated from the active destination. 1535 The client SHOULD send data encapsulated using this framing scheme or 1536 it MAY place the data inside Send Indications. 1538 13. Server Procedures 1540 Besides the processing of the request and indications described 1541 above, this specification defines rules for processing of data 1542 packets received by the STUN server. There are two cases - receipt 1543 of any packets on an allocated address, and receipt of non-STUN data 1544 on its internal local transport address. 1546 13.1 Receiving Data on Allocated Transport Addresses 1548 13.1.1 TCP Processing 1550 If a server receives a TCP connection request on an allocated TCP 1551 transport address, it checks the permissions associated with that 1552 allocation. If the source IP address of the TCP SYN packet match one 1553 of the permissions, the TCP connection is accepted. Otherwise, it is 1554 rejected. No information is passed to the client about the 1555 acceptance of the connection; rather, data passed to the client with 1556 a source transport address it has not seen before serves this 1557 purpose. [[TODO fix]] 1559 If a server receives data on a TCP connection that terminates on the 1560 allocated TCP transport address, the server checks the value of the 1561 active destination. If it equals the source IP address and port of 1562 the data packet (in other words, if the active destination identifies 1563 the other side of the TCP connection), the server checks the state 1564 machine of the allocation. If the state is "Set", the data is taken 1565 from the TCP connection and sent towards the client in unencapsulated 1566 form. Otherwise, the data is sent towards the client in a Data 1567 Indication, also known as encapsulated form. In this form, the 1568 server MUST add a REMOTE-ADDRESS which corresponds to the external 1569 remote transport address of the TCP connection, and MUST add a DATA 1570 attribute containing the data received on the TCP connection. 1572 Sending of the data towards the client, whether in encapsulated or 1573 unencapsulated form, depends on the linkage with the client. If the 1574 linkage with the client is over UDP, the data is placed in a UDP 1575 datagram and sent over the linkage. Note that the server will not 1576 retransmit this data to ensure reliability. If the linkage with the 1577 client is over TCP, the data is placed into the TCP connection 1578 corresponding to the linkage. If the TCP connection generates an 1579 error (because, for example, the incoming TCP packet rate exceeds the 1580 throughput of the TCP connection to the client), the data is 1581 discarded silently by the server. 1583 Note that, because data is forwarded blindly across TCP bindings, TLS 1584 will successfully operate over a TURN allocated TCP port if the 1585 linkage to the client is also TCP. 1587 13.1.2 UDP Processing 1589 If a server receives a UDP packet on an allocated UDP transport 1590 address, it checks the permissions associated with that allocation. 1591 If the source IP address of the UDP packet matches one of the 1592 permissions, the UDP packet is accepted. Otherwise, it is discarded. 1594 Assuming the packet is accepted, it must be forwarded to the client. 1595 It will be forwarded in either encapsulated or unencapsulated form. 1596 To determine which, the server checks the value of the active 1597 destination. If it equals the source IP address and port of the UDP 1598 packet, the server checks the state machine of the allocation. If 1599 the state is "Set", the data is taken from the UDP payload and sent 1600 towards the client in unencapsulated form. Otherwise, the data is 1601 sent towards the client in a Data Indication, also known as 1602 encapsulated form. In this form, the server MUST add a REMOTE- 1603 ADDRESS which corresponds to the external remote transport address of 1604 the UDP packet, and MUST add a DATA attribute containing the data 1605 payload of the UDP packet. 1607 Sending of the data towards the client, whether in encapsulated or 1608 unencapsulated form, depends on the linkage with the client. If the 1609 linkage with the client is over UDP, the data is placed in a UDP 1610 datagram and sent over the linkage. Note that the server will not 1611 retransmit this data to ensure reliability. If the linkage with the 1612 client is over TCP, the data is placed into the TCP connection 1613 corresponding to the linkage. If the TCP connection generates an 1614 error (because, for example, the incoming UDP packet rate exceeds the 1615 throughput of the TCP connection), the data is discarded silently by 1616 the server. 1618 13.2 Receiving Data on Internal Local Transport Addresses 1620 If a server receives a UDP packet from the client on its internal 1621 local transport address, and it is coming from an internal remote 1622 transport address associated with an existing allocation, it 1623 represents UDP data that the client wishes to forward. If the active 1624 destination is not set, the server MUST discard the packet. If the 1625 active destination is set, and the allocated transport protocol is 1626 TCP, the server selects the TCP connection from the allocated 1627 transport address to the active destination. The data is then sent 1628 over that connection. If the transmission fails due to a TCP error, 1629 the data is discarded silently by the server. If the active 1630 destination is set, and the allocated transport protocol is UDP, the 1631 server places the data from the client in a UDP payload, and sets the 1632 destination address and port to the active destination. The UDP 1633 packet is then sent with a source IP address and port equal to the 1634 allocated transport address. Note that the server will not 1635 retransmit the UDP datagram. 1637 If a server receives data on a TCP connection to a client, the server 1638 retrieves the allocation bound to that connection. If the active 1639 destination for the allocation is not set, the server MUST discard 1640 the data. If the active destination is set, and the allocated 1641 transport protocol is TCP, the server selects the TCP connection from 1642 the allocated transport address to the active destination. The data 1643 is then sent over that connection. If the transmission fails due to 1644 a TCP error, the data is discarded silently by the server. If the 1645 active destination is set, and the allocated transport protocol is 1646 UDP, the server places the data from the client in a UDP payload, and 1647 sets the destination address and port to the active destination. The 1648 UDP packet is then sent with a source IP address and port equal to 1649 the allocated transport address. Note that the server will not 1650 retransmit the UDP datagram. 1652 If a TCP connection from a client is closed, the associated 1653 allocation is destroyed. This involves terminating any TCP 1654 connections from the allocated transport address to external clients 1655 (applicable only when the allocated transport address was TCP), and 1656 then freeing the the allocated transport address (and all associated 1657 state maintained by the server) for use by other clients. 1659 Note that the state of the allocation, whether it is "Set", "Not 1660 Set", or "Transitioning", has no bearing on the rules for forwarding 1661 of packets received from clients. Only the value of the active 1662 destination is relevant. 1664 13.3 Lifetime Expiration 1666 When the allocation expiration timer for a binding fires, the server 1667 MUST destroy the allocation. This involves terminating any TCP 1668 connections from the allocated transport address to external clients 1669 (applicable only when the allocated transport address was TCP), and 1670 then freeing the allocated transport address (and all associated 1671 state maintained by the server) for use by other clients. 1673 [[OPEN ISSUE: This is a change from the previous version, which 1674 allowed data traffic to keep allocations alive. This change was made 1675 based on implementation considerations, as it allows an easier 1676 separation of packet processing and signaling. Is this OK?]] 1678 14. Security Considerations 1680 TODO: Need to spend more time on this. 1682 STUN servers implementing this relay usage allocate bandwidth and 1683 port resources to clients, in constrast to the usages defined in [1]. 1684 Therefore, a STUN server providing the relay usage requires 1685 authentication and authorization of STUN requests. This 1686 authentication is provided by mechanisms defined in the STUN 1687 specification itself. In particular, digest authentication and the 1688 usage of short-term passwords, obtained through a digest exchange 1689 over TLS, are available. The usage of short-tem passwords ensures 1690 that the Allocate Requests, which often do not run over TLS, are not 1691 susceptible to offline dictionary attacks that can be used to guess 1692 the long lived shared secret between the client and the server. 1694 Because STUN servers implementing the relay usage allocate resources, 1695 they can be susceptible to denial-of-service attacks. All Allocate 1696 Requests are authenticated, so that an unknown attacker cannot launch 1697 an attack. An authenticated attacker can generate multiple Allocate 1698 Requests, however. To prevent a single malicious user from 1699 allocating all of the resources on the server, it is RECOMMENDED that 1700 a server implement a modest per user cap on the amount of bandwidth 1701 that can be allocated. Such a mechanism does not prevent a large 1702 number of malicious users from each requesting a small number of 1703 allocations. Attacks as these are possible using botnets, and are 1704 difficult to detect and prevent. Implementors of the STUN relay 1705 usage should keep up with best practices around detection of 1706 anomalous botnet attacks. 1708 A client will use the transport address learned from the RELAY- 1709 ADDRESS attribute of the Allocate Response to tell other users how to 1710 reach them. Therefore, a client needs to be certain that this 1711 address is valid, and will actually route to them. Such validation 1712 occurs through the message integrity checks provided in the Allocate 1713 response. They can guarantee the authenticity and integrity of the 1714 allocated addresss. Note that the STUN relay usage is not 1715 susceptible to the attacks described in Section 12.2.3, 12.2.4, 1716 12.2.5 or 12.2.6 of RFC 3489 [[TODO: Update references once 3489bis 1717 is more stable]]. These attacks are based on the fact that a STUN 1718 server mirrors the source IP address, which cannot be authenticated. 1719 STUN does not use the source address of the Allocate Request in 1720 providing the RELAY-ADDRESS, and therefore, those attacks do not 1721 apply. 1723 The relay usage cannot be used by clients for subverting firewall 1724 policies. The relay usage has fairly limited applicability, 1725 requiring a user to send a packet to a peer before being able to 1726 receive a packet from that peer. This applies to both TCP and UDP. 1727 Thus, it does not provide a general technique for externalizing TCP 1728 and UDP sockets. Rather, it has similar security properties to the 1729 placement of an address-restricted NAT in the network, allowing 1730 messaging in from a peer only if the internal client has sent a 1731 packet out towards the IP address of that peer. This limitation 1732 means that the relay usage cannot be used to run web servers, email 1733 servers, SIP servers, or other network servers that service a large 1734 number of clients. Rather, it facilitates rendezvous of NATted 1735 clients that use some other protocol, such as SIP, to communicate IP 1736 addresses and ports for communications. 1738 Confidentiality of the transport addresses learned through Allocate 1739 requests does not appear to be that important, and therefore, this 1740 capability is not provided. 1742 Relay servers are useful even for users not behind a NAT. They can 1743 provide a way for truly anonymous communications. A user can cause a 1744 call to have its media routed through a STUN server, so that the 1745 user's IP addresses are never revealed. 1747 TCP transport addresses allocated by Allocate requests will properly 1748 work with TLS and SSL. However, any relay addresses learned through 1749 an Allcoate will not operate properly with IPSec Authentication 1750 Header (AH) [11] in transport mode. IPSec ESP [12] and any tunnel- 1751 mode ESP or AH should still operate. 1753 15. IANA Considerations 1755 TODO. 1757 16. IAB Considerations 1759 The IAB has studied the problem of ``Unilateral Self Address 1760 Fixing'', which is the general process by which a client attempts to 1761 determine its address in another realm on the other side of a NAT 1762 through a collaborative protocol reflection mechanism RFC 3424 [13]. 1763 TURN is an example of a protocol that performs this type of function. 1764 The IAB has mandated that any protocols developed for this purpose 1765 document a specific set of considerations. This section meets those 1766 requirements. 1768 16.1 Problem Definition 1770 >From RFC 3424 [13], any UNSAF proposal must provide: 1772 Precise definition of a specific, limited-scope problem that is to 1773 be solved with the UNSAF proposal. A short term fix should not be 1774 generalized to solve other problems; this is why "short term 1775 fixes usually aren't". 1777 The specific problem being solved by TURN is for a client, which may 1778 be located behind a NAT of any type, to obtain an IP address and port 1779 on the public Internet, useful for applications that require a client 1780 to place a transport address into a protocol message, with the 1781 expectation that the client will be able to receive packets from a 1782 single host that will send to this address. Both UDP and TCP are 1783 addressed. It is also possible to send packets so that the recipient 1784 sees a source address equal to the allocated address. TURN, by 1785 design, does not allow a client to run a server (such as a web or 1786 SMTP server) using a TURN address. TURN is useful even when NAT is 1787 not present, to provide anonymity services. 1789 16.2 Exit Strategy 1791 From [13], any UNSAF proposal must provide: 1793 Description of an exit strategy/transition plan. The better short 1794 term fixes are the ones that will naturally see less and less use 1795 as the appropriate technology is deployed. 1797 It is expected that TURN will be useful indefinitely, to provide 1798 anonymity services. When used to facilitate NAT traversal, TURN does 1799 not iself provide an exit strategy. That is provided by the 1800 Interactive Connectivity Establishment (ICE) [14] mechanism. ICE 1801 allows two cooperating clients to interactively determine the best 1802 addresses to use when communicating. ICE uses TURN-allocated 1803 addresses as a last resort, only when no other means of connectivity 1804 exists. As a result, as NATs phase out, and as IPv6 is deployed, ICE 1805 will increasingly use other addresses (host local addresses). 1806 Therefore, clients will allocate TURN addresses, but not use them, 1807 and therefore, de-allocate them. Servers will see a decrease in 1808 usage. Once a provider sees that its TURN servers are not being used 1809 at all (that is, no media flows through them), they can simply remove 1810 them. ICE will operate without TURN-allocated addresses. 1812 16.3 Brittleness Introduced by TURN 1814 From [13], any UNSAF proposal must provide: 1816 Discussion of specific issues that may render systems more 1817 "brittle". For example, approaches that involve using data at 1818 multiple network layers create more dependencies, increase 1819 debugging challenges, and make it harder to transition. 1821 TURN introduces brittleness in a few ways. First, it adds another 1822 server element to any system, which adds another point of failure. 1823 TURN requires clients to demultiplex TURN packets and data based on 1824 hunting for a MAGIC-COOKIE in the TURN messages. It is possible 1825 (with extremely small probabilities) that this cookie could appear 1826 within a data stream, resulting in mis-classification. That might 1827 introduce errors into the data stream (they would appear as lost 1828 packets), and also result in loss of a binding. TURN relies on any 1829 NAT bindings existing for the duration of the bindings held by the 1830 TURN server. Neither the client nor the TURN server have a way of 1831 reliably determining this lifetime (STUN can provide a means, but it 1832 is heuristic in nature and not reliable). Therefore, if there is no 1833 activity on an address learned from TURN for some period, the address 1834 might become useless spontaneously. 1836 TURN will result in potentially significant increases in packet 1837 latencies, and also increases in packet loss probabilities. That is 1838 because it introduces an intermediary on the path of a packet from 1839 point A to B, whose location is determined by application-layer 1840 processing, not underlying routing topologies. Therefore, a packet 1841 sent from one user on a LAN to another on the same LAN may do a trip 1842 around the world before arriving. When combined with ICE, some of 1843 the most problematic cases are avoided (such as this example) by 1844 avoiding the usage of TURN addresses. However, when used, this 1845 problem will exist. 1847 Note that TURN does not suffer from many of the points of brittleness 1848 introduced by STUN. TURN will work with all existing NAT types known 1849 at the time of writing, and for the forseeable future. TURN does not 1850 introduce any topological constraints. TURN does not rely on any 1851 heuristics for NAT type classification. 1853 16.4 Requirements for a Long Term Solution 1855 >From [13]}, any UNSAF proposal must provide: 1857 Identify requirements for longer term, sound technical solutions 1858 -- contribute to the process of finding the right longer term 1859 solution. 1861 Our experience with TURN continues to validate our belief in the 1862 requirements outlined in Section 14.4 of STUN. 1864 16.5 Issues with Existing NAPT Boxes 1866 >From [13], any UNSAF proposal must provide: 1868 Discussion of the impact of the noted practical issues with 1869 existing, deployed NA[P]Ts and experience reports. 1871 A number of NAT boxes are now being deployed into the market which 1872 try and provide "generic" ALG functionality. These generic ALGs hunt 1873 for IP addresses, either in text or binary form within a packet, and 1874 rewrite them if they match a binding. This usage avoids that problem 1875 by using the XOR-MAPPED-ADDRESS attribute instead of the MAPPED- 1876 ADDRESS 1878 17. Example 1880 In this example, a client is behind a NAT. The client has a private 1881 address of 10.0.1.1. The STUN server is on the public side of the 1882 NAT, and is listening for STUN relay requests on 192.0.2.3:8776. The 1883 public side of the NAT has an IP address of 192.0.2.1. The client is 1884 attempting to send a SIP INVITE to a peer, and wishes to allocate an 1885 IP address and port for inclusion in the SDP of the INVITE. 1886 Normally, TURN would be used in conjunction with ICE when applied to 1887 SIP. For simplicities sake, TURN is showed without ICE. 1889 The client communicates with a SIP user agent on the public network. 1890 This user agent uses a 192.0.2.17:12734 for receipt of its RTP 1891 packets. 1893 Client NAT STUN Server Peer 1894 | | | | 1895 |(1) Allocate | | | 1896 |S=10.0.1.1:4334 | | | 1897 |D=192.0.2.3:8776 | | | 1898 |------------------>| | | 1899 | | | | 1900 | |(2) Allocate | | 1901 | |S=192.0.2.1:63346 | | 1902 | |D=192.0.2.3:8776 | | 1903 | |------------------>| | 1904 | | | | 1905 | |(3) Error | | 1906 | |S=192.0.2.3:8776 | | 1907 | |D=192.0.2.1:63346 | | 1908 | |<------------------| | 1909 | | | | 1910 |(4) Error | | | 1911 |S=192.0.2.3:8776 | | | 1912 |D=10.0.1.1:4334 | | | 1913 |<------------------| | | 1914 | | | | 1915 |(5) Allocate | | | 1916 |S=10.0.1.1:4334 | | | 1917 |D=192.0.2.3:8776 | | | 1918 |------------------>| | | 1919 | | | | 1920 | |(6) Allocate | | 1921 | |S=192.0.2.1:63346 | | 1922 | |D=192.0.2.3:8776 | | 1923 | |------------------>| | 1924 | | | | 1925 | |(7) Response | | 1926 | |RA=192.0.2.3:32766 | | 1927 | |MA=192.0.2.1:63346 | | 1928 | |S=192.0.2.3:8776 | | 1929 | |D=192.0.2.1:63346 | | 1930 | |<------------------| | 1931 |(8) Response | | | 1932 |RA=192.0.2.3:32766 | | | 1933 |MA=192.0.2.1:63346 | | | 1934 |S=192.0.2.3:8776 | | | 1935 |D=10.0.1.1:4334 | | | 1936 |<------------------| | | 1937 | | | | 1938 | | | | 1939 |(9) INVITE | | | 1940 |SDP=192.0.2.3:32766| | | 1941 |---------------------------------------------------------->| 1942 | | | | 1943 | | | | 1944 |(10) 200 OK | | | 1945 |SDP=192.0.2.17:12734 | | 1946 |<----------------------------------------------------------| 1947 | | | | 1948 | | | | 1949 | | | | 1950 |(11) ACK | | | 1951 |---------------------------------------------------------->| 1952 | | | | 1953 |(12) Send | | | 1954 |DATA=RTP | | | 1955 |DA=192.0.2.17:12734| | | 1956 |S=10.0.1.1:4334 | | | 1957 |D=192.0.2.3:8776 | | | 1958 |------------------>| | | 1959 | | | | 1960 | |(13) Send | | 1961 | |DATA=RTP | | 1962 | |DA=192.0.2.17:12734| | 1963 | |S=192.0.2.1:63346 | | 1964 | |D=192.0.2.3:8776 | | 1965 | |------------------>| | 1966 | | | | 1967 | | |(14) RTP | 1968 | | |S=192.0.2.3:32766 | 1969 | | |D=192.0.2.17:12734 | 1970 | | |------------------>| 1971 | | | | 1972 | | |Permission | 1973 | | |Created | 1974 | | |192.0.2.17 | 1975 | | | | 1976 | | |(15) RTP | 1977 | | |S=192.0.2.17:12734 | 1978 | | |D=192.0.2.3:32766 | 1979 | | |<------------------| 1980 | | | | 1981 | |(16) DataInd | | 1982 | |DATA=RTP | | 1983 | |RA=192.0.2.17:12734| | 1984 | |S=192.0.2.3:8776 | | 1985 | |D=192.0.2.1:63346 | | 1986 | |<------------------| | 1987 |(17) DataInd | | | 1988 |DATA=RTP | | | 1989 |RA=192.0.2.17:12734| | | 1990 |S=192.0.2.3:8776 | | | 1991 |D=10.0.1.1:4334 | | | 1992 |<------------------| | | 1993 | | | | 1994 |(18) SetAct | | | 1995 |DA=192.0.2.17:12734| | | 1996 |S=10.0.1.1:4334 | | | 1997 |D=192.0.2.3:8776 | | | 1998 |------------------>| | | 1999 | | | | 2000 | |(19) SetAct | | 2001 | |DA=192.0.2.17:12734| | 2002 | |S=192.0.2.1:63346 | | 2003 | |D=192.0.2.3:8776 | | 2004 | |------------------>| | 2005 | | | | 2006 | |(20) Response | | 2007 | |S=192.0.2.3:8776 | | 2008 | |D=192.0.2.1:63346 | | 2009 | |<------------------| | 2010 | | | | 2011 |(21) Response | | | 2012 |S=192.0.2.3:8776 | | | 2013 |D=10.0.1.1:4334 | | | 2014 |<------------------| | | 2015 | | | | 2016 | | | | 2017 | | | after 3s| 2018 | | | | 2019 | | | | 2020 | | |(22) RTP | 2021 | | |S=192.0.2.17:12734 | 2022 | | |D=192.0.2.3:32766 | 2023 | | |<------------------| 2024 | | | | 2025 | |(23) RTP | | 2026 | |S=192.0.2.3:8776 | | 2027 | |D=192.0.2.1:63346 | | 2028 | |<------------------| | 2029 | | | | 2030 |(24) RTP | | | 2031 |S=192.0.2.3:8776 | | | 2032 |D=10.0.1.1:4334 | | | 2033 |<------------------| | | 2034 | | | | 2035 | | | | 2037 Figure 13 2039 The call flow is shown in Figure 13. The client allocates a port 2040 from the local operating system on its private interface, obtaining 2041 4334. It then attempts to secure a port for RTP traffic. RTCP 2042 processing is not shown. The client sends an Allocate request (1) 2043 with a source address (denoted by S) of 10.0.1.1:4334 and a 2044 destination (denoted by D) of 192.0.2.3:8776. This passes through 2045 the NAT (2), which creates a mapping from the 192.0.2.1:63346 to the 2046 source IP address and port of the request, 10.0.1.1:4334. This 2047 request is received at the STUN server, which challenges it (3), 2048 requesting credentials. This response is passed to the client (4). 2049 The client retries the request, this time with credentials (5). This 2050 arrives at the server (6). The request is now authenticated. The 2051 server provides a UDP allocation, 192.0.2.3:32766, and places it into 2052 the RELAY-ADDRESS (denoted by RA) in the response (7). It also 2053 reflects the source IP address and port of the request into the 2054 MAPPED-ADDRESS (denoted by MA) in the response. This passes through 2055 the NAT to the client (8). The client now proceeds to perform a 2056 basic SIP call setup. In message 9, it includes the relay address 2057 into the SDP of its INVITE. The called party responds with a 200 OK, 2058 and includes its IP address - 192.0.2.17:12734. The exchange 2059 completes with an ACK (11). 2061 Next, user A sends an RTP packet. Since the active destination has 2062 not been set, the client decides to use the Send indication. It does 2063 so, including the RTP packet as the contents of the DATA attribute. 2064 The REMOTE-ADDRESS attribute (denoted by DA) is set to 192.0.2.17: 2065 12734, learned from the 200 OK. This is sent through the NAT 2066 (message 12) and arrives at the STUN server (message 13). The server 2067 extracts the data contents, and sends the packet towards REMOTE- 2068 ADDRESS (message 14). Note how the source address and port in this 2069 packet is 192.0.2.3:32766, the allocated transport address given to 2070 the client. The act of sending the packet with Send causes the STUN 2071 server to install a permission for 192.0.2.17. 2073 Indeed, the called party now sends an RTP packet toward the client 2074 (message 15). This arrives at the STUN server. Since a permission 2075 has been set for the IP address in the source of this packet, it is 2076 accepted. As no active destination is set, the STUN server 2077 encapsulates the contents of the packet in a Data Indication (message 2078 16), and sends it towards the client. The REMOTE-ADDRESS attribute 2079 (denoted by RA) indicates the source of the packet - 192.0.2.17: 2080 12734. This is forwarded through the NAT to the client (message 17). 2082 The client decides to optimize the path for packets to and from 2083 192.0.2.17:12734. So, it issues a Set Active Destination request 2084 (message 18) with a REMOTE-ADDRESS of 192.0.2.17:12734. This passes 2085 through the NAT and arrives at the STUN server (message 19). This 2086 generates a successful response (message 20) which is passed to the 2087 client (message 21). At this point, the server and client are in the 2088 transitioning state. A little over 3 seconds later (by default), the 2089 state machines transition back to "Set". Until this point, packets 2090 from the called party would have been relayed back to the client in 2091 Data Indications. Now, the next RTP packet shows up at the STUN 2092 server (message 22). Since the source IP address and port match the 2093 active destination, the RTP packet is relayed towards the client 2094 without encapsulation (message 23 and 24). 2096 18. Acknowledgements 2098 The authors would like to thank Marc Petit-Huguenin for his comments 2099 and suggestions. 2101 19. References 2103 19.1 Normative References 2105 [1] Rosenberg, J., "Simple Traversal of UDP Through Network Address 2106 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-03 (work 2107 in progress), March 2006. 2109 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2110 Levels", BCP 14, RFC 2119, March 1997. 2112 [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2113 specifying the location of services (DNS SRV)", RFC 2782, 2114 February 2000. 2116 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2117 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 2118 Basic and Digest Access Authentication", RFC 2617, June 1999. 2120 19.2 Informative References 2122 [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2123 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2124 RFC 3550, July 2003. 2126 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2127 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2128 Session Initiation Protocol", RFC 3261, June 2002. 2130 [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2131 Session Description Protocol (SDP)", RFC 3264, June 2002. 2133 [8] Handley, M. and V. Jacobson, "SDP: Session Description 2134 Protocol", RFC 2327, April 1998. 2136 [9] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 2137 Protocol (RTSP)", RFC 2326, April 1998. 2139 [10] Senie, D., "Network Address Translator (NAT)-Friendly 2140 Application Design Guidelines", RFC 3235, January 2002. 2142 [11] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 2143 November 1998. 2145 [12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 2146 (ESP)", RFC 2406, November 1998. 2148 [13] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 2149 Address Fixing (UNSAF) Across Network Address Translation", 2150 RFC 3424, November 2002. 2152 [14] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 2153 Methodology for Network Address Translator (NAT) Traversal for 2154 Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in 2155 progress), March 2006. 2157 [15] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 2158 Unicast UDP", draft-ietf-behave-nat-udp-07 (work in progress), 2159 June 2006. 2161 Authors' Addresses 2163 Jonathan Rosenberg 2164 Cisco Systems 2165 600 Lanidex Plaza 2166 Parsippany, NJ 07054 2167 US 2169 Phone: +1 973 952-5000 2170 Email: jdrosen@cisco.com 2171 URI: http://www.jdrosen.net 2173 Rohan Mahy 2174 Plantronics 2176 Email: rohan@ekabal.com 2178 Christian Huitema 2179 Microsoft 2180 One Microsoft Way 2181 Redmond, WA 98052-6399 2182 US 2184 Email: huitema@microsoft.com 2186 Intellectual Property Statement 2188 The IETF takes no position regarding the validity or scope of any 2189 Intellectual Property Rights or other rights that might be claimed to 2190 pertain to the implementation or use of the technology described in 2191 this document or the extent to which any license under such rights 2192 might or might not be available; nor does it represent that it has 2193 made any independent effort to identify any such rights. Information 2194 on the procedures with respect to rights in RFC documents can be 2195 found in BCP 78 and BCP 79. 2197 Copies of IPR disclosures made to the IETF Secretariat and any 2198 assurances of licenses to be made available, or the result of an 2199 attempt made to obtain a general license or permission for the use of 2200 such proprietary rights by implementers or users of this 2201 specification can be obtained from the IETF on-line IPR repository at 2202 http://www.ietf.org/ipr. 2204 The IETF invites any interested party to bring to its attention any 2205 copyrights, patents or patent applications, or other proprietary 2206 rights that may cover technology that may be required to implement 2207 this standard. Please address the information to the IETF at 2208 ietf-ipr@ietf.org. 2210 Disclaimer of Validity 2212 This document and the information contained herein are provided on an 2213 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2214 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2215 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2216 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2217 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2218 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2220 Copyright Statement 2222 Copyright (C) The Internet Society (2006). This document is subject 2223 to the rights, licenses and restrictions contained in BCP 78, and 2224 except as set forth therein, the authors retain all their rights. 2226 Acknowledgment 2228 Funding for the RFC Editor function is currently provided by the 2229 Internet Society.