idnits 2.17.1 draft-ietf-behave-turn-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2332. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2008) is 5756 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) == Missing Reference: '0x4001' is mentioned on line 429, but not defined == Unused Reference: 'RFC3697' is defined on line 2201, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tsvwg-udp-guidelines' is defined on line 2249, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-15 ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) == Outdated reference: A later version (-07) exists of draft-ietf-behave-turn-tcp-00 == Outdated reference: A later version (-11) exists of draft-ietf-behave-turn-ipv6-04 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-08 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE WG J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track R. Mahy 5 Expires: December 26, 2008 Plantronics 6 P. Matthews 7 (Unaffiliated) 8 June 24, 2008 10 Traversal Using Relays around NAT (TURN): Relay Extensions to Session 11 Traversal Utilities for NAT (STUN) 12 draft-ietf-behave-turn-08 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 26, 2008. 39 Abstract 41 If a host is located behind a NAT, then in certain situations it can 42 be impossible for that host to communicate directly with other hosts 43 (peers) located behind other NATs. In these situations, it is 44 necessary for the host to use the services of an intermediate node 45 that acts as a communication relay. This specification defines a 46 protocol, called TURN (Traversal Using Relays around NAT), that 47 allows the host to control the operation of the relay and to exchange 48 packets with its peers using the relay. 50 The TURN protocol can be used in isolation, but is more properly used 51 as part of the ICE (Interactive Connectivity Establishment) approach 52 to NAT traversal. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.3. Exchanging Data with Peers . . . . . . . . . . . . . . . . 8 61 2.4. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 2.5. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11 63 2.6. Preserving vs. Non-Preserving Allocations . . . . . . . . 11 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 4. General Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 66 5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 16 68 6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 16 69 6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 17 70 6.3. Receiving an Allocate Response . . . . . . . . . . . . . . 21 71 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 23 72 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 23 73 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 23 74 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . . 24 75 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 9. Send and Data Indications . . . . . . . . . . . . . . . . . . 25 77 9.1. Sending a Send Indication . . . . . . . . . . . . . . . . 25 78 9.2. Receiving a Send Indication . . . . . . . . . . . . . . . 26 79 9.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . . 26 80 9.4. Receiving a Data Indication . . . . . . . . . . . . . . . 27 81 10. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 10.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 28 83 10.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 28 84 10.3. Receiving a ChannelBind Response . . . . . . . . . . . . . 29 85 10.4. The ChannelData Message . . . . . . . . . . . . . . . . . 29 86 10.5. Sending a ChannelData Message . . . . . . . . . . . . . . 30 87 10.6. Receiving a ChannelData Message . . . . . . . . . . . . . 30 88 10.7. Relaying . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 11. IP and ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 32 90 11.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 91 11.2. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 92 12. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . . 36 93 13. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 37 94 13.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . . 37 95 13.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 37 96 13.3. PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . . 37 97 13.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 98 13.5. RELAY-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 38 99 13.6. REQUESTED-PROPS . . . . . . . . . . . . . . . . . . . . . 38 100 13.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 38 101 13.8. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . . 39 102 14. New STUN Error Response Codes . . . . . . . . . . . . . . . . 39 103 15. Security Considerations . . . . . . . . . . . . . . . . . . . 40 104 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 105 17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 42 106 18. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 107 19. Changes from Previous Versions . . . . . . . . . . . . . . . . 42 108 19.1. Changed from -07 to -08 . . . . . . . . . . . . . . . . . 42 109 19.2. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 43 110 19.3. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 45 111 19.4. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 46 112 20. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 47 113 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 114 22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 115 22.1. Normative References . . . . . . . . . . . . . . . . . . . 48 116 22.2. Informative References . . . . . . . . . . . . . . . . . . 48 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 118 Intellectual Property and Copyright Statements . . . . . . . . . . 51 120 1. Introduction 122 Session Traversal Utilities for NAT (STUN) 123 [I-D.ietf-behave-rfc3489bis] provides a suite of tools for 124 facilitating the traversal of NAT. Specifically, it defines the 125 Binding method, which is used by a client to determine its reflexive 126 transport address towards the STUN server. The reflexive transport 127 address can be used by the client for receiving packets from peers, 128 but only when the client is behind "good" NATs. In particular, if a 129 client is behind a NAT whose mapping behavior [RFC4787] is address or 130 address and port dependent (sometimes called "bad" NATs), the 131 reflexive transport address will not be usable for communicating with 132 a peer. 134 The only reliable way to obtain a UDP transport address that can be 135 used for corresponding with a peer through such a NAT is to make use 136 of a relay. The relay sits on the public side of the NAT, and 137 allocates transport addresses to clients reaching it from behind the 138 private side of the NAT. These allocated transport addresses, called 139 relayed transport address, are IP addresses and ports on the relay. 140 When the relay receives a packet on one of these allocated addresses, 141 the relay forwards it toward the client. 143 This specification defines an extension to STUN, called TURN, that 144 allows a client to request a relayed transport address on a TURN 145 server. 147 Though a relayed transport address is highly likely to work when 148 corresponding with a peer, it comes at high cost to the provider of 149 the relay service. As a consequence, relayed transport addresses 150 should only be used as a last resort. Protocols using relayed 151 transport addresses should make use of mechanisms to dynamically 152 determine whether such an address is actually needed. One such 153 mechanism, defined for multimedia session establishment protocols 154 based on the offer/answer protocol in RFC 3264 [RFC3264], is 155 Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice]. 157 TURN was originally invented to support multimedia sessions signaled 158 using SIP. Since SIP supports forking, TURN supports multiple peers 159 per client; a feature not supported by other approaches (e.g., SOCKS 160 [RFC1928]). However, care has been taken in the later stages of its 161 development to make sure that TURN is suitable for other types of 162 applications. 164 2. Overview of Operation 166 This section gives an overview of the operation of TURN. It is non- 167 normative. 169 In a typical configuration, a TURN client is connected to a private 170 network [RFC1918] and through one or more NATs to the public 171 Internet. On the public Internet is a TURN server. Elsewhere in the 172 Internet are one or more peers that the TURN client wishes to 173 communicate with. These peers may or may not be behind one or more 174 NATs. 176 +---------+ 177 | | 178 | | 179 / | Peer A | 180 Client's TURN // | | 181 Host Transport Server / | | 182 Address Address +-+ // +---------+ 183 10.1.1.2:17240 192.0.2.15:3478 |N|/ 192.168.100.2:16400 184 | | |A| 185 | +-+ | /|T| 186 | | | | / +-+ 187 v | | | / 192.0.2.210:18200 188 +---------+ | | |+---------+ / +---------+ 189 | | |N| || | // | | 190 | TURN | | | v| TURN |/ | | 191 | Client |----|A|----------| Server |------------------| Peer B | 192 | | | |^ | |^ ^| | 193 | | |T|| | || || | 194 +---------+ | || +---------+| |+---------+ 195 | || | | 196 | || | | 197 +-+| | | 198 | | | 199 | | | 200 Client's | Peer B 201 Server-Reflexive Relayed Transport 202 Transport Address Transport Address Address 203 192.0.2.1:7000 192.0.2.15:9000 192.0.2.210:18200 205 Figure 1 207 Figure 1 shows a typical deployment. In this figure, the TURN client 208 and the TURN server are separated by a NAT, with the client on the 209 private side and the server on the public side of the NAT. This NAT 210 is assumed to be a "bad" NAT; for example, it might have a mapping 211 property of address-and-port-dependent mapping (see [RFC4787]) for a 212 description of what this means). 214 The client has allocated a local port on one of its addresses for use 215 in communicating with the server. The combination of an IP address 216 and a port is called a TRANSPORT ADDRESS and since this (IP address, 217 port) combination is located on the client and not on the NAT, it is 218 called the client's HOST transport address. 220 The client sends TURN messages from its host transport address to a 221 transport address on the TURN server which is known as the TURN 222 SERVER ADDRESS. The client learns the server's address through some 223 unspecified means (e.g., configuration), and this address is 224 typically used by many clients simultaneously. The TURN server 225 address is used by the client to send both commands and data to the 226 server; the commands are processed by the TURN server, while the data 227 is relayed on to the peers. 229 Since the client is behind a NAT, the server sees these packets as 230 coming from a transport address on the NAT itself. This address is 231 known as the client's SERVER-REFLEXIVE transport address; packets 232 sent by the server to the client's server-reflexive transport address 233 will be forwarded by the NAT to the client's host transport address. 235 The client uses TURN commands to allocate a RELAYED TRANSPORT 236 ADDRESS, which is an transport address located on the TURN server. 237 The server ensures that there is a one-to-one relationship between 238 the client's server-reflexive transport address and the relayed 239 transport address; thus a packet received at the relayed transport 240 address can be unambiguously relayed by the server to the client. 242 The client will typically communicate this relayed transport address 243 to one or more peers through some mechanism not specified here (e.g., 244 an ICE offer or answer [I-D.ietf-mmusic-ice]). Once this is done, 245 the client can send data to the server to relay towards its peers. 246 In the reverse direction, peers can send data to the the relayed 247 transport address of the client. The server will relay this data to 248 the client as long as the client explicitly created a permission (see 249 Section 2.5) for the IP address of the peer. 251 2.1. Transports 253 TURN as defined in this specification only allows the use of UDP 254 between the server and the peer. However, this specification allows 255 the use of any one of UDP, TCP, or TLS over TCP to carry the TURN 256 messages between the client and the server. 258 +----------------------------+---------------------+ 259 | TURN client to TURN server | TURN server to peer | 260 +----------------------------+---------------------+ 261 | UDP | UDP | 262 | TCP | UDP | 263 | TLS over TCP | UDP | 264 +----------------------------+---------------------+ 266 If TCP or TLS over TCP is used between the client and the server, 267 then the server will convert between stream transport and UDP 268 transport when relaying data. TURN allows both TCP and TLS over TCP 269 as transports in part because many firewalls are configured to not 270 pass any UDP traffic. 272 For TURN clients, using TLS over TCP to communicate with the TURN 273 server provides two benefits. First, the client can be assured that 274 the addresses of its peers are not visible to any attackers between 275 it and the server. Second, the client may be able to communicate 276 with TURN servers using TLS when it would not be able to communicate 277 with the same server using TCP or UDP, due to the policy of a 278 firewall between the TURN client and its server. In this second 279 case, TLS between the client and TURN server facilitates traversal. 281 There is a planned extension to TURN to add support for TCP between 282 the server and the peers [I-D.ietf-behave-turn-tcp]. For this 283 reason, allocations that use UDP between the server and the peers are 284 known as UDP allocations, while allocations that use TCP between the 285 server and the peers are known as TCP allocations. This 286 specification describes only UDP allocations. 288 2.2. Allocations 290 To allocate a relayed transport address, the client uses an Allocate 291 transaction. The client sends a Allocate Request to the server, and 292 the server replies with an Allocate Response containing the allocated 293 relayed transport address. The client can include attributes in the 294 Allocate Request that describe the type of allocation it desires 295 (e.g., the lifetime of the allocation). And since relaying data may 296 require lots of bandwidth, the server typically requires that the 297 client authenticate itself using STUN's long-term credential 298 mechanism, to show that it is authorized to use the server. 300 Once a relayed transport address is allocated, a client must keep the 301 allocation alive. To do this, the client periodically sends a 302 Refresh Request to the server with the allocated related transport 303 address. TURN deliberately uses a different method (Refresh rather 304 than Allocate) for refreshes to ensure that the client is informed if 305 the allocation vanishes for some reason. 307 The frequency of the Refresh transaction is determined by the 308 lifetime of the allocation. The client can request a lifetime in the 309 Allocate Request and may modify its request in a Refresh Request, and 310 the server always indicates the actual lifetime in the response. The 311 client must issue a new Refresh transaction within 'lifetime' seconds 312 of the previous Allocate or Refresh transaction. If a client no 313 longer wishes to use an Allocation, it should do a Refresh 314 transaction with a requested lifetime of 0. 316 Note that sending or receiving data from a peer DOES NOT refresh the 317 allocation. 319 The server keeps track of the client reflexive transport address and 320 port, the server transport address and port, and the protocol used by 321 the client to communicate with the server. (Together known as a 322 5-tuple. The server remembers the 5-tuple used in the Allocate 323 Request. Subsequent transactions between the client and the server 324 use this same 5-tuple. In this way, the server knows which client 325 owns the allocated relayed transport address. If the client wishes 326 to allocate a second relayed transport address, it must use a 327 different 5-tuple for this allocation (e.g., by using a different 328 client host address)., 330 While the terminology used in this document refers to 5-tuples, 331 the TURN server can store whatever identifier it likes that yields 332 identical results. Specifically, many implementations use a file- 333 descriptor in place of a 5-tuple to represent a TCP connection. 335 2.3. Exchanging Data with Peers 337 There are two ways for the client and peers to exchange data using 338 the TURN server. The first way uses Send and Data indications, the 339 second way uses channels. Common to both ways is the ability of the 340 client to communicate with multiple peers using a single allocated 341 relayed transport address; thus both ways include a means for the 342 client to indicate to the server which peer to forward the data to, 343 and for the server to indicate which peer sent the data. 345 When using the first way, the client sends a Send indication to the 346 TURN server containing, in attributes inside the indication, the 347 transport address of the peer and the data to be sent to that peer. 348 When the TURN server receives the Send Indication, it extracts the 349 data from the Send Indication and sends it in a UDP datagram to the 350 peer, using the allocated relay address as the source address. In 351 the reverse direction, UDP datagrams arriving at the relay address on 352 the TURN server are converted into Data Indications and sent to the 353 client, with the transport address of the peer included in an 354 attribute in the Data Indication. 356 TURN TURN Peer Peer 357 client server A B 358 |--- Allocate Req -->| | | 359 |<-- Allocate Resp ---| | | 360 | | | | 361 |--- Send (Peer A)--->| | | 362 | |=== data ===>| | 363 | | | | 364 | |<== data ====| | 365 |<-- Data (Peer A)----| | | 366 | | | | 367 |--- Send (Peer B)--->| | | 368 | |=== data =================>| 369 | | | | 370 | |<== data ==================| 371 |<-- Data (Peer B)----| | | 373 Figure 2 375 In the figure above, the client first allocates a relayed transport 376 address. It then sends data to Peer A using a Send Indication; at 377 the server, the data is extracted and forwarded in a UDP datagram to 378 Peer A, using the relayed transport address as the source transport 379 address. When a UDP datagram from Peer A is received at the relayed 380 transport address, the contents are placed into a Data Indication and 381 forwarded to the client. A similar exchange happens with Peer B. 383 2.4. Channels 385 For some applications (e.g. Voice over IP), the 36 bytes of overhead 386 that a Send or Data indication adds to the application data can 387 substantially increase the bandwidth required between the client and 388 the server. To remedy this, TURN offers a second way for the client 389 and server to associate data with a specific peer. 391 This second way uses an alternate packet format known as the 392 ChannelData message. The ChannelData message does not use the STUN 393 header used by other TURN messages, but instead has a 4-byte header 394 that includes a number known as a channel number. Each channel 395 number in use is bound to a specific peer and thus serves as a 396 shorthand for the peer's address. 398 To bind a channel to a peer, the client sends a ChannelBind request 399 to the server, and includes an unbound channel number and the 400 transport address of the peer. Once the channel is bound, the client 401 can use a ChannelData message to send the server data destined for 402 the peer. Similarly, the server can relay data from that peer 403 towards the client using a ChannelData message. 405 Channel bindings last for 10 minutes unless refreshed. Channel 406 bindings are refreshed by sending ChannelData messages from the 407 client to the server, or by rebinding the channel to the peer. 409 TURN TURN Peer Peer 410 client server A B 411 |--- Allocate Req -->| | | 412 |<-- Allocate Resp ---| | | 413 | | | | 414 |--- Send (Peer A)--->| | | 415 | |=== data ===>| | 416 | | | | 417 | |<== data ====| | 418 |<-- Data (Peer A)----| | | 419 | | | | 420 |- ChannelBind Req -->| | | 421 | (Peer A to 0x4001) | | | 422 | | | | 423 |<- ChannelBind Resp -| | | 424 | | | | 425 |-- [0x4001] data --->| | | 426 | |=== data ===>| | 427 | | | | 428 | |<== data ====| | 429 |<- [0x4001] data --->| | | 430 | | | | 431 |--- Send (Peer B)--->| | | 432 | |=== data =================>| 433 | | | | 434 | |<== data ==================| 435 |<-- Data (Peer B)----| | | 437 Figure 3 439 The figure above shows the channel mechanism in use. The client 440 begins by allocating a relayed transport address, and then uses that 441 address to exchange data with Peer A. After a bit, the client decides 442 to bind a channel to Peer A. To do this, it sends a ChannelBind 443 request to the server, specifying the transport address of Peer A and 444 a channel number (0x4001). After that, the client can send 445 application data encapsulated inside ChannelData messages to Peer A: 446 this is shown as "[0x4001] data" where 0x4001 is the channel number. 448 Note that ChannelData messages can only be used for peers to which 449 the client has bound a channel. In the example above, Peer A has 450 been bound to a channel, but Peer B has not, so application data to 451 and from Peer B uses Send and Data indications. 453 Channel bindings are always initiated by the client. 455 2.5. Permissions 457 To ease concerns amongst enterprise IT administrators that TURN could 458 be used to bypass corporate firewall security, TURN includes the 459 notion of permissions. TURN permissions mimic the address-restricted 460 filtering mechanism of NATs that comply with [RFC4787]. 462 The client can install a permission by sending data to a peer (or by 463 doing certain other things). Once a permission is installed, any 464 peer with the same IP address (the ports numbers can differ) is 465 permitted to send data to the client. After 5 minutes, the 466 permission times out and the server drops any UDP datagrams arriving 467 at the relayed transport from that IP address. Note that permissions 468 are within the context of an allocation, so adding or expiring a 469 permission in one allocation does not affect other allocations. 471 Data received from the peer DOES NOT refresh the permission. 473 2.6. Preserving vs. Non-Preserving Allocations 475 Some applications that use TURN are quite tolerant of the different 476 possible ways a TURN server could set the Diff-Serv, ECN, TTL / Hop 477 Limit, and Flow Label fields in the IP header of the outgoing packet. 478 Other applications require that the TURN server set these fields in a 479 specific way, and also require that the TURN server relay ICMP error 480 packets. Applications in the second class typically wish to do Path 481 MTU Discovery or end-to-end QOS. 483 Unfortunately, reading and manipulating fields in the IP header and 484 relaying ICMP messages usually requires the server to have special 485 permissions (e.g., access to RAW sockets or be loaded into the 486 kernel), something that the person setting up the server may be 487 unwilling or unable to grant. This is especially true when the 488 server is part of a larger application, for example a peer-to-peer 489 application. It is also significantly more difficult to implement 490 this type of server than just relaying at the UDP layer. 492 To allow TURN to cater to both usage scenarios, TURN defines the 493 concept of Preserving vs. Non-Preserving allocations. A Preserving 494 allocation sets the fields in outgoing IP header correctly, and also 495 relays ICMP messages, while a Non-Preserving allocation may not relay 496 correctly in every case. The relaying rules for a Preserving are 497 designed to guarantee the following: 499 o Path MTU Discovery works end-to-end (i.e. client-to-peer), using 500 either the old algorithm ([RFC1191] and [RFC1981]) or the new one 501 ([RFC4821]); 503 o ECN and Diff-Serv works end-to-end; 505 o Loops are prevented by copying and decrementing the TTL/Hop Count 506 field. 508 If the client knows its application or usage scenario requires a 509 Preserving allocation, then it can request one in its Allocate 510 request. If the server is unable to grant this request, then it 511 rejects the Allocate request. 513 Note that a Preserving allocation only makes sense when the transport 514 protocol to the client is UDP; when the transport is TCP or TLS, the 515 allocation is always Non-Preserving. 517 3. Terminology 519 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 520 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 521 document are to be interpreted as described in RFC 2119 [RFC2119]. 523 Readers are expected to be familar with [I-D.ietf-behave-rfc3489bis] 524 and the terms defined there. 526 The following terms are used in this document: 528 TURN: A protocol spoken between a TURN client and a TURN server. It 529 is an extension to the STUN protocol [I-D.ietf-behave-rfc3489bis]. 530 The protocol allows a client to allocate and use a relayed 531 transport address. 533 TURN client: A STUN client that implements this specification. 535 TURN server: A STUN server that implements this specification. It 536 relays data between a TURN client and its peer(s). 538 Peer: A host with which the TURN client wishes to communicate. The 539 TURN server relays traffic between the TURN client and its 540 peer(s). The peer does not interact with the TURN server using 541 the protocol defined in this document; rather, the peer receives 542 data sent by the TURN server and the peer sends data towards the 543 TURN server. 545 Host Transport Address: A transport address allocated on a host. 547 Server-Reflexive Transport Address: A transport address on the 548 "public side" of a NAT. This address is allocated by the NAT to 549 correspond to a specific host transport address. 551 Relayed Transport Address: A transport address that exists on a TURN 552 server. If a permission exists, packets that arrive at this 553 address are relayed towards the TURN client. 555 Allocation: The relayed transport address granted to a client 556 through an Allocate request, along with related state, such as 557 permissions and expiration timers. 559 5-tuple: The combination (client IP address and port, server IP 560 address and port, and transport protocol (UDP or TCP)) used to 561 communicate between the client and the server . The 5-tuple 562 uniquely identifies this communication stream. The 5-tuple also 563 uniquely identifies the Allocation on the server. 565 Permission: The IP address and transport protocol (but not the port) 566 of a peer that is permitted to send traffic to the TURN server and 567 have that traffic relayed to the TURN client. The TURN server 568 will only forward traffic to its client from peers that match an 569 existing permission. 571 Preserving Allocation An allocation that sets the the fields in the 572 IP header in a specific manner when relaying application data, and 573 which also relays ICMP messages. An allocation that may not do 574 this in some cases is called a Non-Preserving allocation. 576 4. General Behavior 578 This section contains general TURN processing rules that apply to all 579 TURN messages. 581 TURN is an extension to STUN. All TURN messages, with the exception 582 of the ChannelData message, are STUN-formatted messages. All the 583 base processing rules described in [I-D.ietf-behave-rfc3489bis] apply 584 to STUN-formatted messages. This means that all the message-forming 585 and -processing descriptions in this document are implicitly prefixed 586 with the rules of [I-D.ietf-behave-rfc3489bis]. 588 In addition, the server SHOULD require that all TURN requests use the 589 Long-Term Credential mechanism described in 590 [I-D.ietf-behave-rfc3489bis], and the client MUST be prepared to 591 authenticate requests if required. The server's administrator MUST 592 choose a realm value that will uniquely identify the username and 593 password combination that the client must use, even if the client 594 uses multiple servers under different administrations. The server's 595 administrator MAY choose to allocate a unique username to each 596 client, or MAY choose to allocate the same username to more than one 597 client (for example, to all clients from the same department or 598 company). 600 The client and/or the server MAY include the FINGERPRINT attribute in 601 any of the methods defined in this document. However, TURN does not 602 use the backwards-compatibility mechanism described in 603 [I-D.ietf-behave-rfc3489bis]. 605 By default, TURN runs on the same port as STUN. However, either the 606 SRV procedures or the ALTERNATE-SERVER procedures described in 607 Section 6 may be used to run TURN on a different port. 609 5. Allocations 611 All TURN operations revolve around allocations, and all TURN messages 612 are associated with an allocation. An allocation conceptually 613 consists of the following state data: 615 o the relayed transport address 617 o The 5-tuple: client IP address, client port, server IP address, 618 server port, transport protocol 620 o the username 622 o the transaction ID of the Allocate request 624 o the time-to-expiry 626 o A list of permissions 628 o A list of channel to peer bindings 630 o A flag indicating whether or not the allocation is Preserving 632 The relayed transport address is the transport address allocated by 633 the server for communicating with peers, while the 5-tuple describes 634 the communication path between the client and the server. Both of 635 these MUST be unique across all allocations, so either one can be 636 used to uniquely identify the allocation. 638 When a TURN message arrives at the server from the client, the server 639 uses the 5-tuple in the message to identify the associated 640 allocation. For all TURN messages (including ChannelData) EXCEPT an 641 Allocate request, if the 5-tuple does not identify an existing 642 allocation, then the message MUST either be rejected with a 437 643 Allocation Mismatch error (if it is a request), or silently ignored 644 (if it is an indication or a ChannelData message). A client 645 receiving a 437 error response to a request other than Allocate MUST 646 assume the allocation no longer exists. 648 The username and password of the allocation is the username and 649 password of the authenticated Allocate request that creates the 650 allocation. Subsequent requests on an allocation use the same 651 username and password as those used to create the allocation, to 652 prevent attackers from hijacking the client's allocation. 653 Specifically, if the server requires the use of the Long-Term 654 Credential mechanism, and if a non-Allocate request passes 655 authentication under this mechanism, and if the 5-tuple identifies an 656 existing allocation, but the request does not use the same username 657 as used to create the allocation, then the request MUST be rejected 658 with a 438 (Wrong Credentials) error. 660 The transaction ID of the allocation is the transaction ID used in 661 the Allocate request. This is used to detect retransmissions of the 662 Allocate request over UDP (see Section 6.2 for details). 664 The time-to-expiry is the time in seconds left until the allocation 665 expires. Each Allocate or Refresh transaction sets this timer, which 666 then ticks down towards 0. By default, each Allocate or Refresh 667 transaction resets this timer to 600 seconds (10 minutes), but the 668 client can request a different value in the Allocate and Refresh 669 request. Allocations can only be refreshed using the Refresh 670 request; sending data to a peer does not refresh an allocation. When 671 an allocation expires, the state data associated with the allocation 672 is freed. However the server MUST ensure that neither the relayed 673 transport address nor the client reflexive transport address from the 674 5-tuple are re-used in other allocations until 2 minutes after the 675 allocation expires; this ensures that any messages that are in 676 transit when the allocation expires are gone before either of these 677 transport addresses are re-used. 679 The list of permissions is described in Section 8 and the list of 680 channels is described in Section 10. 682 The differences between a Preserving and a Non-Preserving allocation 683 are described in Section 11. 685 6. Creating an Allocation 687 An allocation on the server is created using an Allocate transaction. 689 6.1. Sending an Allocate Request 691 The client forms an Allocate request as follows. 693 The client first needs to pick a host transport address that the 694 server does not think is currently in use, or was recently in use. 695 The client SHOULD pick a currently-unused transport address on the 696 client's host (typically by allowing its OS to pick a currently- 697 unused port for a new socket). 699 The client needs to pick a transport protocol to use between the 700 client and the server. The transport protocol MUST be one of UDP, 701 TCP, or TLS over TCP. Since this specification only allows UDP 702 between the server and the peers, it is RECOMMENDED that the client 703 pick UDP unless it has a reason to use a different transport. One 704 reason to pick a different transport would be that the client 705 believes, either through configuration or by experiment, that it is 706 unable to contact any TURN server using UDP. See Section 2.1 for 707 more discussion. 709 The client must also pick a server transport address. Typically, 710 this is done by the client learning (perhaps through configuration) 711 one or more domain names for TURN servers. In this case, the client 712 uses the DNS procedures described in [I-D.ietf-behave-rfc3489bis], 713 but using an SRV service name of "turn" (or "turns" for TURN over 714 TLS) instead of "stun" (or "stuns"). For example, to find servers in 715 the example.com domain, the client performs a lookup for 716 '_turn._udp.example.com', '_turn._tcp.example.com', and 717 '_turns._tcp.example.com' if the client wants to communicate with the 718 server using UDP, TCP, or TLS over TCP, respectively. 720 The client MUST include a REQUESTED-TRANSPORT attribute in the 721 request. This attribute specifies the transport protocol between the 722 server and the peers (note that this is NOT the transport protocol 723 that appears in the 5-tuple). In this specification, the REQUESTED- 724 TRANSPORT type is always UDP. This attribute is included to allow 725 future extensions specify other protocols (e.g., 726 [I-D.ietf-behave-turn-tcp]). 728 If the client wishes the server to initialize the time-to-expire 729 field of the allocation to some value other the default lifetime, 730 then it MAY include a LIFETIME attribute specifying its desired 731 value. This is just a request, and the server may elect to use a 732 different value. Note that the server will ignore requests to 733 initialize the field to less tha the default value. 735 If the client required the allocation to satisfy certain properties, 736 then the client includes the REQUESTED-PROPS attribute. This 737 attribute is optional, and can be omitted if no special properties 738 are required. 740 Using the E and R bits in the REQUESTED-PROPS attribute, the client 741 can request: 743 o (E=1, R=0 ) That the server allocate a relayed transport address 744 with an even port number; OR 746 o (E=1, R=1) That the server reserve a pair of relayed transport 747 addresses with adjacent port numbers N and N+1, where N is even 748 and N+1 is odd, and then use port N for the current allocation. 749 In this case, the server returns a RESERVATION-TOKEN attribute in 750 the response which the client can then include in a subsequent 751 Allocate request to create an allocation with port number N+1. 753 Note that the client cannot request a pair of adjacent ports unless 754 it also requests that the lower numbered port be even. Thus the 755 combination (E=0, R=1) is not allowed. 757 Similarly, by setting the P bit to 1 in the REQUESTED-PROPS 758 attribute, the client can request that the server allocate a 759 Preserving allocation. 761 For all the various REQUESTED-PROPS flags, if the server cannot 762 satisfy the request, the Allocate request is rejected. 764 The client MAY also include a RESERVATION-TOKEN attribute in the 765 request to ask the server to use a previously reserved port for the 766 allocation. If the RESERVATION-TOKEN attribute is included, then the 767 client MUST either omit the REQUESTED-PROPS attribute or set E=0 and 768 R=0, since doing otherwise would make no sense. 770 Once constructed, the client sends the Allocate request on the 771 5-tuple. 773 6.2. Receiving an Allocate Request 775 When the server receives an Allocate request, it performs the 776 following checks: 778 1. The server checks the credentials of the request, as per the 779 Long-Term Credential mechanism of [I-D.ietf-behave-rfc3489bis]. 781 2. The server checks if the 5-tuple is currently in use by an 782 existing allocation, or was it in use by another allocation 783 within the last 2 minutes. If yes, then there are two sub-cases: 785 * If the transport protocol in the 5-tuple is UDP, and if the 786 5-tuple is currently in use by an existing allocation, and if 787 the transaction id of the request matches the transaction id 788 stored with the allocation, then the request is a 789 retransmission of the original request. The server replies 790 either with a stored copy of the original response, or with a 791 response rebuilt from the stored state data. If the server 792 chooses to rebuild the response, then (a) it need not parse 793 the request further, but can immediately start building a 794 success response, (b) the value of the LIFETIME attribute can 795 be set to the current value of the time-to-expire timer, and 796 (c) the server may need to include an extra field in the 797 allocation to store the token returned in a RESERVATION-TOKEN 798 attribute. 800 * Otherwise, the server rejects the request with a 437 801 (Allocation Mismatch) error. 803 NOTE: If the request includes credentials that are acceptable to 804 server, but the 5-tuple is already in use, then it is important 805 that the server reject the request with a 437 (Allocation 806 Mismatch) error rather than a 401 (Unauthorized) error. This 807 ensures that the client knows that the problem is with the 808 5-tuple, rather than (wrongly) believing that the problem lies 809 with its credentials. 811 3. The server checks if the request contain a REQUESTED-TRANPORT 812 attribute. If the REQUESTED-TRANSPORT attribute is not included 813 or is malformed, the server rejects the request with a 400 (Bad 814 Request) error. Otherwise, if the attribute is included but 815 specifies a protocol other that UDP, the server rejects the 816 request with a 422 (Unsupported Transport Protocol) error. 818 4. The server checks if the request contains a REQUESTED-PROPS 819 attribute. If yes, then the server checks that it understands 820 and can satisfy all the flags that are set to 1. If a flag is 821 not understood, or if the server cannot satisfy the request, then 822 the server rejects the request with a 508 (Insufficient Port 823 Capacity) error. Note that the combination (E=0, R=1) MUST be 824 treated as unsupported. 826 5. The server checks if the request contains a RESERVATION-TOKEN 827 attribute. If yes, and the request also contains a REQUESTED- 828 PROPS attribute, then the server rejectes the request with a 400 829 (Bad Request) error. Otherwise it checks to see if the token is 830 valid (i.e., the token is in range and has not expired, and the 831 corresponding relayed transport address is still available). If 832 the token is not valid for some reason, the server rejects the 833 request with a 508 (Insufficient Port Capacity) error. 835 6. At any point, the server MAY also choose to reject the request 836 with a 486 (Allocation Quota Reached) error if it feels the 837 client is trying to exceed some locally-defined allocation quota. 838 The server is free to define this allocation quota any way it 839 wishes, but SHOULD define it based on the username used to 840 authenticate the request, and not on the client's transport 841 address. 843 If the server rejects the request with one of the error codes 422 844 (Unsupported Transport Protocol), 486 (Allocation Quota Reached) or 845 508 (Insufficient Port Capacity), it MAY include an ALTERNATE-SERVER 846 attribute in the error response redirecting the client to another 847 server that it believes will accept the request. If the attribute is 848 included, the address MUST be from the same address family as the 849 server's transport address. Note that, if the attribute is included, 850 the client will try this alternate server before trying the other 851 servers given by the SRV procedures. 853 If all the checks pass, the server creates the allocation. The 854 5-tuple is set to the 5-tuple from the Allocate request, while the 855 list of permissions and the list of channels are initially empty. 857 When allocating a relayed transport address for the allocation, the 858 server MUST allocate an IP address from the same family (e.g, IPv4 859 vs. IPv6) as that on which the request was received (i.e., the 860 server's IP address in the 5-tuple for the allocation). 862 NOTE: An extension to TURN to allow an address from a different 863 address family is currently in progress 864 [I-D.ietf-behave-turn-ipv6]. 866 In addition, the server SHOULD only allocate ports from the range 867 49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]), 868 unless the TURN server application knows, through some means not 869 specified here, that other applications running on the same host as 870 the TURN server application will not be impacted by allocating ports 871 outside this range. This condition can often be satisfied by running 872 the TURN server application on a dedicated machine and/or by 873 arranging that any other applications on the machine allocate ports 874 before the TURN server application starts. In any case, the TURN 875 server SHOULD NOT allocate ports in the range 0 - 1023 (the Well- 876 Known Port range) to discourage clients from using TURN to run 877 standard services. 879 If the request contains a REQUESTED-PROPS attribute with the R flag 880 set, then the server looks for a pair of port numbers N and N+1 on 881 the same IP address, where N is even. Port N is used in the current 882 allocation, while the relayed transport address with port N+1 is 883 assigned a token and reserved for a future allocation. The server 884 MUST hold this reservation for at least 30 seconds, and MAY choose to 885 hold longer (e.g. until the allocation with port N expires). The 886 server then includes the token in a RESERVATION-TOKEN attribute in 887 the success response. 889 If the request contains a RESERVATION-TOKEN, the server uses the 890 previously-reserved transport address corresponding to the included 891 token (if it is still available). 893 The server determines the initial value of the time-to-expire field 894 as follows. If the request contains a LIFETIME attribute, and the 895 proposed lifetime value is greater than the default lifetime, and the 896 proposed lifetime value is otherwise acceptable to the server, then 897 the server uses that value. Otherwise, the server uses the default 898 value. It is RECOMMENDED that the server impose a maximum lifetime 899 of no more than 3600 seconds (1 hour). 901 NOTE: The time-to-expire is recomputed with each successful 902 Refresh request. Thus the value computed here applies only until 903 the first refresh. 905 Once the allocation is created, the server replies with a success 906 response. The success response contains: 908 o A RELAYED-ADDRESS attribute containing the relayed transport 909 address; 911 o A LIFETIME attribute containing the current value of the time-to- 912 expire timer; 914 o A RESERVATION-TOKEN attribute (if a second relayed transport 915 address was reserved). 917 o An XOR-MAPPED-ADDRESS attribute containing the client's IP address 918 and port (from the 5-tuple); 920 NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response 921 as a convenience to the client. TURN itself does not make use of 922 this value, but clients running ICE can often need this value and 923 can thus avoid having to do an extra Binding transaction with some 924 STUN server to learn it. 926 The response (either success or error) is sent back to the client on 927 the 5-tuple. 929 6.3. Receiving an Allocate Response 931 If the client receives a success response, then it MUST check that 932 the relayed transport address is in an address family that the client 933 understands and is prepared to deal with. This specification only 934 covers the case where the relayed transport address is of the same 935 address family as the client's transport address. If the relayed 936 transport address is not in an address family that the client is 937 prepared to deal with, then the client MUST delete the allocation 938 (Section 7) and MUST NOT attempt to create another allocation on that 939 server until it believes the mismatch has been fixed. 941 The IETF is currently considering mechanisms for transitioning 942 between IPv4 and IPv6 that could result in a client originating an 943 Allocate request over IPv4, but the request would arrive at the 944 server over IPv6, or vica-versa. Hence the importance of this 945 check. 947 Otherwise, the client creates its own copy of the allocation data 948 structure to track what is happening on the server. In particular, 949 the client needs to remember the actual lifetime received back from 950 the server, rather than the value sent to the server in the request. 951 The client must also remember the 5-tuple used for the request and 952 the username and password it used to authenticate the request to 953 ensure that it reuses them for subsequent messages. The client also 954 needs to track the channels and permissions it establishes on the 955 server. 957 The client will probably wish to send the relayed transport address 958 to peers (using some method not specified here) so the peers can 959 communicate with it. The client may also wish to use the server- 960 reflexive address it receives in the XOR-MAPPED-ADDRESS attribute in 961 its ICE processing. 963 If the client receives an error response, then the processing depends 964 on the actual error code returned: 966 o (Request timed out): There is either a problem with the server, or 967 a problem reaching the server with the chosen transport. The 968 client MAY choose to try again using a different transport (e.g., 969 TCP instead of UDP), or the client MAY try a different server. 971 o 400 (Bad Request): The server believes the client's request is 972 malformed for some reason. The client MAY notify the user or 973 operator and SHOULD NOT retry the same request with this server 974 until it believes the problem has been fixed. The client MAY try 975 a different server. 977 o 401 (Unauthorized): If the client has followed the procedures of 978 the Long-Term Credential mechanism and still gets this error, then 979 the server is not accepting the client's credentials. The client 980 SHOULD notify the user or operator and SHOULD NOT send any further 981 requests to this server until it believes the problem has been 982 fixed. The client MAY try a different server. 984 o 437 (Allocation Mismatch): This indicates that the client has 985 picked a 5-tuple which the server sees as already in use or which 986 was recently in use. One way this could happen is if an 987 intervening NAT assigned a mapped transport address that was 988 recently used by another allocation. The client SHOULD pick 989 another client transport address and retry the Allocate request 990 (using a different transaction id). The client SHOULD try three 991 different client transport addresses before giving up on this 992 server. Once the client gives up on the server, it SHOULD NOT try 993 to create another allocation on the server for 2 minutes. 995 o 438 (Wrong Credentials): The client should not receive this error 996 in response to a Allocate request. The client MAY notify the user 997 or operator and SHOULD NOT retry the same request with this server 998 until it believes the problem has been fixed. The client MAY try 999 a different server. 1001 o 442 (Unsupported Transport Address): The client should not receive 1002 this error in response to a request for a UDP allocation. The 1003 client MAY notify the user or operator and SHOULD NOT retry the 1004 same request with this server until it believes the problem has 1005 been fixed. The client MAY try a different server. 1007 o 486 (Allocation Quota Reached): The server is currently unable to 1008 create any more allocations with this username. The client SHOULD 1009 wait at least 1 minute before trying to create any more 1010 allocations on the server. The client MAY try a different server. 1012 o 508 (Insufficient Port Capacity): The server has no more relayed 1013 transport addresses avaiable, or has none with the requested 1014 properties, or the one that was reserved is no longer available. 1015 If the client is using either the REQUESTED-PROPS or the 1016 RESERVATION-TOKEN attribute, then the client MAY choose to remove 1017 this attribute and try again immediately. Otherwise, the client 1018 SHOULD wait at least 1 minute before trying to create any more 1019 allocations on this server. The client MAY try a different 1020 server. 1022 If the error response contains an ALTERNATE-SERVER attribute, and the 1023 client elects to try a different server, the the client SHOULD try 1024 the alternate server specified in that attribute (while obeying the 1025 rules in [I-D.ietf-behave-rfc3489bis] for avoiding redirection loops) 1026 before trying any other servers found using the SRV procedures of 1027 [I-D.ietf-behave-rfc3489bis]. 1029 7. Refreshing an Allocation 1031 A Refresh transaction can be used to either (a) refresh an existing 1032 allocation and update its time-to-expire, or (b) delete an existing 1033 allocation. 1035 If a client wishes to continue using an allocation, then the client 1036 MUST refresh it before it expires. It is suggested that the client 1037 refresh the allocation roughly 1 minute before it expires. If a 1038 client no longer wishes to use an allocation, then it SHOULD 1039 explicitly delete the allocation. A client MAY also change the time- 1040 to-expire of an allocation at any time for other reasons. 1042 7.1. Sending a Refresh Request 1044 If the client wishes to immediately delete an existing allocation, it 1045 includes a LIFETIME attribute with a value of 0. All other forms of 1046 the request refresh the allocation. 1048 The Refresh transaction updates the time-to-expire timer of an 1049 allocation. If the client wishes the server to set the time-to- 1050 expire timer to something other than the default lifetime, it 1051 includes a LIFETIME attribute with the requested value. The server 1052 then computes a new time-to-expire value in the same way as it does 1053 for an Allocate transaction, with the exception that a requested 1054 lifetime of 0 causes the server to immediately delete the allocation. 1056 The Refresh transaction is sent on the 5-tuple for the allocation. 1058 7.2. Receiving a Refresh Request 1060 When the server receives a Refresh request, it processes it as 1061 follows. If, during processing, an error in the request is detected 1062 (for example, a syntax error in the request which causes a 400 1063 error), then the request is rejected with an error response but the 1064 allocation is NOT deleted (but note that a 437 error will indicate 1065 that the allocation was not found). 1067 The server determines the new value for the time-to-expire field as 1068 follows. If the request contains a LIFETIME attribute, and the 1069 attribute value is 0, then the server uses a value of 0, which causes 1070 the allocation to expire. Otherwise, if the request contains a 1071 LIFETIME attribute and the attribute value is greater than the 1072 default lifetime, and the attribute value is otherwise acceptable to 1073 the server, then the server uses the attribute value. Otherwise, the 1074 server uses the default value. It is RECOMMENDED that the server 1075 impose a maximum lifetime of no more than 3600 seconds (1 hour). 1077 The server then constructs a success response containing: 1079 o A LIFETIME attribute containing the current value of the time-to- 1080 expire timer. 1082 The response is then sent on the 5-tuple. 1084 7.3. Receiving a Refresh Response 1086 If the client receives a success response to its Refresh request, it 1087 updates its copy of the allocation data structure with the time-to- 1088 expire value contained in the response. 1090 If the client receives an 437 (Allocation Mismatch) error response to 1091 its Refresh request, then it must consider the allocation as having 1092 expired, as described in Section 4. All other errors indicate a 1093 software error on the part of either the client or the server. 1095 8. Permissions 1097 For each allocation, the server keeps a list of zero or more 1098 permissions. Each permission consists an IP address which uniquely 1099 identifies the permission, and an associated time-to-expiry. The IP 1100 address describes a peer that is allowed to send data to the client, 1101 and the time-to-expiry is the number of seconds until the permission 1102 expires. 1104 Various events, as described in subsequent sections, can cause a 1105 permission for a given IP address to be installed or refreshed. This 1106 causes one of two things to happen: 1108 o If no permission for that IP address exists, then a permission is 1109 created with the given IP address and a time-to-expiry equal to 1110 the default permission lifetime. 1112 o If a permission for that IP address already exists, then the 1113 lifetime for that permission is reset to the default permission 1114 lifetime. 1116 The default permission lifetime MUST be 300 seconds (= 5 minutes). 1118 Each permission's time-to-expire decreases down once per second until 1119 it reaches 0, at which point the permission expires and is deleted. 1121 When a UDP datagram arrives at the relayed transport address for the 1122 allocation, the server checks the list of permissions for that 1123 allocation. If there is a permission with an IP address that is 1124 equal to the source IP address of the UDP datagram, then the UDP 1125 datagram can be relayed to the client. Otherwise, the UDP datagram 1126 is silently discarded. Note that only IP addresses are compared; 1127 port numbers are irrelevant. 1129 The permissions for one allocation are totally unrelated to the 1130 permissions for a different allocation. If an allocation expires, 1131 all its permissions expire with it. 1133 NOTE: Though TURN permissions expire after 5 minutes, many NATs 1134 deployed at the time of publication expire their UDP bindings 1135 considerably faster. Thus an application using TURN will probably 1136 wish to send some sort of keep-alive traffic at a much faster 1137 rate. Applications using ICE should follow the keep-alive 1138 guidelines of ICE [I-D.ietf-mmusic-ice], and applications not 1139 using ICE are advised to do something similar. 1141 9. Send and Data Indications 1143 TURN supports two ways to send and receive data from peers. This 1144 section describes the use of Send and Data indications, while 1145 Section 10 describes the use of the Channel Mechanism. 1147 9.1. Sending a Send Indication 1149 A client can use a Send Indication to pass data to the server for 1150 relaying to a peer. A client can also use a Send Indication without 1151 a DATA attribute to install or refresh a permission for the specified 1152 IP address. A client may use a Send indication to send data to a 1153 peer even if a channel is bound to that peer. 1155 When forming a Send Indication, the client MUST include a PEER- 1156 ADDRESS attribute and MAY include a DATA attribute. If the DATA 1157 attribute is included, then the DATA attribute contains the actual 1158 application data to be sent to the peer, and the PEER-ADDRESS 1159 attribute contains the transport address of the peer to which the 1160 data is to be sent. If the DATA attribute is not present, then the 1161 PEER-ADDRESS attribute contains the IP address for which a permission 1162 is to be installed or refreshed; in this case the port specified in 1163 the attribute is ignored. 1165 Note that no authentication attributes are included, since 1166 indications cannot be authenticated using the Long-Term Credential 1167 mechanism. 1169 The Send Indication MUST be sent using the same 5-tuple used for the 1170 original allocation. 1172 9.2. Receiving a Send Indication 1174 When the server receives a Send indication, it processes it as 1175 follows. 1177 If the received Send indication contains a DATA attribute, then it 1178 forms a UDP datagram as follows: 1180 o the source transport address is the relayed transport address of 1181 the allocation, where the allocation is determined by the 5-tuple 1182 on which the Send Indication arrived; 1184 o the destination transport address is taken from the PEER-ADDRESS 1185 attribute; 1187 o the data following the UDP header is the contents of the value 1188 field of the DATA attribute. 1190 The resulting UDP datagram is then sent to the peer. If any errors 1191 are detected during this process (e.g., the Send indication does not 1192 contain a PEER-ADDRESS attribute), the received indication is 1193 silently discarded and no UDP datagram is sent. 1195 When the server receives a valid Send Indication, either with or 1196 without a DATA attribute, it also installs or refreshes a permission 1197 for the IP address contained in the PEER-ADDRESS attribute (see 1198 Section 8). 1200 9.3. Receiving a UDP Datagram 1202 When the server receives a UDP datagram at a currently allocated 1203 relayed transport address, the server looks up the allocation 1204 associated with the relayed transport address. It then checks to see 1205 if relaying is permitted, as described in section Section 8). 1207 If relaying is permitted, and there is no channel bound to the peer 1208 that sent the UDP datagram (see ISection 10), then the server forms 1209 and sends a Data indication. The Data indication MUST contain both a 1210 PEER-ADDRESS and a DATA attribute. The DATA attribute is set to the 1211 value of the 'data octets' field from the datagram, and the PEER- 1212 ADDRESS attribute is set to the source transport address of the 1213 received UDP datagram. The Data indication is then sent on the 1214 5-tuple associated with the allocation. 1216 9.4. Receiving a Data Indication 1218 When the client receives a Data indication, it checks that the Data 1219 indication contains both a PEER-ADDRESS and a DATA attribute. It 1220 then delivers the data octets inside the DATA attribute to the 1221 application, along with an indication that they were received from 1222 the peer whose transport address is given by the PEER-ADDRESS 1223 attribute. 1225 10. Channels 1227 Channels provide a way for the client and server to send application 1228 data using ChannelData messages, which have less overhead than Send 1229 and Data indications. 1231 Channel bindings are always initiated by the client. The client can 1232 bind a channel to a peer at any time during the lifetime of the 1233 allocation. The client may bind a channel to a peer before 1234 exchanging data with it, or after exchanging data with it (using Send 1235 and Data indications) for some time, or may choose never to bind a 1236 channel it. The client can also bind channels to some peers while 1237 not binding channels to other peers. 1239 Channel bindings are specific to an allocation, so that a binding in 1240 one allocation has no relationship to a binding in any other 1241 allocation. If an allocation expires, all its channel bindings 1242 expire with it. 1244 A channel binding consists of: 1246 o A channel number; 1248 o A transport address (of the peer); 1250 o A time-to-expiry timer. 1252 Within the context of an allocation, a channel binding is uniquely 1253 identified either by the channel number or by the transport address. 1254 Thus the same channel cannot be bound to two different transport 1255 addresses, nor can the same transport address be bound to two 1256 different channels. 1258 A channel binding last for 10 minutes unless refreshed. Refreshing 1259 the binding (by the server receiving either a ChannelBind request 1260 rebinding the channel to the same peer, or by the server receiving a 1261 ChannelData message on that channel) resets the time-to-expire timer 1262 back to 10 minutes. When the channel binding expires, the channel 1263 becomes unbound and available for binding to a different transport 1264 address. 1266 When binding a channel to a peer, the client SHOULD be prepared to 1267 receive ChannelData messages on the channel from the server as soon 1268 as it has sent the ChannelBind request. Over UDP, it is possible for 1269 the client to receive ChannelData messages from the server before it 1270 receives a ChannelBind success response. 1272 In the other direction, the client MAY elect to send ChannelData 1273 messages before receiving the ChannelBind success response. Doing 1274 so, however, runs the risk of having the ChannelData messages dropped 1275 by the server if the ChannelBind request does not succeed for some 1276 reason (e.g., packet lost if the request is sent over UDP, or the 1277 server being unable to fulfill the request). A client that wishes to 1278 be safe should either queue the data, or use Send indications until 1279 the channel binding is confirmed. 1281 10.1. Sending a ChannelBind Request 1283 A channel binding is created using a ChannelBind transaction. A 1284 channel binding can also be refreshed using a ChannelBind 1285 transaction. 1287 To initiate the ChannelBind transaction, the client forms a 1288 ChannelBind request. The channel to be bound is specified in a 1289 CHANNEL-NUMBER attribute, and the peer's transport address is 1290 specified in a PEER-ADDRESS attribute. Section 10.2 describes the 1291 restrictions on these attributes. 1293 Note that rebinding a channel to the same transport address that it 1294 is already bound to provides a way to refresh a channel binding 1295 without sending data to the peer. 1297 Once formed, the ChannelBind Request is sent using the 5-tuple for 1298 the allocation. 1300 10.2. Receiving a ChannelBind Request 1302 When the server receives a ChannelBind request, it checks the 1303 following: 1305 o The request contains both a CHANNEL-NUMBER and a PEER-ADDRESS 1306 attribute; 1308 o The channel number is in the range 0x4000 to 0xFFFE (inclusive); 1310 o The channel number is not currently bound to a different transport 1311 address (same transport address is OK); 1313 o The transport address is not currently bound to a different 1314 channel number. 1316 If any of these tests fail, the server replies with an error response 1317 with error code 400 "Bad Request". Otherwise, the ChannelBind 1318 request is valid and the server replies with a ChannelBind success 1319 response. 1321 If ChannelBind request is valid, then the server creates or refreshes 1322 the channel binding using the channel number in the CHANNEL-ADDRESS 1323 attribute and the transport address in the PEER-ADDRESS attribute. 1324 The server also installs or refreshes a permission for the IP address 1325 in the PEER-ADDRESS attribute. 1327 10.3. Receiving a ChannelBind Response 1329 When the client receives a successful ChannelBind response, it 1330 updates its data structures to record that the channel binding is now 1331 active. 1333 10.4. The ChannelData Message 1335 The ChannelData message is used to carry application data between the 1336 client and the server. It has the following format: 1338 0 1 2 3 1339 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 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Channel Number | Length | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | | 1344 / Application Data / 1345 / / 1346 | | 1347 | +-------------------------------+ 1348 | | 1349 +-------------------------------+ 1351 The Channel Number field specifies the number of the channel on which 1352 the data is traveling, and thus the address of the peer that is 1353 sending or is to receive the data. The channel number MUST be in the 1354 range 0x4000 - 0xFFFF, with channel number 0xFFFF being reserved for 1355 possible future extensions. 1357 Channel numbers 0x0000 - 0x3FFF cannot be used because bits 0 and 1 1358 are used to distinguish ChannelData messages from STUN-formatted 1359 messages (i.e., Allocate, Send, Data, ChannelBind, etc). STUN- 1360 formatted messages always have bits 0 and 1 as "00", while 1361 ChannelData messages use combinations "01", "10", and "11". 1363 The Length field specifies the length in bytes of the application 1364 data field (i.e., it does not include the size of the ChannelData 1365 header). Note that 0 is a valid length. 1367 The Application Data field carries the data the client is trying to 1368 send to the peer, or that the peer is sending to the client. 1370 10.5. Sending a ChannelData Message 1372 Once a client has bound a channel to a peer, then when the client has 1373 data to send to that peer it may use either a ChannelData message or 1374 a Send Indication; that is, the client is not obligated to use the 1375 channel when it exists and may freely intermix the two message types 1376 when sending data to the peer. The server, on the other hand, MUST 1377 use the ChannelData message if a channel has been bound to the peer. 1379 The fields of the ChannelData message are filled in as described in 1380 Section 10.4. 1382 Over stream transports, the ChannelData message MUST be padded to a 1383 multiple of four bytes in order to ensure the alignment of subsequent 1384 messages. The padding is not reflected in the length field of the 1385 ChannelData message, so the actual size of a ChannelData message 1386 (including padding) is (4 + Length) rounded up to the nearest 1387 multiple of 4. Over UDP, the padding is not required but MAY be 1388 included. 1390 The ChannelData message is then sent on the 5-tuple associated with 1391 the allocation. 1393 10.6. Receiving a ChannelData Message 1395 The receiver of the ChannelData message uses bits 0 and 1 to 1396 distinguish it from STUN-formatted messages, as described in 1397 Section 10.4. 1399 If the ChannelData message is received in a UDP datagram, and if the 1400 UDP datagram is too short to contain the claimed length of the 1401 ChannelData message (i.e., the UDP header length field value is less 1402 than the ChannelData header length field value + 4 + 8), then the 1403 message is silently discarded. 1405 If the ChannelData message is received over TCP or over TLS over TCP, 1406 then the actual length of the ChannelData message is as described in 1407 Section 10.5. 1409 If the ChannelData message is received on a channel which is not 1410 bound to any peer, then the message is silently discarded. 1412 10.7. Relaying 1414 When a server receives a ChannelData message, it first processes it 1415 as described in the previous section. If no errors are detected, it 1416 relays the application data to the peer by forming a UDP datagram as 1417 follows: 1419 o the source transport address is the relayed transport address of 1420 the allocation, where the allocation is determined by the 5-tuple 1421 on which the ChannelData message arrived; 1423 o the destination transport address is the transport address to 1424 which the channel is bound; 1426 o the data following the UDP header is the contents of the data 1427 field of the ChannelData message. 1429 The resulting UDP datagram is then sent to the peer. 1431 If the ChannelData message is valid, then the server refreshes the 1432 channel binding, and also installs or refreshes a permission for the 1433 IP address part of the transport address to which the UDP datagram is 1434 sent (see Section 8). 1436 In the other direction, when the server receives a UDP datagram on 1437 the relayed transport address associated with an allocation, then it 1438 first checks to see if it is permitted to relay the datagram. This 1439 check is done as described in Section 8. If relaying is permitted, 1440 then the server checks to see if there is a channel bound to the peer 1441 that sent the UDP datagram. If there is, then it SHOULD form and 1442 send a ChannelData message as described in Section 10.5. If no 1443 channel is bound to the peer, then it MUST form and send a Data 1444 indication as described in Section 9.3. 1446 11. IP and ICMP 1448 This section describes how the server sets various fields in the IP 1449 header when relaying between the client and the peer or vica-versa. 1450 It also describes how the server relays ICMP messages. The 1451 descriptions in this section apply: (a) when the server receives a 1452 Send indication or ChannelData message from the client and sends a 1453 UDP datagram to the peer, (b) when the server receives a UDP datagram 1454 on the relayed-transport address and sends a Data indication or 1455 ChannelData message to the client, or (c) when the server receives an 1456 ICMP message. This section does not apply when the server sends TURN 1457 control messages. 1459 The descriptions below have two parts: a preferred behavior and an 1460 alternate behavior. A Preserving allocation MUST implement the 1461 preferred behavior. A non-preserving allocation with UDP transport 1462 to the client SHOULD implement the preferred behavior, but if that is 1463 not possible for a particular field, then it SHOULD implement the 1464 alternative behavior. A non-preserving allocation with TCP or TLS 1465 transport to client SHOULD implement the alternate behavior, except 1466 where this conflicts with standard TCP or TLS behavior. 1468 11.1. IP 1470 This section describes the preferred and alternate behavior for 1471 various fields in the IP header. 1473 Time to Live (IPv4) or Hop Count (IPv6) 1475 Preferred Behavior: If the incoming value is 0, then send an ICMP 1476 Time Exceeded message back to the sender. Otherwise set the 1477 outgoing Time to Live/Hop Count to one less than the incoming 1478 value. 1480 Alternate Behavior: Set the outgoing value to the default for 1481 outgoing packets. 1483 Diff-Serv Code Point 1485 Preferred Behavior: Set the outgoing value to the incoming value, 1486 unless the server, though configuration or other means, believes 1487 that a different setting is more appropriate. 1489 Alternate Behavior: Set the outgoing value to Best Effort, unless 1490 the server, through configuration or other means, believes a 1491 different setting is more appropriate. 1493 ECN 1495 Preferred Behavior: Set the outgoing value to the incoming value, 1496 UNLESS the server is doing Active Queue Management, the incoming 1497 ECN field is 01 or 10, and the server wishes to indicate that 1498 congestion has been experienced, in which case set the outgoing 1499 value to 11. 1501 Alternate Behavior: Set the outgoing value to 00 (ECN not 1502 supported) 1504 Flow Label 1506 Preferred Behavior: Set the outgoing flow label to 0. 1508 Alternate Behavior: Same as the Preferred behavior. 1510 IPv4 Fragmentation 1512 Preferred Behavior: 1514 If the outgoing packet size does not exceed the outgoing link's 1515 MTU, then send the outgoing packet unfragmented. Set the DF 1516 bit in the outgoing packet to the value of the DF bit in the 1517 incoming packet, and set the other fragmentation fields 1518 (Identification, MF, Fragment Offset) as appropriate for a 1519 packet originating from the server. 1521 Otherwise, if the outgoing link's MTU is exceeded and the 1522 incoming DF bit is 0, then fragment the packet before sending. 1523 Set the outgoing DF to 0, and set the other fragmentation 1524 fields as appropriate for fragments originated from the server. 1526 Otherwise [link MTU exceeded and incoming DF set], drop the 1527 outgoing packet and send an ICMP message of type 3 code 4 1528 ("fragmentation needed and DF set") to the sender of the 1529 incoming packet. 1531 Alternate Behavior: As described in the Preferred Behavior, except 1532 always assume the incoming DF bit is 0. 1534 IPv6 Fragmentation 1536 Preferred Behavior: 1538 If the incoming packet did not include a Fragmentation header 1539 and the outgoing packet size does not exceed the outgoing 1540 link's MTU, then send the outgoing packet without a 1541 Fragmentation header. 1543 If the incoming packet included a Fragment header and if the 1544 outgoing packet size (with a Fragmentation header included) 1545 does not exceed the outgoing link's MTU, then send the outgoing 1546 packet with a Fragmentation header. Set the fields of the 1547 Fragmentation header as appropriate for a packet originating 1548 from the server. 1550 If the incoming packet did not include a Fragmentation header 1551 and the outgoing packet size exceeds the outgoing link's MTU , 1552 then drop the outgoing packet and send an ICMP message of type 1553 2 code 0 ("Packet too big") to the sender of the incoming 1554 packet. If the packet is being sent to the peer, then reduce 1555 the MTU reported in the ICMP message by 48 bytes to allow room 1556 for the overhead of a Data indication. 1558 Otherwise, if the link's MTU is exceeded and the incoming 1559 packet contained a Fragmentation header, then fragment the 1560 outgoing packet into fragments of no more than 1280 bytes. Set 1561 the fields of the Fragmentation header as appropriate for a 1562 packet originating from the server. 1564 Alternate Behavior: As described in the Preferred Behavior, except 1565 always assume incoming packet has a Fragmentation header. 1567 IPv4 Options 1569 Preferred Behavior: The outgoing packet is sent without any IPv4 1570 options. 1572 Alternate Behavior: Same as preferred. 1574 IPv6 Extention Headers 1576 Preferred Behavior: The outgoing packet is sent without any IPv6 1577 extension headers, with the exception of the Fragmentation header 1578 as described above 1580 Alternate Behavior: Same as preferred. 1582 11.2. ICMP 1584 This sub-section describes the preferred behavior of ICMP relaying. 1585 The corresponding alternate behavior is to not relay ICMP messages. 1587 When an ICMP message arrives at the server, the copy of the original 1588 IP packet present inside the ICMP message is examined. The server 1589 first checks that the original IP packet header is immediately 1590 followed by a UDP protocol header, such that the original source 1591 transport address was X and the original destination transport 1592 address was Y. The server also checks that the type and code values 1593 in the ICMP header are one of those relayed (see below). Other ICMP 1594 messages are either ignored, or used by the server internally in an 1595 unspecified manner. 1597 The server then checks if one of the following two cases applies: 1599 Case 1: X is a relayed-transport-address currently assigned to an 1600 active allocation on the server, and there exists a permission for 1601 the IP address of Y in the allocation. 1603 In this case, the original IP packet was traveling from the server to 1604 a peer, so the the server relays the ICMP message back to the client. 1605 The server creates a Data indication where the PEER-ADDRESS attribute 1606 contains Y, and the ICMP attribute contains the type and code from 1607 the incoming ICMP message, and the DATA attribute contains 1608 application data from the original IP packet starting AFTER the UDP 1609 header. The server SHOULD include as much application data as 1610 possible consistent with not exceeding a total IP packet size of 1611 either 576 bytes (for IPv4) or 1280 bytes (for IPv6). 1613 Note that there is no point in including the original IP or UDP 1614 header in the DATA attribute because those headers were generated 1615 by the server, not the client. 1617 Case 2: There is an active allocation where X is the server transport 1618 address, Y is the client transport address, and UDP is used as 1619 transport between the client and the server. Furthermore, the packet 1620 after the UDP header is either (a) a ChannelData header which 1621 contains an active channel number in the allocation, or (b) a Data 1622 indication whose PEER-ADDRESS attribute contains an IP address for 1623 which there exists a permission in the allocation. 1625 In this case, the original IP packet was traveling from the server to 1626 the client, so the server creates and sends an ICMP message to the 1627 peer. The outgoing ICMP message contains the type and code fields 1628 from the incoming ICMP message and then contains an approximation to 1629 the original IP packet sent from the peer to the server (the one the 1630 server was trying to relay to the client inside the ChannelData or 1631 Data indication). This approximation contains a synthesized IP 1632 header, a synthesized UDP header, and some application data. The 1633 synthesis is done as follows: 1635 o The destination transport address is the relayed-transport-address 1636 of the allocation; 1638 o The source transport address is the peer's transport address 1639 determined from either (a) the channel number or (b) the PEER- 1640 ADDRESS attribute; 1642 o The application data is taken from either (a) the ChannelData 1643 message or (b) the DATA attribute. The server SHOULD include as 1644 much application data as possible consistent with not exceeding 1645 either 576 bytes (for IPv4) or 1280 bytes (for IPv6). 1647 The remaining fields in the IP and UDP headers are simply set to 1648 sensible values, since for most of them there is no way to 1649 reconstruct the original values. 1651 The server SHOULD relay as all ICMP type/code combinations and MUST 1652 relay at at least the following combinations. For IPv4: 1654 Type 3, code 4: Fragmentation needed and DF set 1656 For IPv6: 1658 Type 2, code : Packet too big 1660 12. New STUN Methods 1662 This section lists the codepoints for the new STUN methods defined in 1663 this specification. See elsewhere in this document for the semantics 1664 of these new methods. 1666 Request/Response Transactions 1667 0x003 : Allocate 1668 0x004 : Refresh 1669 0x009 : ChannelBind 1671 Indications 1672 0x006 : Send 1673 0x007 : Data 1675 13. New STUN Attributes 1677 This STUN extension defines the following new attributes: 1679 0x000C: CHANNEL-NUMBER 1680 0x000D: LIFETIME 1681 0x0010: Reserved (was BANDWIDTH) 1682 0x0012: PEER-ADDRESS 1683 0x0013: DATA 1684 0x0016: RELAY-ADDRESS 1685 0x0018: REQUESTED-PROPS 1686 0x0019: REQUESTED-TRANSPORT 1687 0x0022: RESERVATION-TOKEN 1689 13.1. CHANNEL-NUMBER 1691 The CHANNEL-NUMBER attribute contains the number of the channel. It 1692 is a 16-bit unsigned integer, followed by a two-octet RFFU (Reserved 1693 For Future Use) field which MUST be set to 0 on transmission and MUST 1694 be ignored on reception. 1696 0 1 2 3 1697 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 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 | Channel Number | RFFU = 0 | 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 13.2. LIFETIME 1704 The lifetime attribute represents the duration for which the server 1705 will maintain an allocation in the absence of a refresh. It is a 32- 1706 bit unsigned integral value representing the number of seconds 1707 remaining until expiration. 1709 13.3. PEER-ADDRESS 1711 The PEER-ADDRESS specifies the address and port of the peer as seen 1712 from the TURN server. It is encoded in the same way as XOR-MAPPED- 1713 ADDRESS. 1715 13.4. DATA 1717 The DATA attribute is present in all Data Indications and most Send 1718 Indications. It contains raw payload data that is to be sent (in the 1719 case of a Send Request) or was received (in the case of a Data 1720 Indication). 1722 13.5. RELAY-ADDRESS 1724 The RELAY-ADDRESS is present in Allocate responses. It specifies the 1725 address and port that the server allocated to the client. It is 1726 encoded in the same way as XOR-MAPPED-ADDRESS. 1728 13.6. REQUESTED-PROPS 1730 This attribute allows the client to request that the allocation have 1731 certain properties. The attribute is 32 bits long. Its format is: 1733 0 1 2 3 1734 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 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 |E|R|P| MUST be 0 | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 The first part of the attribute value contains a number of one-bit 1740 flags. These are: 1742 E: If 1, the port number for the relayed-transport-address must be 1743 even. If 0, the port number can be even or odd. 1745 R: If 1, the server must reserve the next highest port for a 1746 subsequent allocation. If 0, no such reservation is requested. 1747 If the client sets the R bit to 1, it MUST also set the E bit to 1 1748 (however, the E bit may be 1 when the R bit is 0). 1750 P: If 1, the allocation must be a Preserving allocation. If 0, the 1751 allocation can be either Preserving or Non-Preserving. 1753 All these flags have the property that if the bit is 1, and the 1754 server cannot create an allocation that satisfies the request, then 1755 the Allocate request is rejected. To allow future TURN extensions to 1756 define new flags that also have this property, the client MUST set 1757 the rest of the attribute to zero, and the server MUST fail the 1758 Allocate request if any bits which the server does not support are 1759 set to 1. By doing this, any new flags that are not recognized by 1760 the server will cause the Allocate request to fail. 1762 13.7. REQUESTED-TRANSPORT 1764 This attribute is used by the client to request a specific transport 1765 protocol for the allocated transport address. It has the following 1766 format: 1768 0 1 2 3 1769 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 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Protocol | RFFU | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 The Protocol field specifies the desired protocol. The codepoints 1775 used in this field are taken from those allowed in the Protocol field 1776 in the IPv4 header and the NextHeader field in the IPv6 header 1777 [Protocol-Numbers]. This specification only allows the use of 1778 codepoint 17 (User Datagram Protocol). 1780 The RFFU field MUST be set to zero on transmission and MUST be 1781 ignored on receiption. It is reserved for future uses. 1783 13.8. RESERVATION-TOKEN 1785 The RESERVATION-TOKEN attribute contains a token that uniquely 1786 identifies a relayed transport address being held in reserve by the 1787 server. The server includes this attribute in a success response to 1788 tell the client about the token, and the client includes this 1789 attribute in a subsequent Allocate request to request the server use 1790 that relayed transport address for the allocation. 1792 The attribute value is a 64-bit-long field containing the token 1793 value. 1795 14. New STUN Error Response Codes 1797 This document defines the following new error response codes: 1799 437 (Allocation Mismatch): A request was received by the server that 1800 requires an allocation to be in place, but there is none, or a 1801 request was received which requires no allocation, but there is 1802 one. 1804 438 (Wrong Credentials): The credentials in the (non-Allocate) 1805 request, though otherwise acceptable to the server, do not match 1806 those used to create the allocation. 1808 442 (Unsupported Transport Protocol): The Allocate request asked the 1809 server to use a transport protocol between the server and the peer 1810 that the server does not support. NOTE: This does NOT refer to 1811 the transport protocol used in the 5-tuple. 1813 486 (Allocation Quota Reached): No more allocations using this 1814 username can be created at the present time. 1816 508 (Insufficient Port Capacity): The server has no more relayed 1817 transport addresses available right now, or has none with the 1818 requested properties, or the one that corresponds to the specified 1819 token is not available. 1821 15. Security Considerations 1823 TURN servers allocate resources to clients, in contrast to the 1824 Binding method defined in [I-D.ietf-behave-rfc3489bis]. Therefore, a 1825 TURN server may require the authentication and authorization of STUN 1826 requests. This authentication is provided by mechanisms defined in 1827 the STUN specification itself, in particular digest authentication. 1829 Because TURN servers allocate resources, they can be susceptible to 1830 denial-of-service attacks. All Allocate transactions are 1831 authenticated, so that an unknown attacker cannot launch an attack. 1832 An authenticated attacker can generate multiple Allocate Requests, 1833 however. To prevent a single malicious user from allocating all of 1834 the resources on the server, it is RECOMMENDED that a server 1835 implement a per user limit on the number of allocations that can 1836 active at one time. Such a mechanism does not prevent a large number 1837 of malicious users from each requesting a small number of 1838 allocations. Attacks such as these are possible using botnets, and 1839 are difficult to detect and prevent. Implementors of TURN should 1840 keep up with best practices around detection of anomalous botnet 1841 attacks. 1843 A client will use the transport address learned from the RELAY- 1844 ADDRESS attribute of the Allocate Response to tell other users how to 1845 reach them. Therefore, a client needs to be certain that this 1846 address is valid, and will actually route to them. Such validation 1847 occurs through the message integrity checks provided in the Allocate 1848 response. They can guarantee the authenticity and integrity of the 1849 allocated addresses. Note that TURN is not susceptible to the 1850 attacks described in Section 12.2.3, 12.2.4, 12.2.5 or 12.2.6 of 1851 [I-D.ietf-behave-rfc3489bis] [[TODO: Update section number references 1852 to 3489bis]]. These attacks are based on the fact that a STUN server 1853 mirrors the source IP address, which cannot be authenticated. STUN 1854 does not use the source address of the Allocate Request in providing 1855 the RELAY-ADDRESS, and therefore, those attacks do not apply. 1857 TURN attempts to adhere as closely as possible to common firewall 1858 policies, consistent with allowing data to flow. TURN has fairly 1859 limited applicability, requiring a user to explicitly authorize 1860 permission to receive data from a peer, one IP address at a time. 1861 Thus, it does not provide a general technique for externalizing 1862 sockets. Rather, it has similar security properties to the placement 1863 of an address-restricted NAT in the network, allowing messaging in 1864 from a peer only if the internal client has sent a packet out towards 1865 the IP address of that peer. This limitation means that TURN cannot 1866 be used to run, for example, SIP servers, NTP servers, FTP servers or 1867 other network servers that service a large number of clients. 1868 Rather, it facilitates rendezvous of NATted clients that use some 1869 other protocol, such as SIP, to communicate IP addresses and ports 1870 for communications. 1872 Confidentiality of the transport addresses learned through Allocate 1873 transactions does not appear to be that important. If required, it 1874 can be provided by running TURN over TLS. 1876 TURN does not and cannot guarantee that UDP data is delivered in 1877 sequence or to the correct address. As most TURN clients will only 1878 communicate with a single peer, the use of a single channel number 1879 will be very common. Consider an enterprise where Alice and Bob are 1880 involved in separate calls through the enterprise NAT to their 1881 corporate TURN server. If the corporate NAT reboots, it is possible 1882 that Bob will obtain the exact NAT binding originally used by Alice. 1883 If Alice and Bob were using identical channel numbers, Bob will 1884 receive unencapsulated data intended for Alice and will send data 1885 accidentally to Alice's peer. This is not a problem with TURN. This 1886 is precisely what would happen if there was no TURN server and Bob 1887 and Alice instead provided a (STUN) reflexive transport address to 1888 their peers. If detecting this misdelivery is a problem, the client 1889 and its peer need to use message integrity on their data. 1891 Relay servers are useful even for users not behind a NAT. They can 1892 provide a way for truly anonymous communications. A user can cause a 1893 call to have its media routed through a TURN server, so that the 1894 user's IP addresses are never revealed. 1896 Any relay addresses learned through an Allocate request will not 1897 operate properly with IPSec Authentication Header (AH) [RFC4302] in 1898 transport or tunnel mode. However, tunnel-mode IPSec ESP [RFC4303] 1899 should still operate. 1901 16. IANA Considerations 1903 Since TURN is an extension to STUN [I-D.ietf-behave-rfc3489bis], the 1904 methods, attributes and error codes defined in this specification are 1905 new method, attributes, and error codes for STUN. This section 1906 directs IANA to add these new protocol elements to the IANA registry 1907 of STUN protocol elements. 1909 The codepoints for the new STUN methods defined in this specification 1910 are listed in Section 12. 1912 The codepoints for the new STUN attributes defined in this 1913 specification are listed in Section 13. 1915 The codepoints for the new STUN error codes defined in this 1916 specification are listed in Section 14. 1918 Extensions to TURN can be made through IETF consensus. 1920 17. IAB Considerations 1922 The IAB has studied the problem of "Unilateral Self Address Fixing", 1923 which is the general process by which a client attempts to determine 1924 its address in another realm on the other side of a NAT through a 1925 collaborative protocol reflection mechanism [RFC3424]. The TURN 1926 extension is an example of a protocol that performs this type of 1927 function. The IAB has mandated that any protocols developed for this 1928 purpose document a specific set of considerations. 1930 TURN is an extension of the STUN protocol. As such, the specific 1931 usages of STUN that use the TURN extensions need to specifically 1932 address these considerations. Currently the only STUN usage that 1933 uses TURN is ICE [I-D.ietf-mmusic-ice]. 1935 18. Example 1937 TBD 1939 19. Changes from Previous Versions 1941 Note to RFC Editor: Please remove this section prior to publication 1942 of this document as an RFC. 1944 This section lists the changes between the various versions of this 1945 specification. 1947 19.1. Changed from -07 to -08 1949 o Removed the BANDWIDTH attribute and all associated text (including 1950 error code 507 "Insufficient Bandwidth Capacity"), as the 1951 requirements for this feature were not clear and it was felt the 1952 feature could be easily added later. 1954 o Changed the format of the REQUESTED-PROPS attribute from a one- 1955 byte field to a set of bit flags. Changed the semantics of the 1956 unused portion of the value from RFFU to "MUST be 0" to give a 1957 more desirable behavior when new flags are defined. 1959 o Introduced the concept of Preserving vs. Non-Preserving 1960 allocations. As a result, completely revamped the rules for how 1961 to set the fields in the IP header, and added rules for relaying 1962 ICMP messages when the allocation is Preserving. 1964 19.2. Changes from -06 to -07 1966 o Rewrote the General Behavior section, making various changes in 1967 the process. 1969 o Changed the usage of authentication from MUST to SHOULD. 1971 o Changed the requirement that subsequent requests use the same 1972 username and password from MUST to SHOULD to allow for the 1973 possibility of changing the credentials using some unspecified 1974 mechanism. 1976 o Introduced a 438 (Wrong Credentials) error which is used when a 1977 non-Allocate request authenticates but does not use the same 1978 username and password as the Allocate request. Having a separate 1979 error code for this case avoids the client being confused over 1980 what the error actually is. 1982 o The server must now prevent the relayed transport address and the 1983 5-tuple from being reused in different allocations for 2 minutes 1984 after the allocation expires. 1986 o Changed the usage of FINGERPRINT from MUST NOT to MAY, to allow 1987 for the possible multiplexing of TURN with some other protocol. 1989 o Rewrote much of the section on Allocations, splitting it into 1990 three new sections (one on allocations in general, one on creating 1991 an allocation, and one on refreshing an allocation). 1993 o Replaced the mechanism for requesting relayed transport addresses 1994 with specific properties. The new mechanism is less powerful: a 1995 client can request an even port, or a pair of ports, but cannot 1996 request a single odd port or a specific port as was possible under 1997 the old mechanism. Nor can the client request a specific IP 1998 address. 2000 o Changed the rules for handling ALTERNATE-SERVER, removing the 2001 requirement that the referring server have "positive knowledge" 2002 about the state of the alternate server. The new rules instead 2003 rely on text in STUN to prevent referral loops. 2005 o Changed the rules for allocation lifetimes. Allocations lifetimes 2006 are now a minimum of 10 minutes; the client can ask for longer 2007 values, but requests for shorter values are ignored. The text now 2008 recommends that the client refresh an allocation one minute before 2009 it expires. 2011 o Put in temporary procedures for handling the BANDWIDTH attribute, 2012 modelled on the LIFETIME attribute. These procedures are mostly 2013 placeholders and likely to change in the next revision. 2015 o Added a detailed description of how a client reacts to the various 2016 errors it can receive in reply to an Allocate request. This 2017 replaces the various descriptions that were previously scattered 2018 throughout the document, which were inconsistent and sometimes 2019 contradictory. 2021 o Added a new section that gives the normative rules for 2022 permissions. 2024 o Changed the rules around permission lifetimes. The text used to 2025 recommend a value of one minute; it MUST now be 5 minutes. 2027 o Removed the errors "Channel Missing or Invalid", "Peer Address 2028 Missing or Invalid" and "Lifetime Malformed or Invalid" and used 2029 400 "Bad Request" instead. 2031 o Rewrote portions of the section on Send and Data indications and 2032 the section on Channels to try to make the client vs. server 2033 behavior clearer. 2035 o Channel bindings now expire after 10 minutes, and must be 2036 refreshed to keep them alive. 2038 o Binding a channel now installs or refreshes a permission for the 2039 IP address of corresponding peer. 2041 o Changed the wording describing the situation when the client sends 2042 a ChannelData message before receiving the ChannelBind success 2043 response. -06 said that client SHOULD NOT do this; -07 now says 2044 that a client MAY, but describes the consequences of doing it. 2046 o Added a section discussing the setting of fields in the IP header. 2048 o Replaced the REQUESTED-PORT-PROPS attribute with the REQUESTED- 2049 PROPS attribute that has a different format and semantics, but 2050 reuses the same code point. 2052 o Replaced the REQUESTED-IP attribute with the RESERVATION-TOKEN 2053 attribute, which has a different format and semantics, but reuses 2054 the same code point. 2056 o Removed error codes 443 and 444, and replaced them with 508 2057 (Insufficient Port Capacity). Also changed the error text for 2058 code 507 from "Insufficient Capacity" to "Insufficient Bandwidth 2059 Capacity". 2061 19.3. Changes from -05 to -06 2063 o Changed the mechanism for allocating channels to the one proposed 2064 by Eric Rescorla at the Dec 2007 IETF meeting. 2066 o Removed the framing mechanism (which was used to frame all 2067 messages) and replaced it with the ChannelData message. As part 2068 of this change, noted that the demux of ChannelData messages from 2069 TURN messages can be done using the first two bits of the message. 2071 o Rewrote the sections on transmitted and receiving data as a result 2072 of the above to changes, splitting it into a section on Send and 2073 Data Indications and a separate section on channels. 2075 o Clarified the handling of Allocate Request messages. In 2076 particular, subsequent Allocate Request messages over UDP with the 2077 same transaction id are not an error but a retransmission. 2079 o Restricted the range of ports available for allocation to the 2080 Dynamic and/or Private Port range, and noted when ports outside 2081 this range can be used. 2083 o Changed the format of the REQUESTED-TRANSPORT attribute. The 2084 previous version used 00 for UDP and 01 for TCP; the new version 2085 uses protocol numbers from the IANA protocol number registry. The 2086 format of the attribute also changed. 2088 o Made a large number of changes to the non-normative portion of the 2089 document to reflect technical changes and improve the 2090 presentation. 2092 o Added the Issues section. 2094 19.4. Changes from -04 to -05 2096 o Removed the ability to allocate addresses for TCP relaying. This 2097 is now covered in a separate document. However, communication 2098 between the client and the server can still run over TCP or TLS/ 2099 TCP. This resulted in the removal of the Connect method and the 2100 TIMER-VAL and CONNECT-STAT attributes. 2102 o Added the concept of channels. All communication between the 2103 client and the server flows on a channel. Channels are numbered 2104 0..65535. Channel 0 is used for TURN messages, while the 2105 remaining channels are used for sending unencapsulated data to/ 2106 from a remote peer. This concept adds a new Channel Confirmation 2107 method and a new CHANNEL-NUMBER attribute. The new attribute is 2108 also used in the Send and Data methods. 2110 o The framing mechanism formally used just for stream-oriented 2111 transports is now also used for UDP, and the former Type and 2112 Reserved fields in the header have been replaced by a Channel 2113 Number field. The length field is zero when running over UDP. 2115 o TURN now runs on its own port, rather than using the STUN port. 2116 The use of channels requires this. 2118 o Removed the SetActiveDestination concept. This has been replaced 2119 by the concept of channels. 2121 o Changed the allocation refresh mechanism. The new mechanism uses 2122 a new Refresh method, rather than repeating the Allocation 2123 transaction. 2125 o Changed the syntax of SRV requests for secure transport. The new 2126 syntax is "_turns._tcp" rather than the old "_turn._tls". This 2127 change mirrors the corresponding change in STUN SRV syntax. 2129 o Renamed the old REMOTE-ADDRESS attribute to PEER-ADDRESS, and 2130 changed it to use the XOR-MAPPED-ADDRESS format. 2132 o Changed the RELAY-ADDRESS attribute to use the XOR-MAPPED-ADDRESS 2133 format (instead of the MAPPED-ADDRESS format)). 2135 o Renamed the 437 error code from "No Binding" to "Allocation 2136 Mismatch". 2138 o Added a discussion of what happens if a client's public binding on 2139 its outermost NAT changes. 2141 o The document now consistently uses the term "peer" as the name of 2142 a remote endpoint with which the client wishes to communicate. 2144 o Rewrote much of the document to describe the new concepts. At the 2145 same time, tried to make the presentation clearer and less 2146 repetitive. 2148 20. Open Issues 2150 NOTE to RFC Editor: Please remove this section prior to publication 2151 of this document as an RFC. 2153 Bandwidth: How should bandwidth be specified? What are the right 2154 rules around bandwidth? 2156 Alternate Server: Do we still want this mechanism? Is the current 2157 proposal acceptable? Note that the usage of the ALTERNATE-SERVER 2158 attribute in this document is inconsistent with its usage in STUN. 2159 In STUN, if the ALTERNATE-SERVER attribute is used, then the error 2160 that the server would otherwise generate is replaced by a 300 (Try 2161 Alternate) code. In this document, the 300 error code is not used, 2162 and the server returns an appropriate error code and then includes 2163 the ALTERNATE-SERVER attribute in the response. In this way, the 2164 client can see the actual error code, rather than always seeing error 2165 code 300, and can thus make a more intelligent decision on whether it 2166 wishes to try the alternate server. 2168 Public TURN servers: The text currently says that a server "SHOULD" 2169 use the Long-Term Credential mechanism, with the unstated idea that a 2170 public TURN server would not use it. But this really weakens the 2171 security of TURN. Is there a better way to allow public servers? Or 2172 should we just drop the notion of a public server entirely? 2174 21. Acknowledgements 2176 The authors would like to thank the various participants in the 2177 BEHAVE working group for their many comments on this draft. Marc 2178 Petit-Huguenin, Remi Denis-Courmont, Derek MacDonald, Cullen 2179 Jennings, Lars Eggert, Magnus Westerlund, and Eric Rescorla have been 2180 particularly helpful, with Eric also suggesting the channel 2181 allocation mechanism, and Cullen suggesting the REQUESTED-PROPS 2182 mechanism. Christian Huitema was an early contributor to this 2183 document and was a co-author on the first few drafts. Finally, the 2184 authors would like to thank Dan Wing for both his contributions to 2185 the text and his huge help in restarting progress on this draft after 2186 work had stalled. 2188 22. References 2190 22.1. Normative References 2192 [I-D.ietf-behave-rfc3489bis] 2193 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2194 "Session Traversal Utilities for (NAT) (STUN)", 2195 draft-ietf-behave-rfc3489bis-15 (work in progress), 2196 February 2008. 2198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2199 Requirement Levels", BCP 14, RFC 2119, March 1997. 2201 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 2202 "IPv6 Flow Label Specification", RFC 3697, March 2004. 2204 22.2. Informative References 2206 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2207 E. Lear, "Address Allocation for Private Internets", 2208 BCP 5, RFC 1918, February 1996. 2210 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2211 for IP version 6", RFC 1981, August 1996. 2213 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2214 with Session Description Protocol (SDP)", RFC 3264, 2215 June 2002. 2217 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2218 December 2005. 2220 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2221 RFC 4303, December 2005. 2223 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 2224 Self-Address Fixing (UNSAF) Across Network Address 2225 Translation", RFC 3424, November 2002. 2227 [I-D.ietf-mmusic-ice] 2228 Rosenberg, J., "Interactive Connectivity Establishment 2229 (ICE): A Protocol for Network Address Translator (NAT) 2230 Traversal for Offer/Answer Protocols", 2231 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 2233 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2234 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2235 RFC 4787, January 2007. 2237 [I-D.ietf-behave-turn-tcp] 2238 Rosenberg, J. and R. Mahy, "Traversal Using Relays around 2239 NAT (TURN) Extensions for TCP Allocations", 2240 draft-ietf-behave-turn-tcp-00 (work in progress), 2241 November 2007. 2243 [I-D.ietf-behave-turn-ipv6] 2244 Camarillo, G. and O. Novo, "Traversal Using Relays around 2245 NAT (TURN) Extension for IPv4/IPv6 Transition", 2246 draft-ietf-behave-turn-ipv6-04 (work in progress), 2247 January 2008. 2249 [I-D.ietf-tsvwg-udp-guidelines] 2250 Eggert, L. and G. Fairhurst, "Guidelines for Application 2251 Designers on Using Unicast UDP", 2252 draft-ietf-tsvwg-udp-guidelines-08 (work in progress), 2253 June 2008. 2255 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2256 November 1990. 2258 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2259 Discovery", RFC 4821, March 2007. 2261 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 2262 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 2263 March 1996. 2265 [Port-Numbers] 2266 "IANA Port Numbers Registry", 2267 . 2269 [Protocol-Numbers] 2270 "IANA Protocol Numbers Registry", 2005, 2271 . 2273 Authors' Addresses 2275 Jonathan Rosenberg 2276 Cisco Systems, Inc. 2277 Edison, NJ 2278 USA 2280 Email: jdrosen@cisco.com 2281 URI: http://www.jdrosen.net 2282 Rohan Mahy 2283 Plantronics, Inc. 2285 Email: rohan@ekabal.com 2287 Philip Matthews 2288 (Unaffiliated) 2290 Fax: 2291 Email: philip_matthews@magma.ca 2292 URI: 2294 Full Copyright Statement 2296 Copyright (C) The IETF Trust (2008). 2298 This document is subject to the rights, licenses and restrictions 2299 contained in BCP 78, and except as set forth therein, the authors 2300 retain all their rights. 2302 This document and the information contained herein are provided on an 2303 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2304 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2305 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2306 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2307 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2308 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2310 Intellectual Property 2312 The IETF takes no position regarding the validity or scope of any 2313 Intellectual Property Rights or other rights that might be claimed to 2314 pertain to the implementation or use of the technology described in 2315 this document or the extent to which any license under such rights 2316 might or might not be available; nor does it represent that it has 2317 made any independent effort to identify any such rights. Information 2318 on the procedures with respect to rights in RFC documents can be 2319 found in BCP 78 and BCP 79. 2321 Copies of IPR disclosures made to the IETF Secretariat and any 2322 assurances of licenses to be made available, or the result of an 2323 attempt made to obtain a general license or permission for the use of 2324 such proprietary rights by implementers or users of this 2325 specification can be obtained from the IETF on-line IPR repository at 2326 http://www.ietf.org/ipr. 2328 The IETF invites any interested party to bring to its attention any 2329 copyrights, patents or patent applications, or other proprietary 2330 rights that may cover technology that may be required to implement 2331 this standard. Please address the information to the IETF at 2332 ietf-ipr@ietf.org.