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