idnits 2.17.1 draft-ietf-behave-turn-09.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 2593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2617. 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 (July 12, 2008) is 5766 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 452, but not defined == Unused Reference: 'RFC3697' is defined on line 2480, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tsvwg-udp-guidelines' is defined on line 2528, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-16 ** 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-09 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-01 Summary: 2 errors (**), 0 flaws (~~), 10 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: January 13, 2009 Plantronics 6 P. Matthews 7 (Unaffiliated) 8 July 12, 2008 10 Traversal Using Relays around NAT (TURN): Relay Extensions to Session 11 Traversal Utilities for NAT (STUN) 12 draft-ietf-behave-turn-09 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 13, 2009. 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 . . . . . . . . . . . . . . . . 9 61 2.4. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 2.5. Permissions . . . . . . . . . . . . . . . . . . . . . . . 12 63 2.6. Preserving vs. Non-Preserving Allocations . . . . . . . . 12 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 4. General Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 66 5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 6. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 17 68 6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 17 69 6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 18 70 6.3. Receiving an Allocate Response . . . . . . . . . . . . . . 23 71 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 25 72 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 25 73 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 26 74 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . . 27 75 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 27 76 9. Send and Data Indications . . . . . . . . . . . . . . . . . . 28 77 9.1. Sending a Send Indication . . . . . . . . . . . . . . . . 28 78 9.2. Receiving a Send Indication . . . . . . . . . . . . . . . 29 79 9.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . . 29 80 9.4. Receiving a Data Indication . . . . . . . . . . . . . . . 30 81 10. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 82 10.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 31 83 10.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 32 84 10.3. Receiving a ChannelBind Response . . . . . . . . . . . . . 32 85 10.4. The ChannelData Message . . . . . . . . . . . . . . . . . 32 86 10.5. Sending a ChannelData Message . . . . . . . . . . . . . . 33 87 10.6. Receiving a ChannelData Message . . . . . . . . . . . . . 34 88 10.7. Relaying Data from the Peer . . . . . . . . . . . . . . . 35 89 11. IP and ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 35 90 11.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 91 11.2. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 92 12. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . . 40 93 13. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 40 94 13.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . . 40 95 13.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 41 96 13.3. PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . . 41 97 13.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 98 13.5. RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 41 99 13.6. REQUESTED-PROPS . . . . . . . . . . . . . . . . . . . . . 41 100 13.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 42 101 13.8. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . . 42 102 13.9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 103 14. New STUN Error Response Codes . . . . . . . . . . . . . . . . 43 104 15. Security Considerations . . . . . . . . . . . . . . . . . . . 43 105 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 106 17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 45 107 18. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 108 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 46 109 20. Changes from Previous Versions . . . . . . . . . . . . . . . . 47 110 20.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 47 111 20.2. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 49 112 20.3. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 49 113 20.4. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 51 114 20.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 52 115 21. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 53 116 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 117 23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 118 23.1. Normative References . . . . . . . . . . . . . . . . . . . 54 119 23.2. Informative References . . . . . . . . . . . . . . . . . . 54 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 121 Intellectual Property and Copyright Statements . . . . . . . . . . 57 123 1. Introduction 125 Session Traversal Utilities for NAT (STUN) 126 [I-D.ietf-behave-rfc3489bis] provides a suite of tools for 127 facilitating the traversal of NAT. Specifically, it defines the 128 Binding method, which is used by a client to determine its reflexive 129 transport address towards the STUN server. The reflexive transport 130 address can be used by the client for receiving packets from peers, 131 but only when the client is behind "good" NATs. In particular, if a 132 client is behind a NAT whose mapping behavior [RFC4787] is address or 133 address and port dependent (sometimes called "bad" NATs), the 134 reflexive transport address will not be usable for communicating with 135 a peer. 137 The only reliable way to obtain a UDP transport address that can be 138 used for corresponding with a peer through such a NAT is to make use 139 of a relay. The relay sits on the public side of the NAT, and 140 allocates transport addresses to clients reaching it from behind the 141 private side of the NAT. These allocated transport addresses, called 142 relayed transport address, are IP addresses and ports on the relay. 143 When the relay receives a packet on one of these allocated addresses, 144 the relay forwards it toward the client. 146 This specification defines an extension to STUN, called TURN, that 147 allows a client to request a relayed transport address on a TURN 148 server. 150 Though a relayed transport address is highly likely to work when 151 corresponding with a peer, it comes at high cost to the provider of 152 the relay service. As a consequence, relayed transport addresses 153 should only be used as a last resort. Protocols using relayed 154 transport addresses should make use of mechanisms to dynamically 155 determine whether such an address is actually needed. One such 156 mechanism, defined for multimedia session establishment protocols 157 based on the offer/answer protocol in RFC 3264 [RFC3264], is 158 Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice]. 160 TURN was originally invented to support multimedia sessions signaled 161 using SIP. Since SIP supports forking, TURN supports multiple peers 162 per client; a feature not supported by other approaches (e.g., SOCKS 163 [RFC1928]). However, care has been taken in the later stages of its 164 development to make sure that TURN is suitable for other types of 165 applications. 167 2. Overview of Operation 169 This section gives an overview of the operation of TURN. It is non- 170 normative. 172 In a typical configuration, a TURN client is connected to a private 173 network [RFC1918] and through one or more NATs to the public 174 Internet. On the public Internet is a TURN server. Elsewhere in the 175 Internet are one or more peers that the TURN client wishes to 176 communicate with. These peers may or may not be behind one or more 177 NATs. 179 +---------+ 180 | | 181 | | 182 / | Peer A | 183 Client's TURN // | | 184 Host Transport Server / | | 185 Address Address +-+ // +---------+ 186 10.1.1.2:17240 192.0.2.15:3478 |N|/ 192.168.100.2:16400 187 | | |A| 188 | +-+ | /|T| 189 | | | | / +-+ 190 v | | | / 192.0.2.210:18200 191 +---------+ | | |+---------+ / +---------+ 192 | | |N| || | // | | 193 | TURN | | | v| TURN |/ | | 194 | Client |----|A|----------| Server |------------------| Peer B | 195 | | | |^ | |^ ^| | 196 | | |T|| | || || | 197 +---------+ | || +---------+| |+---------+ 198 | || | | 199 | || | | 200 +-+| | | 201 | | | 202 | | | 203 Client's | Peer B 204 Server-Reflexive Relayed Transport 205 Transport Address Transport Address Address 206 192.0.2.1:7000 192.0.2.15:9000 192.0.2.210:18200 208 Figure 1 210 Figure 1 shows a typical deployment. In this figure, the TURN client 211 and the TURN server are separated by a NAT, with the client on the 212 private side and the server on the public side of the NAT. This NAT 213 is assumed to be a "bad" NAT; for example, it might have a mapping 214 property of address-and-port-dependent mapping (see [RFC4787] for a 215 description of what this means). 217 The client has allocated a local port on one of its addresses for use 218 in communicating with the server. The combination of an IP address 219 and a port is called a TRANSPORT ADDRESS and since this (IP address, 220 port) combination is located on the client and not on the NAT, it is 221 called the client's HOST transport address. 223 The client sends TURN messages from its host transport address to a 224 transport address on the TURN server which is known as the TURN 225 SERVER ADDRESS. The client learns the server's address through some 226 unspecified means (e.g., configuration), and this address is 227 typically used by many clients simultaneously. The TURN server 228 address is used by the client to send both commands and data to the 229 server; the commands are processed by the TURN server, while the data 230 is relayed on to the peers. 232 Since the client is behind a NAT, the server sees these packets as 233 coming from a transport address on the NAT itself. This address is 234 known as the client's SERVER-REFLEXIVE transport address; packets 235 sent by the server to the client's server-reflexive transport address 236 will be forwarded by the NAT to the client's host transport address. 238 The client uses TURN commands to allocate a RELAYED TRANSPORT 239 ADDRESS, which is an transport address located on the TURN server. 240 The server ensures that there is a one-to-one relationship between 241 the client's server-reflexive transport address and the relayed 242 transport address; thus a packet received at the relayed transport 243 address can be unambiguously relayed by the server to the client. 245 The client will typically communicate this relayed transport address 246 to one or more peers through some mechanism not specified here (e.g., 247 an ICE offer or answer [I-D.ietf-mmusic-ice]). Once this is done, 248 the client can send data to the server to relay towards its peers. 249 In the reverse direction, peers can send data to the relayed 250 transport address of the client. The server will relay this data to 251 the client as long as the client explicitly created a permission (see 252 Section 2.5) for the IP address of the peer. 254 2.1. Transports 256 TURN as defined in this specification only allows the use of UDP 257 between the server and the peer. However, this specification allows 258 the use of any one of UDP, TCP, or TLS over TCP to carry the TURN 259 messages between the client and the server. 261 +----------------------------+---------------------+ 262 | TURN client to TURN server | TURN server to peer | 263 +----------------------------+---------------------+ 264 | UDP | UDP | 265 | TCP | UDP | 266 | TLS over TCP | UDP | 267 +----------------------------+---------------------+ 269 If TCP or TLS over TCP is used between the client and the server, 270 then the server will convert between these transports and UDP 271 transport when relaying data to/from the peer. 273 TURN supports TCP transport between the client and the server because 274 some firewalls are configured to block UDP entirely. These firewalls 275 block UDP but not TCP in part because TCP has properties that make 276 the intention of the nodes being protected by the firewall more 277 obvious to the firewall. For example, TCP has a three-way handshake 278 that makes in clearer that the protected node really wishes to have 279 that particular connection established, while for UDP the best the 280 firewall can do is guess which flows are desired by using filtering 281 rules. Also, TCP has explicit connection teardown, while for UDP the 282 firewall has to use timers to guess when the flow is finished 284 TURN supports TLS over TCP transport between the client and the 285 server because TLS provides additional security properties not 286 provided by TURN's default digest authentication; properties which 287 some clients may wish to take advantage of. In particular, TLS 288 provides a way for the client to ascertain that it is talking to the 289 server that it intended to, and also provides for confidentiality of 290 TURN control messages. TURN does not require TLS because the 291 overhead of using TLS is higher than that of digest authentication; 292 for example, using TLS likely means that most application data will 293 be doubly encrypted (once by TLS and once to ensure it is still 294 encrypted in the UDP datagram). 296 There is a planned extension to TURN to add support for TCP between 297 the server and the peers [I-D.ietf-behave-turn-tcp]. For this 298 reason, allocations that use UDP between the server and the peers are 299 known as UDP allocations, while allocations that use TCP between the 300 server and the peers are known as TCP allocations. This 301 specification describes only UDP allocations. 303 2.2. Allocations 305 To allocate a relayed transport address, the client uses an Allocate 306 transaction. The client sends a Allocate request to the server, and 307 the server replies with an Allocate response containing the allocated 308 relayed transport address. The client can include attributes in the 309 Allocate request that describe the type of allocation it desires 310 (e.g., the lifetime of the allocation). And since relaying data may 311 require lots of bandwidth, the server typically requires that the 312 client authenticate itself using STUN's long-term credential 313 mechanism, to show that it is authorized to use the server. 315 Once a relayed transport address is allocated, a client must keep the 316 allocation alive. To do this, the client periodically sends a 317 Refresh request to the server with the allocated related transport 318 address. TURN deliberately uses a different method (Refresh rather 319 than Allocate) for refreshes to ensure that the client is informed if 320 the allocation vanishes for some reason. 322 The frequency of the Refresh transaction is determined by the 323 lifetime of the allocation. The client can request a lifetime in the 324 Allocate request and may modify its request in a Refresh request, and 325 the server always indicates the actual lifetime in the response. The 326 client must issue a new Refresh transaction within 'lifetime' seconds 327 of the previous Allocate or Refresh transaction. If a client no 328 longer wishes to use an Allocation, it should do a Refresh 329 transaction with a requested lifetime of 0. 331 Note that sending or receiving data from a peer DOES NOT refresh the 332 allocation. 334 Both the server and the client keeps track of the client transport 335 address and port, the server transport address and port, and the 336 protocol used by the client to communicate with the server. These 5 337 values are collectively referred to as the 5-TUPLE. The server 338 remembers the 5-tuple used in the Allocate request. Subsequent 339 transactions between the client and the server use this same 5-tuple. 340 In this way, the server knows which client owns the allocated relayed 341 transport address. If the client wishes to allocate a second relayed 342 transport address, it must use a different 5-tuple for this 343 allocation (e.g., by using a different client host address or port)., 345 NOTE: While the terminology used in this document refers to 346 5-tuples, the TURN server can store whatever identifier it likes 347 that yields identical results. Specifically, many implementations 348 use a file-descriptor in place of a 5-tuple to represent a TCP 349 connection. 351 NOTE: In some applications of TURN, a client may send and receive 352 packets other than TURN packets on the address and port it is 353 using to communicate with the TURN server. This can happen, for 354 example, when using TURN with ICE [I-D.ietf-mmusic-ice]. In these 355 cases, the client can examine the 5-tuple for an arriving packet 356 and use the 5-tuple to distinguish packets received from the TURN 357 server from packets received from other nodes. 359 2.3. Exchanging Data with Peers 361 There are two ways for the client and peers to exchange data using 362 the TURN server. The first way uses Send and Data indications, the 363 second way uses channels. Common to both ways is the ability of the 364 client to communicate with multiple peers using a single allocated 365 relayed transport address; thus both ways include a means for the 366 client to indicate to the server which peer to forward the data to, 367 and for the server to indicate which peer sent the data. 369 When using the first way, the client sends a Send indication to the 370 TURN server containing, in attributes inside the indication, the 371 transport address of the peer and the data to be sent to that peer. 372 When the TURN server receives the Send indication, it extracts the 373 data from the Send indication and sends it in a UDP datagram to the 374 peer, using the allocated relay address as the source address. In 375 the reverse direction, UDP datagrams arriving at the relay address on 376 the TURN server are converted into Data indications and sent to the 377 client, with the transport address of the peer included in an 378 attribute in the Data indication. 379 TURN TURN Peer Peer 380 client server A B 381 |--- Allocate Req -->| | | 382 |<-- Allocate Resp ---| | | 383 | | | | 384 |--- Send (Peer A)--->| | | 385 | |=== data ===>| | 386 | | | | 387 | |<== data ====| | 388 |<-- Data (Peer A)----| | | 389 | | | | 390 |--- Send (Peer B)--->| | | 391 | |=== data =================>| 392 | | | | 393 | |<== data ==================| 394 |<-- Data (Peer B)----| | | 396 Figure 2 398 In the figure above, the client first allocates a relayed transport 399 address. It then sends data to Peer A using a Send indication; at 400 the server, the data is extracted and forwarded in a UDP datagram to 401 Peer A, using the relayed transport address as the source transport 402 address. When a UDP datagram from Peer A is received at the relayed 403 transport address, the contents are placed into a Data indication and 404 forwarded to the client. A similar exchange happens with Peer B. 406 2.4. Channels 408 For some applications (e.g. Voice over IP), the 36 bytes of overhead 409 that a Send or Data indication adds to the application data can 410 substantially increase the bandwidth required between the client and 411 the server. To remedy this, TURN offers a second way for the client 412 and server to associate data with a specific peer. 414 This second way uses an alternate packet format known as the 415 ChannelData message. The ChannelData message does not use the STUN 416 header used by other TURN messages, but instead has a 4-byte header 417 that includes a number known as a channel number. Each channel 418 number in use is bound to a specific peer and thus serves as a 419 shorthand for the peer's address. 421 To bind a channel to a peer, the client sends a ChannelBind request 422 to the server, and includes an unbound channel number and the 423 transport address of the peer. Once the channel is bound, the client 424 can use a ChannelData message to send the server data destined for 425 the peer. Similarly, the server can relay data from that peer 426 towards the client using a ChannelData message. 428 Channel bindings last for 10 minutes unless refreshed. Channel 429 bindings are refreshed by sending ChannelData messages from the 430 client to the server, or by rebinding the channel to the peer. 432 TURN TURN Peer Peer 433 client server A B 434 |--- Allocate Req -->| | | 435 |<-- Allocate Resp ---| | | 436 | | | | 437 |--- Send (Peer A)--->| | | 438 | |=== data ===>| | 439 | | | | 440 | |<== data ====| | 441 |<-- Data (Peer A)----| | | 442 | | | | 443 |- ChannelBind Req -->| | | 444 | (Peer A to 0x4001) | | | 445 | | | | 446 |<- ChannelBind Resp -| | | 447 | | | | 448 |-- [0x4001] data --->| | | 449 | |=== data ===>| | 450 | | | | 451 | |<== data ====| | 452 |<- [0x4001] data --->| | | 453 | | | | 454 |--- Send (Peer B)--->| | | 455 | |=== data =================>| 456 | | | | 457 | |<== data ==================| 458 |<-- Data (Peer B)----| | | 460 Figure 3 462 The figure above shows the channel mechanism in use. The client 463 begins by allocating a relayed transport address, and then uses that 464 address to exchange data with Peer A. After a bit, the client decides 465 to bind a channel to Peer A. To do this, it sends a ChannelBind 466 request to the server, specifying the transport address of Peer A and 467 a channel number (0x4001). After that, the client can send 468 application data encapsulated inside ChannelData messages to Peer A: 469 this is shown as "[0x4001] data" where 0x4001 is the channel number. 471 Note that ChannelData messages can only be used for peers to which 472 the client has bound a channel. In the example above, Peer A has 473 been bound to a channel, but Peer B has not, so application data to 474 and from Peer B uses Send and Data indications. 476 Channel bindings are always initiated by the client. 478 2.5. Permissions 480 To ease concerns amongst enterprise IT administrators that TURN could 481 be used to bypass corporate firewall security, TURN includes the 482 notion of permissions. TURN permissions mimic the address-restricted 483 filtering mechanism of NATs that comply with [RFC4787]. 485 The client can install a permission by sending data to a peer (or by 486 doing certain other things). Once a permission is installed, any 487 peer with the same IP address (the ports numbers can differ) is 488 permitted to send data to the client. After 5 minutes, the 489 permission times out and the server drops any UDP datagrams arriving 490 at the relayed transport from that IP address. Note that permissions 491 are within the context of an allocation, so adding or expiring a 492 permission in one allocation does not affect other allocations. 494 Data received from the peer DOES NOT refresh the permission. 496 2.6. Preserving vs. Non-Preserving Allocations 498 Some applications that use TURN are quite tolerant of the different 499 possible ways a TURN server could set the Diff-Serv, ECN, TTL / Hop 500 Limit, and Flow Label fields in the IP header of the outgoing packet. 501 Other applications require that the TURN server set these fields in a 502 specific way, and also require that the TURN server relay ICMP error 503 packets. Applications in the second class typically wish to do Path 504 MTU Discovery or end-to-end QOS. 506 Unfortunately, reading and manipulating fields in the IP header and 507 relaying ICMP messages usually requires the server to have special 508 permissions (e.g., access to RAW sockets or be loaded into the 509 kernel), something that the person setting up the server may be 510 unwilling or unable to grant. This is especially true when the 511 server is part of a larger application, for example a peer-to-peer 512 application. It is also significantly more difficult to implement 513 this type of server than just relaying at the UDP layer. 515 To allow TURN to cater to both usage scenarios, TURN defines the 516 concept of Preserving vs. Non-Preserving allocations. A Preserving 517 allocation sets the fields in the outgoing IP header correctly, and 518 also relays ICMP messages, while a Non-Preserving allocation may not 519 relay correctly in every case. The relaying rules for a Preserving 520 are designed to guarantee the following: 522 o Path MTU Discovery works end-to-end (i.e. client-to-peer), using 523 either the old algorithm ([RFC1191] and [RFC1981]) or the new one 524 ([RFC4821]); 526 o ECN and Diff-Serv works end-to-end; 528 o Loops are prevented by copying and decrementing the TTL/Hop Count 529 field. 531 If the client knows its application or usage scenario requires a 532 Preserving allocation, then it can request one in its Allocate 533 request. If the server is unable to grant this request, then it 534 rejects the Allocate request. 536 Note that a Preserving allocation only makes sense when the transport 537 protocol to the client is UDP; when the transport is TCP or TLS, the 538 allocation is always Non-Preserving. 540 3. Terminology 542 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 543 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 544 document are to be interpreted as described in RFC 2119 [RFC2119]. 546 Readers are expected to be familar with [I-D.ietf-behave-rfc3489bis] 547 and the terms defined there. 549 The following terms are used in this document: 551 TURN: A protocol spoken between a TURN client and a TURN server. It 552 is an extension to the STUN protocol [I-D.ietf-behave-rfc3489bis]. 553 The protocol allows a client to allocate and use a relayed 554 transport address. 556 TURN client: A STUN client that implements this specification. 558 TURN server: A STUN server that implements this specification. It 559 relays data between a TURN client and its peer(s). 561 Peer: A host with which the TURN client wishes to communicate. The 562 TURN server relays traffic between the TURN client and its 563 peer(s). The peer does not interact with the TURN server using 564 the protocol defined in this document; rather, the peer receives 565 data sent by the TURN server and the peer sends data towards the 566 TURN server. 568 Host Transport Address: A transport address allocated on a host. 570 Server-Reflexive Transport Address: A transport address on the 571 "public side" of a NAT. This address is allocated by the NAT to 572 correspond to a specific host transport address. 574 Relayed Transport Address: A transport address that exists on a TURN 575 server. If a permission exists, packets that arrive at this 576 address are relayed towards the TURN client. 578 Allocation: The relayed transport address granted to a client 579 through an Allocate request, along with related state, such as 580 permissions and expiration timers. 582 5-tuple: The combination (client IP address and port, server IP 583 address and port, and transport protocol (UDP or TCP)) used to 584 communicate between the client and the server . The 5-tuple 585 uniquely identifies this communication stream. The 5-tuple also 586 uniquely identifies the Allocation on the server. 588 Permission: The IP address and transport protocol (but not the port) 589 of a peer that is permitted to send traffic to the TURN server and 590 have that traffic relayed to the TURN client. The TURN server 591 will only forward traffic to its client from peers that match an 592 existing permission. 594 Preserving Allocation An allocation that sets the the fields in the 595 IP header in a specific manner when relaying application data, and 596 which also relays ICMP messages. An allocation that may not do 597 this in some cases is called a Non-Preserving allocation. 599 4. General Behavior 601 This section contains general TURN processing rules that apply to all 602 TURN messages. 604 TURN is an extension to STUN. All TURN messages, with the exception 605 of the ChannelData message, are STUN-formatted messages. All the 606 base processing rules described in [I-D.ietf-behave-rfc3489bis] apply 607 to STUN-formatted messages. This means that all the message-forming 608 and -processing descriptions in this document are implicitly prefixed 609 with the rules of [I-D.ietf-behave-rfc3489bis]. 611 In addition, the server SHOULD require that all TURN requests use the 612 Long-Term Credential mechanism described in 613 [I-D.ietf-behave-rfc3489bis], and the client MUST be prepared to 614 authenticate requests if required. The server's administrator MUST 615 choose a realm value that will uniquely identify the username and 616 password combination that the client must use, even if the client 617 uses multiple servers under different administrations. The server's 618 administrator MAY choose to allocate a unique username to each 619 client, or MAY choose to allocate the same username to more than one 620 client (for example, to all clients from the same department or 621 company). 623 The client and/or the server MAY include the FINGERPRINT attribute in 624 any of the methods defined in this document. The client and server 625 SHOULD include the SOFTWARE-TYPE attribute in all requests and 626 responses, but SHOULD NOT include it in Send and Data indications. 627 TURN does not use the backwards-compatibility mechanism described in 628 [I-D.ietf-behave-rfc3489bis]. 630 By default, TURN runs on the same port as STUN. However, either the 631 SRV procedures or the ALTERNATE-SERVER procedures described in 632 Section 6 may be used to run TURN on a different port. 634 5. Allocations 636 All TURN operations revolve around allocations, and all TURN messages 637 are associated with an allocation. An allocation conceptually 638 consists of the following state data: 640 o the relayed transport address 642 o The 5-tuple: client IP address, client port, server IP address, 643 server port, transport protocol 645 o the username 647 o the transaction ID of the Allocate request 649 o the time-to-expiry 651 o A list of permissions 653 o A list of channel to peer bindings 655 o A flag indicating whether or not the allocation is Preserving 657 The relayed transport address is the transport address allocated by 658 the server for communicating with peers, while the 5-tuple describes 659 the communication path between the client and the server. Both of 660 these MUST be unique across all allocations, so either one can be 661 used to uniquely identify the allocation. 663 When a TURN message arrives at the server from the client, the server 664 uses the 5-tuple in the message to identify the associated 665 allocation. For all TURN messages (including ChannelData) EXCEPT an 666 Allocate request, if the 5-tuple does not identify an existing 667 allocation, then the message MUST either be rejected with a 437 668 Allocation Mismatch error (if it is a request), or silently ignored 669 (if it is an indication or a ChannelData message). A client 670 receiving a 437 error response to a request other than Allocate MUST 671 assume the allocation no longer exists. 673 The username and password of the allocation is the username and 674 password of the authenticated Allocate request that creates the 675 allocation. Subsequent requests on an allocation use the same 676 username as that used to create the allocation, to prevent attackers 677 from hijacking the client's allocation. Specifically, if the server 678 requires the use of the Long-Term Credential mechanism, and if a non- 679 Allocate request passes authentication under this mechanism, and if 680 the 5-tuple identifies an existing allocation, but the request does 681 not use the same username as used to create the allocation, then the 682 request MUST be rejected with a 441 (Wrong Credentials) error. 684 The transaction ID of the allocation is the transaction ID used in 685 the Allocate request. This is used to detect retransmissions of the 686 Allocate request over UDP (see Section 6.2 for details). 688 The time-to-expiry is the time in seconds left until the allocation 689 expires. Each Allocate or Refresh transaction sets this timer, which 690 then ticks down towards 0. By default, each Allocate or Refresh 691 transaction resets this timer to 600 seconds (10 minutes), but the 692 client can request a different value in the Allocate and Refresh 693 request. Allocations can only be refreshed using the Refresh 694 request; sending data to a peer does not refresh an allocation. When 695 an allocation expires, the state data associated with the allocation 696 can be freed. However the server MUST ensure that neither the 697 relayed transport address nor the client reflexive transport address 698 from the 5-tuple are re-used in other allocations until 2 minutes 699 after the allocation expires; this ensures that any messages that are 700 in transit when the allocation expires are gone before either of 701 these transport addresses are re-used. 703 The list of permissions is described in Section 8 and the list of 704 channels is described in Section 10. 706 The differences between a Preserving and a Non-Preserving allocation 707 are described in Section 11. 709 6. Creating an Allocation 711 An allocation on the server is created using an Allocate transaction. 713 6.1. Sending an Allocate Request 715 The client forms an Allocate request as follows. 717 The client first needs to pick a host transport address that the 718 server does not think is currently in use, or was recently in use. 719 The client SHOULD pick a currently-unused transport address on the 720 client's host (typically by allowing its OS to pick a currently- 721 unused port for a new socket). 723 The client needs to pick a transport protocol to use between the 724 client and the server. The transport protocol MUST be one of UDP, 725 TCP, or TLS over TCP. Since this specification only allows UDP 726 between the server and the peers, it is RECOMMENDED that the client 727 pick UDP unless it has a reason to use a different transport. One 728 reason to pick a different transport would be that the client 729 believes, either through configuration or by experiment, that it is 730 unable to contact any TURN server using UDP. See Section 2.1 for 731 more discussion. 733 The client must also pick a server transport address. Typically, 734 this is done by the client learning (perhaps through configuration) 735 one or more domain names for TURN servers. In this case, the client 736 uses the DNS procedures described in [I-D.ietf-behave-rfc3489bis], 737 but using an SRV service name of "turn" (or "turns" for TURN over 738 TLS) instead of "stun" (or "stuns"). For example, to find servers in 739 the example.com domain, the client performs a lookup for 740 '_turn._udp.example.com', '_turn._tcp.example.com', and 741 '_turns._tcp.example.com' if the client wants to communicate with the 742 server using UDP, TCP, or TLS over TCP, respectively. 744 The client MUST include a REQUESTED-TRANSPORT attribute in the 745 request. This attribute specifies the transport protocol between the 746 server and the peers (note that this is NOT the transport protocol 747 that appears in the 5-tuple). In this specification, the REQUESTED- 748 TRANSPORT type is always UDP. This attribute is included to allow 749 future extensions specify other protocols (e.g., 750 [I-D.ietf-behave-turn-tcp]). 752 If the client wishes the server to initialize the time-to-expire 753 field of the allocation to some value other the default lifetime, 754 then it MAY include a LIFETIME attribute specifying its desired 755 value. This is just a request, and the server may elect to use a 756 different value. Note that the server will ignore requests to 757 initialize the field to less than the default value. 759 If the client required the allocation to satisfy certain properties, 760 then the client includes the REQUESTED-PROPS attribute. This 761 attribute is optional, and can be omitted if no special properties 762 are required. 764 Using the E and R bits in the REQUESTED-PROPS attribute, the client 765 can request: 767 o (E=1, R=0 ) That the server allocate a relayed transport address 768 with an even port number; OR 770 o (E=1, R=1) That the server reserve a pair of relayed transport 771 addresses with adjacent port numbers N and N+1, where N is even 772 and N+1 is odd, and then use port N for the current allocation. 773 In this case, the server returns a RESERVATION-TOKEN attribute in 774 the response which the client can then include in a subsequent 775 Allocate request to create an allocation with port number N+1. 777 Note that the client cannot request a pair of adjacent ports unless 778 it also requests that the lower numbered port be even. Thus the 779 combination (E=0, R=1) is not allowed. 781 Similarly, by setting the P bit to 1 in the REQUESTED-PROPS 782 attribute, the client can request that the server allocate a 783 Preserving allocation. 785 For all the various REQUESTED-PROPS flags, if the server cannot 786 satisfy the request, the Allocate request is rejected. 788 The client MAY also include a RESERVATION-TOKEN attribute in the 789 request to ask the server to use a previously reserved port for the 790 allocation. If the RESERVATION-TOKEN attribute is included, then the 791 client MUST either omit the REQUESTED-PROPS attribute or set E=0 and 792 R=0, since doing otherwise would make no sense. 794 Once constructed, the client sends the Allocate request on the 795 5-tuple. 797 6.2. Receiving an Allocate Request 799 When the server receives an Allocate request, it performs the 800 following checks: 802 1. The server checks the credentials of the request, as per the 803 Long-Term Credential mechanism of [I-D.ietf-behave-rfc3489bis]. 805 2. The server checks if the 5-tuple is currently in use by an 806 existing allocation, or was it in use by another allocation 807 within the last 2 minutes. If yes, then there are two sub-cases: 809 * If the transport protocol in the 5-tuple is UDP, and if the 810 5-tuple is currently in use by an existing allocation, and if 811 the transaction id of the request matches the transaction id 812 stored with the allocation, then the request is a 813 retransmission of the original request. The server replies 814 either with a stored copy of the original response, or with a 815 response rebuilt from the stored state data. If the server 816 chooses to rebuild the response, then (a) it need not parse 817 the request further, but can immediately start building a 818 success response, (b) the value of the LIFETIME attribute can 819 be set to the current value of the time-to-expire timer, and 820 (c) the server may need to include an extra field in the 821 allocation to store the token returned in a RESERVATION-TOKEN 822 attribute. 824 * Otherwise, the server rejects the request with a 437 825 (Allocation Mismatch) error. 827 NOTE: If the request includes credentials that are acceptable to 828 server, but the 5-tuple is already in use, then it is important 829 that the server reject the request with a 437 (Allocation 830 Mismatch) error rather than a 401 (Unauthorized) error. This 831 ensures that the client knows that the problem is with the 832 5-tuple, rather than (wrongly) believing that the problem lies 833 with its credentials. 835 3. The server checks if the request contain a REQUESTED-TRANPORT 836 attribute. If the REQUESTED-TRANSPORT attribute is not included 837 or is malformed, the server rejects the request with a 400 (Bad 838 Request) error. Otherwise, if the attribute is included but 839 specifies a protocol other that UDP, the server rejects the 840 request with a 422 (Unsupported Transport Protocol) error. 842 4. The server checks if the request contains a REQUESTED-PROPS 843 attribute. If yes, then the server checks that it understands 844 and can satisfy all the flags that are set to 1. If a flag is 845 not understood, or if the server cannot satisfy the request, then 846 the server rejects the request with a 508 (Insufficient Port 847 Capacity) error. The server includes in its error response a 848 REQUESTED-PROPS attribute with all the flags the server 849 understands set to 1 and all others set to 0. Note that the 850 combination (E=0, R=1) MUST be treated as unsupported. 852 5. The server checks if the request contains a RESERVATION-TOKEN 853 attribute. If yes, and the request also contains a REQUESTED- 854 PROPS attribute with the E and R flags set to any combination 855 other than E=0 and R=0, then the server rejectes the request with 856 a 400 (Bad Request) error. Otherwise it checks to see if the 857 token is valid (i.e., the token is in range and has not expired, 858 and the corresponding relayed transport address is still 859 available). If the token is not valid for some reason, the 860 server rejects the request with a 508 (Insufficient Port 861 Capacity) error. 863 6. At any point, the server MAY also choose to reject the request 864 with a 486 (Allocation Quota Reached) error if it feels the 865 client is trying to exceed some locally-defined allocation quota. 866 The server is free to define this allocation quota any way it 867 wishes, but SHOULD define it based on the username used to 868 authenticate the request, and not on the client's transport 869 address. 871 If the server rejects the request with one of the error codes 422 872 (Unsupported Transport Protocol), 486 (Allocation Quota Reached) or 873 508 (Insufficient Port Capacity), it MAY include an ALTERNATE-SERVER 874 attribute in the error response redirecting the client to another 875 server that it believes will accept the request. If the attribute is 876 included, the address MUST be from the same address family as the 877 server's transport address. Note that, if the attribute is included, 878 the client will try this alternate server before trying the other 879 servers given by the SRV procedures. 881 NOTE: When UDP transport is used between the client and the 882 server, the client will restransmit an Allocate request if it does 883 not receive a response within a certain timeout period 884 [I-D.ietf-behave-rfc3489bis]. Because of this, the server may 885 receive two (or more) Allocate requests with the same 5-tuple and 886 same transaction id. Check #2 (above) handles the case where the 887 first Allocate request is accepted and generates a success 888 response, but it does not handle the case where the first request 889 is rejected but the second request is accepted (because conditions 890 on the server have changed in the brief intervening time period). 891 If the client receives the first (failure) response, it will 892 ignore the second (success) response and believe that an 893 allocation was not created. An allocation created in this matter 894 will eventually timeout, since the client will not refresh it. 895 Furthermore, if the client later retries with the same 5-tuple but 896 different transaction id, it will receive a 437 (Allocation 897 Mismatch), which should cause it to retry with a different 898 5-tuple. 900 Server implementors MAY elect to prevent this second case by 901 remembering recent failure responses and returning the saved 902 failure response when receiving a retransmitted Allocate request. 903 This optional behavior may be appropriate when the server 904 implements some sort of charging mechanism or a per-user quota. 905 Alternatively, servers may use a smaller maximum lifetime value to 906 mimize the lifetime of this "orphaned" allocation (see below). 908 Server implementors debating whether to implement this optional 909 feature should be aware that there are other scenarios in TURN 910 that lead to such "orphaned" allocations. 912 If all the checks pass, the server creates the allocation. The 913 5-tuple is set to the 5-tuple from the Allocate request, while the 914 list of permissions and the list of channels are initially empty. 916 When allocating a relayed transport address for the allocation, the 917 server MUST allocate an IP address from the same family (e.g, IPv4 918 vs. IPv6) as that on which the request was received (i.e., the 919 server's IP address in the 5-tuple for the allocation). 921 NOTE: An extension to TURN to allow an address from a different 922 address family is currently in progress 923 [I-D.ietf-behave-turn-ipv6]. 925 In addition, the server SHOULD only allocate ports from the range 926 49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]), 927 unless the TURN server application knows, through some means not 928 specified here, that other applications running on the same host as 929 the TURN server application will not be impacted by allocating ports 930 outside this range. This condition can often be satisfied by running 931 the TURN server application on a dedicated machine and/or by 932 arranging that any other applications on the machine allocate ports 933 before the TURN server application starts. In any case, the TURN 934 server SHOULD NOT allocate ports in the range 0 - 1023 (the Well- 935 Known Port range) to discourage clients from using TURN to run 936 standard services. 938 NOTE: The IETF is currently investigating the topic of randomized 939 port assignments to avoid certain types of attacks (see 940 [I-D.ietf-tsvwg-port-randomization]). It is recommended that a 941 TURN implementor keep abreast of this topic and, if appropriate, 942 implement a randomized port assignment algorithm. This is 943 especially applicable to servers that choose to pre-allocate a 944 number of ports from the underlying OS and then later assign them 945 to allocations; for example, a server may choose this technique to 946 implement the E and R flags in the REQUESTED-PROPS attribute (see 947 below). 949 If the request contains a REQUESTED-PROPS attribute with the E flag 950 set, then the server looks for an even port number to use for the 951 relayed transport address. 953 If the request contains a REQUESTED-PROPS attribute with both the E 954 and R flags set, then the server looks for a pair of port numbers N 955 and N+1 on the same IP address, where N is even. Port N is used in 956 the current allocation, while the relayed transport address with port 957 N+1 is assigned a token and reserved for a future allocation. The 958 server MUST hold this reservation for at least 30 seconds, and MAY 959 choose to hold longer (e.g. until the allocation with port N 960 expires). The server then includes the token in a RESERVATION-TOKEN 961 attribute in the success response. 963 If the request contains a RESERVATION-TOKEN, the server uses the 964 previously-reserved transport address corresponding to the included 965 token (if it is still available). 967 NOTE: The port N+1 reservation is a global reservation and is not 968 specific to a particular allocation, since the Allocate request 969 containing the RESERVATION-TOKEN will use a different 5-tuple and 970 will create a different allocation. The 5-tuple for the 971 subsequent Allocate request can be any allowed 5-tuple; the 972 subsequent Allocate request can use a 5-tuple with a different 973 client IP address and port, a different transport protocol, and 974 even different server IP address and port (provided, of course, 975 that the server IP address and port is one that the server is 976 listening for TURN requests on). 978 Otherwise (i.e., the E and R flags are not set, and RESERVATION-TOKEN 979 is not included), the server allocates any port in the range 980 described above. 982 The server determines the initial value of the time-to-expire field 983 as follows. If the request contains a LIFETIME attribute, and the 984 proposed lifetime value is greater than the default lifetime, and the 985 proposed lifetime value is otherwise acceptable to the server, then 986 the server uses that value. Otherwise, the server uses the default 987 lifetime. It is RECOMMENDED that the server impose a maximum 988 lifetime of no more than 3600 seconds (1 hour). Servers that 989 implement allocation quotas or charge users for allocations in some 990 way may wish to use a smaller maximum lifetime (perhaps as small as 991 the default lifetime) to more quickly remove orphaned allocations 992 (that is, allocations where the corresponding client has crashed or 993 terminated or the client connection has been lost for some reason). 994 Also note that the time-to-expire is recomputed with each successful 995 Refresh request, and thus the value computed here applies only until 996 the first refresh. 998 Once the allocation is created, the server replies with a success 999 response. The success response contains: 1001 o A RELAYED-ADDRESS attribute containing the relayed transport 1002 address; 1004 o A LIFETIME attribute containing the current value of the time-to- 1005 expire timer; 1007 o A RESERVATION-TOKEN attribute (if a second relayed transport 1008 address was reserved). 1010 o An XOR-MAPPED-ADDRESS attribute containing the client's IP address 1011 and port (from the 5-tuple); 1013 NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response 1014 as a convenience to the client. TURN itself does not make use of 1015 this value, but clients running ICE can often need this value and 1016 can thus avoid having to do an extra Binding transaction with some 1017 STUN server to learn it. 1019 The response (either success or error) is sent back to the client on 1020 the 5-tuple. 1022 6.3. Receiving an Allocate Response 1024 If the client receives a success response, then it MUST check that 1025 the relayed transport address is in an address family that the client 1026 understands and is prepared to deal with. This specification only 1027 covers the case where the relayed transport address is of the same 1028 address family as the client's transport address. If the relayed 1029 transport address is not in an address family that the client is 1030 prepared to deal with, then the client MUST delete the allocation 1031 (Section 7) and MUST NOT attempt to create another allocation on that 1032 server until it believes the mismatch has been fixed. 1034 The IETF is currently considering mechanisms for transitioning 1035 between IPv4 and IPv6 that could result in a client originating an 1036 Allocate request over IPv4, but the request would arrive at the 1037 server over IPv6, or vica-versa. Hence the importance of this 1038 check. 1040 Otherwise, the client creates its own copy of the allocation data 1041 structure to track what is happening on the server. In particular, 1042 the client needs to remember the actual lifetime received back from 1043 the server, rather than the value sent to the server in the request. 1044 The client must also remember the 5-tuple used for the request and 1045 the username and password it used to authenticate the request to 1046 ensure that it reuses them for subsequent messages. The client also 1047 needs to track the channels and permissions it establishes on the 1048 server. 1050 The client will probably wish to send the relayed transport address 1051 to peers (using some method not specified here) so the peers can 1052 communicate with it. The client may also wish to use the server- 1053 reflexive address it receives in the XOR-MAPPED-ADDRESS attribute in 1054 its ICE processing. 1056 If the client receives an error response, then the processing depends 1057 on the actual error code returned: 1059 o (Request timed out): There is either a problem with the server, or 1060 a problem reaching the server with the chosen transport. The 1061 client MAY choose to try again using a different transport (e.g., 1062 TCP instead of UDP), or the client MAY try a different server. 1064 o 400 (Bad Request): The server believes the client's request is 1065 malformed for some reason. The client MAY notify the user or 1066 operator and SHOULD NOT retry the same request with this server 1067 until it believes the problem has been fixed. The client MAY try 1068 a different server. 1070 o 401 (Unauthorized): If the client has followed the procedures of 1071 the Long-Term Credential mechanism and still gets this error, then 1072 the server is not accepting the client's credentials. The client 1073 SHOULD notify the user or operator and SHOULD NOT send any further 1074 requests to this server until it believes the problem has been 1075 fixed. The client MAY try a different server. 1077 o 437 (Allocation Mismatch): This indicates that the client has 1078 picked a 5-tuple which the server sees as already in use or which 1079 was recently in use. One way this could happen is if an 1080 intervening NAT assigned a mapped transport address that was 1081 recently used by another allocation. The client SHOULD pick 1082 another client transport address and retry the Allocate request 1083 (using a different transaction id). The client SHOULD try three 1084 different client transport addresses before giving up on this 1085 server. Once the client gives up on the server, it SHOULD NOT try 1086 to create another allocation on the server for 2 minutes. 1088 o 441 (Wrong Credentials): The client should not receive this error 1089 in response to a Allocate request. The client MAY notify the user 1090 or operator and SHOULD NOT retry the same request with this server 1091 until it believes the problem has been fixed. The client MAY try 1092 a different server. 1094 o 442 (Unsupported Transport Address): The client should not receive 1095 this error in response to a request for a UDP allocation. The 1096 client MAY notify the user or operator and SHOULD NOT retry the 1097 same request with this server until it believes the problem has 1098 been fixed. The client MAY try a different server. 1100 o 486 (Allocation Quota Reached): The server is currently unable to 1101 create any more allocations with this username. The client SHOULD 1102 wait at least 1 minute before trying to create any more 1103 allocations on the server. The client MAY try a different server. 1105 o 508 (Insufficient Port Capacity): The server has no more relayed 1106 transport addresses avaiable, or has none with the requested 1107 properties, or the one that was reserved is no longer available. 1108 If the client is using either the REQUESTED-PROPS or the 1109 RESERVATION-TOKEN attribute, then the client MAY choose to remove 1110 or modify this attribute and try again immediately. Otherwise, 1111 the client SHOULD wait at least 1 minute before trying to create 1112 any more allocations on this server. The client MAY try a 1113 different server. 1115 If the error response contains an ALTERNATE-SERVER attribute, and the 1116 client elects to try a different server, the the client SHOULD try 1117 the alternate server specified in that attribute (while obeying the 1118 rules in [I-D.ietf-behave-rfc3489bis] for avoiding redirection loops) 1119 before trying any other servers found using the SRV procedures of 1120 [I-D.ietf-behave-rfc3489bis]. 1122 7. Refreshing an Allocation 1124 A Refresh transaction can be used to either (a) refresh an existing 1125 allocation and update its time-to-expire, or (b) delete an existing 1126 allocation. 1128 If a client wishes to continue using an allocation, then the client 1129 MUST refresh it before it expires. It is suggested that the client 1130 refresh the allocation roughly 1 minute before it expires. If a 1131 client no longer wishes to use an allocation, then it SHOULD 1132 explicitly delete the allocation. A client MAY also change the time- 1133 to-expire of an allocation at any time for other reasons. 1135 7.1. Sending a Refresh Request 1137 If the client wishes to immediately delete an existing allocation, it 1138 includes a LIFETIME attribute with a value of 0. All other forms of 1139 the request refresh the allocation. 1141 The Refresh transaction updates the time-to-expire timer of an 1142 allocation. If the client wishes the server to set the time-to- 1143 expire timer to something other than the default lifetime, it 1144 includes a LIFETIME attribute with the requested value. The server 1145 then computes a new time-to-expire value in the same way as it does 1146 for an Allocate transaction, with the exception that a requested 1147 lifetime of 0 causes the server to immediately delete the allocation. 1149 The Refresh transaction is sent on the 5-tuple for the allocation. 1151 7.2. Receiving a Refresh Request 1153 When the server receives a Refresh request, it processes it as 1154 follows: 1156 1. The server checks the credentials of the request, as per the 1157 Long-Term Credential mechanism of [I-D.ietf-behave-rfc3489bis]. 1159 2. The server computes a value called the "desired lifetime" as 1160 follows: If the request contains a LIFETIME attribute and the 1161 attribute value is 0, then the desired lifetime is 0. Otherwise, 1162 if the request contains a LIFETIME attribute and the attribute 1163 value is greater than the default lifetime, and if the attribute 1164 value is otherwise acceptable to the server, then the the desired 1165 lifetime is the attribute value. Otherwise the desired lifetime 1166 is the default value. 1168 3. The processing then depends on whether or not the 5-tuple 1169 corresponds to an existing allocation: 1171 * If there is no existing allocation and the desired lifetime is 1172 0, then the request suceeeds (as it is OK to delete a non- 1173 existent allocation). 1175 * If there is no existing allocation and the desired lifetime is 1176 non-zero, then the server rejects the request with a 437 1177 Allocation Mismatch error. 1179 * If there is an existing allocation and the desired lifetime is 1180 0, then the request succeeds and the allocation is deleted. 1182 * If there is an existing allocation and the desired lifetime is 1183 non-zero, then the request succeeds and the allocation's time- 1184 to-expiry is set to the desired lifetime 1186 If the request succeeds, then server sends a success response 1187 containing: 1189 * A LIFETIME attribute containing the current value of the time- 1190 to-expire timer. 1192 If the Refresh request is carried over UDP, then it is possible that 1193 it can be retransmitted. The server need not do anything special to 1194 handle this case since it is OK to delete a non-existent allocation 1195 and it is also OK to refresh an existing allocation twice in rapid 1196 succession. 1198 7.3. Receiving a Refresh Response 1200 If the client receives a success response to its Refresh request, it 1201 updates its copy of the allocation data structure with the time-to- 1202 expire value contained in the response. 1204 If the client receives an 437 (Allocation Mismatch) error response to 1205 its Refresh request, then it must consider the allocation as having 1206 expired, as described in Section 4. All other errors indicate a 1207 software error on the part of either the client or the server. 1209 8. Permissions 1211 For each allocation, the server keeps a list of zero or more 1212 permissions. Each permission consists of an IP address which 1213 uniquely identifies the permission, and an associated time-to-expiry. 1214 The IP address describes a peer that is allowed to send data to the 1215 client, and the time-to-expiry is the number of seconds until the 1216 permission expires. 1218 Various events, as described in subsequent sections, can cause a 1219 permission for a given IP address to be installed or refreshed. This 1220 causes one of two things to happen: 1222 o If no permission for that IP address exists, then a permission is 1223 created with the given IP address and a time-to-expiry equal to 1224 the default permission lifetime. 1226 o If a permission for that IP address already exists, then the 1227 lifetime for that permission is reset to the default permission 1228 lifetime. 1230 The default permission lifetime MUST be 300 seconds (= 5 minutes). 1232 Each permission's time-to-expire decreases down once per second until 1233 it reaches 0, at which point the permission expires and is deleted. 1235 When a UDP datagram arrives at the relayed transport address for the 1236 allocation, the server checks the list of permissions for that 1237 allocation. If there is a permission with an IP address that is 1238 equal to the source IP address of the UDP datagram, then the UDP 1239 datagram can be relayed to the client. Otherwise, the UDP datagram 1240 is silently discarded. Note that only IP addresses are compared; 1241 port numbers are irrelevant. 1243 The permissions for one allocation are totally unrelated to the 1244 permissions for a different allocation. If an allocation expires, 1245 all its permissions expire with it. 1247 NOTE: Though TURN permissions expire after 5 minutes, many NATs 1248 deployed at the time of publication expire their UDP bindings 1249 considerably faster. Thus an application using TURN will probably 1250 wish to send some sort of keep-alive traffic at a much faster 1251 rate. Applications using ICE should follow the keep-alive 1252 guidelines of ICE [I-D.ietf-mmusic-ice], and applications not 1253 using ICE are advised to do something similar. 1255 9. Send and Data Indications 1257 TURN supports two ways to send and receive data from peers. This 1258 section describes the use of Send and Data indications, while 1259 Section 10 describes the use of the Channel Mechanism. 1261 9.1. Sending a Send Indication 1263 A client can use a Send indication to pass data to the server for 1264 relaying to a peer. A client can also use a Send indication without 1265 a DATA attribute to install or refresh a permission for the specified 1266 IP address. A client may use a Send indication to send data to a 1267 peer even if a channel is bound to that peer. 1269 When forming a Send indication, the client MUST include a PEER- 1270 ADDRESS attribute and MAY include a DATA attribute. If the DATA 1271 attribute is included, then the DATA attribute contains the actual 1272 application data to be sent to the peer, and the PEER-ADDRESS 1273 attribute contains the transport address of the peer to which the 1274 data is to be sent. If the DATA attribute is not present, then the 1275 PEER-ADDRESS attribute contains the IP address for which a permission 1276 is to be installed or refreshed; in this case the port specified in 1277 the attribute is ignored. 1279 Note that no authentication attributes are included, since 1280 indications cannot be authenticated using the Long-Term Credential 1281 mechanism. 1283 The Send indication MUST be sent using the same 5-tuple used for the 1284 original allocation. 1286 9.2. Receiving a Send Indication 1288 When the server receives a Send indication, it processes it as 1289 follows. 1291 If the received Send indication contains a DATA attribute, then it 1292 forms a UDP datagram as follows: 1294 o the source transport address is the relayed transport address of 1295 the allocation, where the allocation is determined by the 5-tuple 1296 on which the Send indication arrived; 1298 o the destination transport address is taken from the PEER-ADDRESS 1299 attribute; 1301 o the data following the UDP header is the contents of the value 1302 field of the DATA attribute. 1304 The resulting UDP datagram is then sent to the peer. If any errors 1305 are detected during this process (e.g., the Send indication does not 1306 contain a PEER-ADDRESS attribute), the received indication is 1307 silently discarded and no UDP datagram is sent. 1309 Clients are not allowed to use Send indications to send ICMP messages 1310 to peers. Thus the server MUST silently ignore a Send indication 1311 containing the ICMP attribute. 1313 When the server receives a valid Send indication, either with or 1314 without a DATA attribute, it also installs or refreshes a permission 1315 for the IP address contained in the PEER-ADDRESS attribute (see 1316 Section 8). 1318 9.3. Receiving a UDP Datagram 1320 When the server receives a UDP datagram at a currently allocated 1321 relayed transport address, the server looks up the allocation 1322 associated with the relayed transport address. It then checks to see 1323 if relaying is permitted, as described in Section 8. 1325 If relaying is permitted, then the server checks if there is a 1326 channel bound to the peer that sent the UDP datagram (see 1327 Section 10). If a channel is bound, then processing proceeds as 1328 described in Section 10.7. 1330 If relaying is permitted but no channel is bound to the peer, then 1331 the server forms and sends a Data indication. The Data indication 1332 MUST contain both a PEER-ADDRESS and a DATA attribute and MUST NOT 1333 contain an ICMP attribute. The DATA attribute is set to the value of 1334 the 'data octets' field from the datagram, and the PEER-ADDRESS 1335 attribute is set to the source transport address of the received UDP 1336 datagram. The Data indication is then sent on the 5-tuple associated 1337 with the allocation. 1339 9.4. Receiving a Data Indication 1341 When the client receives a Data indication, it checks that the Data 1342 indication contains both a PEER-ADDRESS and a DATA attribute, and 1343 discards the indication if it does not. 1345 The client then checks for the presence of the ICMP attribute. If it 1346 is present, the Data indication contains an ICMP message as described 1347 in Section 11. 1349 If the Data indication does not contain an ICMP attribute, the client 1350 delivers the data octets inside the DATA attribute to the 1351 application, along with an indication that they were received from 1352 the peer whose transport address is given by the PEER-ADDRESS 1353 attribute. 1355 10. Channels 1357 Channels provide a way for the client and server to send application 1358 data using ChannelData messages, which have less overhead than Send 1359 and Data indications. 1361 Channel bindings are always initiated by the client. The client can 1362 bind a channel to a peer at any time during the lifetime of the 1363 allocation. The client may bind a channel to a peer before 1364 exchanging data with it, or after exchanging data with it (using Send 1365 and Data indications) for some time, or may choose never to bind a 1366 channel it. The client can also bind channels to some peers while 1367 not binding channels to other peers. 1369 Channel bindings are specific to an allocation, so that a binding in 1370 one allocation has no relationship to a binding in any other 1371 allocation. If an allocation expires, all its channel bindings 1372 expire with it. 1374 A channel binding consists of: 1376 o A channel number; 1377 o A transport address (of the peer); 1379 o A time-to-expiry timer. 1381 Within the context of an allocation, a channel binding is uniquely 1382 identified either by the channel number or by the transport address. 1383 Thus the same channel cannot be bound to two different transport 1384 addresses, nor can the same transport address be bound to two 1385 different channels. 1387 A channel binding lasts for 10 minutes unless refreshed. Refreshing 1388 the binding (by the server receiving either a ChannelBind request 1389 rebinding the channel to the same peer, or by the server receiving a 1390 ChannelData message on that channel) resets the time-to-expire timer 1391 back to 10 minutes. When the channel binding expires, the channel 1392 becomes unbound and available for binding to a different transport 1393 address. 1395 When binding a channel to a peer, the client SHOULD be prepared to 1396 receive ChannelData messages on the channel from the server as soon 1397 as it has sent the ChannelBind request. Over UDP, it is possible for 1398 the client to receive ChannelData messages from the server before it 1399 receives a ChannelBind success response. 1401 In the other direction, the client MAY elect to send ChannelData 1402 messages before receiving the ChannelBind success response. Doing 1403 so, however, runs the risk of having the ChannelData messages dropped 1404 by the server if the ChannelBind request does not succeed for some 1405 reason (e.g., packet lost if the request is sent over UDP, or the 1406 server being unable to fulfill the request). A client that wishes to 1407 be safe should either queue the data, or use Send indications until 1408 the channel binding is confirmed. 1410 10.1. Sending a ChannelBind Request 1412 A channel binding is created using a ChannelBind transaction. A 1413 channel binding can also be refreshed using a ChannelBind 1414 transaction. 1416 To initiate the ChannelBind transaction, the client forms a 1417 ChannelBind request. The channel to be bound is specified in a 1418 CHANNEL-NUMBER attribute, and the peer's transport address is 1419 specified in a PEER-ADDRESS attribute. Section 10.2 describes the 1420 restrictions on these attributes. 1422 Note that rebinding a channel to the same transport address that it 1423 is already bound to provides a way to refresh a channel binding 1424 without sending data to the peer. 1426 Once formed, the ChannelBind request is sent using the 5-tuple for 1427 the allocation. 1429 10.2. Receiving a ChannelBind Request 1431 When the server receives a ChannelBind request, it checks the 1432 following: 1434 o The request contains both a CHANNEL-NUMBER and a PEER-ADDRESS 1435 attribute; 1437 o The channel number is in the range 0x4000 to 0xFFFE (inclusive); 1439 o The channel number is not currently bound to a different transport 1440 address (same transport address is OK); 1442 o The transport address is not currently bound to a different 1443 channel number. 1445 If any of these tests fail, the server replies with an error response 1446 with error code 400 "Bad Request". Otherwise, the ChannelBind 1447 request is valid and the server replies with a ChannelBind success 1448 response. There are no required attributes in a ChannelBind 1449 response. 1451 If ChannelBind request is valid, then the server creates or refreshes 1452 the channel binding using the channel number in the CHANNEL-ADDRESS 1453 attribute and the transport address in the PEER-ADDRESS attribute. 1454 The server also installs or refreshes a permission for the IP address 1455 in the PEER-ADDRESS attribute. 1457 10.3. Receiving a ChannelBind Response 1459 When the client receives a successful ChannelBind response, it 1460 updates its data structures to record that the channel binding is now 1461 active. 1463 10.4. The ChannelData Message 1465 The ChannelData message is used to carry application data between the 1466 client and the server. It has the following format: 1468 0 1 2 3 1469 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 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Channel Number | Length | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | | 1474 / Application Data / 1475 / / 1476 | | 1477 | +-------------------------------+ 1478 | | 1479 +-------------------------------+ 1481 The Channel Number field specifies the number of the channel on which 1482 the data is traveling, and thus the address of the peer that is 1483 sending or is to receive the data. The channel number MUST be in the 1484 range 0x4000 - 0xFFFF, with channel number 0xFFFF being reserved for 1485 possible future extensions. 1487 Channel numbers 0x0000 - 0x3FFF cannot be used because bits 0 and 1 1488 are used to distinguish ChannelData messages from STUN-formatted 1489 messages (i.e., Allocate, Send, Data, ChannelBind, etc). STUN- 1490 formatted messages always have bits 0 and 1 as "00", while 1491 ChannelData messages use combinations "01", "10", and "11". 1493 The Length field specifies the length in bytes of the application 1494 data field (i.e., it does not include the size of the ChannelData 1495 header). Note that 0 is a valid length. 1497 The Application Data field carries the data the client is trying to 1498 send to the peer, or that the peer is sending to the client. 1500 10.5. Sending a ChannelData Message 1502 Once a client has bound a channel to a peer, then when the client has 1503 data to send to that peer it may use either a ChannelData message or 1504 a Send indication; that is, the client is not obligated to use the 1505 channel when it exists and may freely intermix the two message types 1506 when sending data to the peer. The server, on the other hand, MUST 1507 use the ChannelData message if a channel has been bound to the peer. 1509 The fields of the ChannelData message are filled in as described in 1510 Section 10.4. 1512 Over stream transports, the ChannelData message MUST be padded to a 1513 multiple of four bytes in order to ensure the alignment of subsequent 1514 messages. The padding is not reflected in the length field of the 1515 ChannelData message, so the actual size of a ChannelData message 1516 (including padding) is (4 + Length) rounded up to the nearest 1517 multiple of 4. Over UDP, the padding is not required but MAY be 1518 included. 1520 The ChannelData message is then sent on the 5-tuple associated with 1521 the allocation. 1523 10.6. Receiving a ChannelData Message 1525 The receiver of the ChannelData message uses bits 0 and 1 to 1526 distinguish it from STUN-formatted messages, as described in 1527 Section 10.4. 1529 If the ChannelData message is received in a UDP datagram, and if the 1530 UDP datagram is too short to contain the claimed length of the 1531 ChannelData message (i.e., the UDP header length field value is less 1532 than the ChannelData header length field value + 4 + 8), then the 1533 message is silently discarded. 1535 If the ChannelData message is received over TCP or over TLS over TCP, 1536 then the actual length of the ChannelData message is as described in 1537 Section 10.5. 1539 If the ChannelData message is received on a channel which is not 1540 bound to any peer, then the message is silently discarded. 1542 If no errors are detected, the server relays the application data to 1543 the peer by forming a UDP datagram as follows: 1545 o the source transport address is the relayed transport address of 1546 the allocation, where the allocation is determined by the 5-tuple 1547 on which the ChannelData message arrived; 1549 o the destination transport address is the transport address to 1550 which the channel is bound; 1552 o the data following the UDP header is the contents of the data 1553 field of the ChannelData message. 1555 The resulting UDP datagram is then sent to the peer. Note that if 1556 the Length field in the ChannelData message is 0, then there will be 1557 no data in the UDP datagram, but the UDP datagram is still formed and 1558 sent. 1560 If the ChannelData message is valid, then the server refreshes the 1561 channel binding, and also installs or refreshes a permission for the 1562 IP address part of the transport address to which the UDP datagram is 1563 sent (see Section 8). 1565 10.7. Relaying Data from the Peer 1567 When the server receives a UDP datagram on the relayed transport 1568 address associated with an allocation, the server processes it as 1569 described in Section 9.3. If that section indicates that a 1570 ChannelData message should be sent (because there is a channel bound 1571 to the peer that sent to UDP datagram), then the server forms and 1572 sends a ChannelData message as described in Section 10.5. 1574 11. IP and ICMP 1576 This section describes how the server sets various fields in the IP 1577 header when relaying between the client and the peer or vica-versa. 1578 It also describes how the server relays ICMP messages. The 1579 descriptions in this section apply: (a) when the server receives a 1580 Send indication or ChannelData message from the client and sends a 1581 UDP datagram to the peer, (b) when the server receives a UDP datagram 1582 on the relayed-transport address and sends a Data indication or 1583 ChannelData message to the client, or (c) when the server receives an 1584 ICMP message. This section does not apply when the server sends TURN 1585 control messages. 1587 The descriptions below have two parts: a preferred behavior and an 1588 alternate behavior. A Preserving allocation MUST implement the 1589 preferred behavior. A non-preserving allocation with UDP transport 1590 to the client SHOULD implement the preferred behavior, but if that is 1591 not possible for a particular field, then it SHOULD implement the 1592 alternative behavior. A non-preserving allocation with TCP or TLS 1593 transport to client SHOULD implement the alternate behavior, except 1594 where this conflicts with standard TCP or TLS behavior. 1596 11.1. IP 1598 This section describes the preferred and alternate behavior for 1599 various fields in the IP header. 1601 Time to Live (IPv4) or Hop Count (IPv6) 1603 Preferred Behavior: If the incoming value is 0, then send an ICMP 1604 Time Exceeded message back to the sender. Otherwise set the 1605 outgoing Time to Live/Hop Count to one less than the incoming 1606 value. 1608 Alternate Behavior: Set the outgoing value to the default for 1609 outgoing packets. 1611 Diff-Serv Code Point 1613 Preferred Behavior: Set the outgoing value to the incoming value, 1614 unless the server includes a differentiated services classifier 1615 and marker [RFC2474]. 1617 Alternate Behavior: Set the outgoing value to a fixed value, which 1618 by default is Best Effort unless configured otherwise. 1620 In both cases, if the server is immediately adjacent to a 1621 differentiated services classifier and marker, then DSCP MAY be 1622 set to any arbitrary value in the direction towards the 1623 classifier. 1625 ECN 1627 Preferred Behavior: Set the outgoing value to the incoming value, 1628 UNLESS the server is doing Active Queue Management, the incoming 1629 ECN field is 01 or 10, and the server wishes to indicate that 1630 congestion has been experienced, in which case set the outgoing 1631 value to 11. 1633 Alternate Behavior: Set the outgoing value to 00 (ECN not 1634 supported) 1636 Flow Label 1638 Preferred Behavior: Set the outgoing flow label to 0. 1640 Alternate Behavior: Same as the Preferred behavior. 1642 IPv4 Fragmentation 1644 Preferred Behavior: 1646 If the outgoing packet size does not exceed the outgoing link's 1647 MTU, then send the outgoing packet unfragmented. Set the DF 1648 bit in the outgoing packet to the value of the DF bit in the 1649 incoming packet, and set the other fragmentation fields 1650 (Identification, MF, Fragment Offset) as appropriate for a 1651 packet originating from the server. 1653 Otherwise, if the outgoing link's MTU is exceeded and the 1654 incoming DF bit is 0, then fragment the packet before sending. 1655 Set the outgoing DF to 0, and set the other fragmentation 1656 fields as appropriate for fragments originated from the server. 1658 Otherwise [link MTU exceeded and incoming DF set], drop the 1659 outgoing packet and send an ICMP message of type 3 code 4 1660 ("fragmentation needed and DF set") to the sender of the 1661 incoming packet. 1663 Alternate Behavior: As described in the Preferred Behavior, except 1664 always assume the incoming DF bit is 0. 1666 IPv6 Fragmentation 1668 Preferred Behavior: 1670 If the incoming packet did not include a Fragmentation header 1671 and the outgoing packet size does not exceed the outgoing 1672 link's MTU, then send the outgoing packet without a 1673 Fragmentation header. 1675 If the incoming packet included a Fragment header and if the 1676 outgoing packet size (with a Fragmentation header included) 1677 does not exceed the outgoing link's MTU, then send the outgoing 1678 packet with a Fragmentation header. Set the fields of the 1679 Fragmentation header as appropriate for a packet originating 1680 from the server. 1682 If the incoming packet did not include a Fragmentation header 1683 and the outgoing packet size exceeds the outgoing link's MTU , 1684 then drop the outgoing packet and send an ICMP message of type 1685 2 code 0 ("Packet too big") to the sender of the incoming 1686 packet. If the packet is being sent to the peer, then reduce 1687 the MTU reported in the ICMP message by 48 bytes to allow room 1688 for the overhead of a Data indication. 1690 Otherwise, if the link's MTU is exceeded and the incoming 1691 packet contained a Fragmentation header, then fragment the 1692 outgoing packet into fragments of no more than 1280 bytes. Set 1693 the fields of the Fragmentation header as appropriate for a 1694 packet originating from the server. 1696 Alternate Behavior: As described in the Preferred Behavior, except 1697 always assume incoming packet has a Fragmentation header. 1699 IPv4 Options 1700 Preferred Behavior: The outgoing packet is sent without any IPv4 1701 options. 1703 Alternate Behavior: Same as preferred. 1705 IPv6 Extention Headers 1707 Preferred Behavior: The outgoing packet is sent without any IPv6 1708 extension headers, with the exception of the Fragmentation header 1709 as described above 1711 Alternate Behavior: Same as preferred. 1713 11.2. ICMP 1715 This sub-section describes the preferred behavior of ICMP relaying. 1716 The corresponding alternate behavior is to not relay ICMP messages. 1718 When an ICMP message arrives at the server, the copy of the original 1719 IP packet present inside the ICMP message is examined. The server 1720 first checks that the original IP packet header is immediately 1721 followed by a UDP protocol header, such that the original source 1722 transport address was X and the original destination transport 1723 address was Y. The server also checks that the type and code values 1724 in the ICMP header are one of those relayed (see below). Other ICMP 1725 messages are either ignored, or used by the server internally in an 1726 unspecified manner. 1728 The server then checks if one of the following two cases applies: 1730 Case 1: X is a relayed-transport-address currently assigned to an 1731 active allocation on the server, and there exists a permission for 1732 the IP address of Y in the allocation. 1734 In this case, the original IP packet was traveling from the server to 1735 a peer, so the the server relays the ICMP message back to the client. 1736 The server creates a Data indication where the PEER-ADDRESS attribute 1737 contains Y, and the ICMP attribute contains the type and code from 1738 the incoming ICMP message, and the DATA attribute contains 1739 application data from the original IP packet starting AFTER the UDP 1740 header. The server SHOULD include as much application data as 1741 possible consistent with not exceeding a total IP packet size of 1742 either 576 bytes (for IPv4) or 1280 bytes (for IPv6). 1744 Note that there is no point in including the original IP or UDP 1745 header in the DATA attribute because those headers were generated 1746 by the server, not the client. 1748 Case 2: There is an active allocation where X is the server transport 1749 address, Y is the client transport address, and UDP is used as 1750 transport between the client and the server. Furthermore, the packet 1751 after the UDP header is either (a) a ChannelData header which 1752 contains an active channel number in the allocation, or (b) a Data 1753 indication whose PEER-ADDRESS attribute contains an IP address for 1754 which there exists a permission in the allocation. 1756 In this case, the original IP packet was traveling from the server to 1757 the client, so the server creates and sends an ICMP message to the 1758 peer. The outgoing ICMP message contains the type and code fields 1759 from the incoming ICMP message and then contains an approximation to 1760 the original IP packet sent from the peer to the server (the one the 1761 server was trying to relay to the client inside the ChannelData or 1762 Data indication). This approximation contains a synthesized IP 1763 header, a synthesized UDP header, and some application data. The 1764 synthesis is done as follows: 1766 o The destination transport address is the relayed-transport-address 1767 of the allocation; 1769 o The source transport address is the peer's transport address 1770 determined from either (a) the channel number or (b) the PEER- 1771 ADDRESS attribute; 1773 o The application data is taken from either (a) the ChannelData 1774 message or (b) the DATA attribute. The server SHOULD include as 1775 much application data as possible consistent with not exceeding 1776 either 576 bytes (for IPv4) or 1280 bytes (for IPv6). 1778 The remaining fields in the IP and UDP headers are simply set to 1779 sensible values, since for most of them there is no way to 1780 reconstruct the original values. 1782 The server SHOULD relay all ICMP type/code combinations and MUST 1783 relay at least the following combinations. For IPv4: 1785 Type 3, code 4: Fragmentation needed and DF set 1787 For IPv6: 1789 Type 2, code : Packet too big 1791 Note that the ICMP attribute appears only in Data indications; the 1792 client cannot use the ICMP attribute in a Send indication to send 1793 ICMP messages to the peer. 1795 12. New STUN Methods 1797 This section lists the codepoints for the new STUN methods defined in 1798 this specification. See elsewhere in this document for the semantics 1799 of these new methods. 1801 Request/Response Transactions 1802 0x003 : Allocate 1803 0x004 : Refresh 1804 0x009 : ChannelBind 1806 Indications 1807 0x006 : Send 1808 0x007 : Data 1810 13. New STUN Attributes 1812 This STUN extension defines the following new attributes: 1814 0x000C: CHANNEL-NUMBER 1815 0x000D: LIFETIME 1816 0x0010: Reserved (was BANDWIDTH) 1817 0x0012: PEER-ADDRESS 1818 0x0013: DATA 1819 0x0016: RELAYED-ADDRESS 1820 0x0018: REQUESTED-PROPS 1821 0x0019: REQUESTED-TRANSPORT 1822 0x0022: RESERVATION-TOKEN 1823 0x0030: ICMP 1825 13.1. CHANNEL-NUMBER 1827 The CHANNEL-NUMBER attribute contains the number of the channel. It 1828 is a 16-bit unsigned integer, followed by a two-octet RFFU (Reserved 1829 For Future Use) field which MUST be set to 0 on transmission and MUST 1830 be ignored on reception. 1832 0 1 2 3 1833 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 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | Channel Number | RFFU = 0 | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 13.2. LIFETIME 1840 The lifetime attribute represents the duration for which the server 1841 will maintain an allocation in the absence of a refresh. It is a 32- 1842 bit unsigned integral value representing the number of seconds 1843 remaining until expiration. 1845 13.3. PEER-ADDRESS 1847 The PEER-ADDRESS specifies the address and port of the peer as seen 1848 from the TURN server. It is encoded in the same way as XOR-MAPPED- 1849 ADDRESS. 1851 13.4. DATA 1853 The DATA attribute is present in all Data indications and most Send 1854 indications. The contents of DATA attribute is the application data 1855 (that is, the data that would immediately follow the UDP header if 1856 the data was been sent directly between the client and the peer). 1858 13.5. RELAYED-ADDRESS 1860 The RELAYED-ADDRESS is present in Allocate responses. It specifies 1861 the address and port that the server allocated to the client. It is 1862 encoded in the same way as XOR-MAPPED-ADDRESS. 1864 13.6. REQUESTED-PROPS 1866 This attribute allows the client to request that the allocation have 1867 certain properties, and by the server to indicate which properties 1868 are supported. The attribute is 32 bits long. Its format is: 1870 0 1 2 3 1871 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 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 |E|R|P| MUST be 0 | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 The first part of the attribute value contains a number of one-bit 1877 flags. These are: 1879 E: If 1, the port number for the relayed-transport-address must be 1880 even. If 0, the port number can be even or odd. 1882 R: If 1, the server must reserve the next highest port for a 1883 subsequent allocation. If 0, no such reservation is requested. 1884 If the client sets the R bit to 1, it MUST also set the E bit to 1 1885 (however, the E bit may be 1 when the R bit is 0). 1887 P: If 1, the allocation must be a Preserving allocation. If 0, the 1888 allocation can be either Preserving or Non-Preserving. 1890 All these flags have the property that if the bit is 1, and the 1891 server cannot create an allocation that satisfies the request, then 1892 the Allocate request is rejected. To allow future TURN extensions to 1893 define new flags that also have this property, the client MUST set 1894 the rest of the attribute to zero, and the server MUST fail the 1895 Allocate request if any bits which the server does not support are 1896 set to 1. By doing this, any new flags that are not recognized by 1897 the server will cause the Allocate request to fail. 1899 13.7. REQUESTED-TRANSPORT 1901 This attribute is used by the client to request a specific transport 1902 protocol for the allocated transport address. It has the following 1903 format: 1904 0 1 2 3 1905 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 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Protocol | RFFU | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 The Protocol field specifies the desired protocol. The codepoints 1911 used in this field are taken from those allowed in the Protocol field 1912 in the IPv4 header and the NextHeader field in the IPv6 header 1913 [Protocol-Numbers]. This specification only allows the use of 1914 codepoint 17 (User Datagram Protocol). 1916 The RFFU field MUST be set to zero on transmission and MUST be 1917 ignored on reception. It is reserved for future uses. 1919 13.8. RESERVATION-TOKEN 1921 The RESERVATION-TOKEN attribute contains a token that uniquely 1922 identifies a relayed transport address being held in reserve by the 1923 server. The server includes this attribute in a success response to 1924 tell the client about the token, and the client includes this 1925 attribute in a subsequent Allocate request to request the server use 1926 that relayed transport address for the allocation. 1928 The attribute value is a 64-bit-long field containing the token 1929 value. 1931 13.9. ICMP 1933 This attribute is included by the server in a Data indication to 1934 indicate that the Data indication contains information from an ICMP 1935 message that was received by the server. The attribute has the 1936 following format: 1937 0 1 2 3 1938 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 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 | Type | Code | MUST be 0 | 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 The Type and Code fields of the attribute are taken from the Type and 1944 Code fields in the ICMP message received by the server. 1946 14. New STUN Error Response Codes 1948 This document defines the following new error response codes: 1950 437 (Allocation Mismatch): A request was received by the server that 1951 requires an allocation to be in place, but there is none, or a 1952 request was received which requires no allocation, but there is 1953 one. 1955 441 (Wrong Credentials): The credentials in the (non-Allocate) 1956 request, though otherwise acceptable to the server, do not match 1957 those used to create the allocation. 1959 442 (Unsupported Transport Protocol): The Allocate request asked the 1960 server to use a transport protocol between the server and the peer 1961 that the server does not support. NOTE: This does NOT refer to 1962 the transport protocol used in the 5-tuple. 1964 486 (Allocation Quota Reached): No more allocations using this 1965 username can be created at the present time. 1967 508 (Insufficient Port Capacity): The server has no more relayed 1968 transport addresses available right now, or has none with the 1969 requested properties, or the one that corresponds to the specified 1970 token is not available. 1972 15. Security Considerations 1974 TBD: Update this section to match changes to the TURN protocol. 1976 TURN servers allocate resources to clients, in contrast to the 1977 Binding method defined in [I-D.ietf-behave-rfc3489bis]. Therefore, a 1978 TURN server may require the authentication and authorization of STUN 1979 requests. This authentication is provided by mechanisms defined in 1980 the STUN specification itself, in particular digest authentication. 1982 Because TURN servers allocate resources, they can be susceptible to 1983 denial-of-service attacks. All Allocate transactions are 1984 authenticated, so that an unknown attacker cannot launch an attack. 1985 An authenticated attacker can generate multiple Allocate requests, 1986 however. To prevent a single malicious user from allocating all of 1987 the resources on the server, it is RECOMMENDED that a server 1988 implement a per user limit on the number of allocations that can 1989 active at one time. Such a mechanism does not prevent a large number 1990 of malicious users from each requesting a small number of 1991 allocations. Attacks such as these are possible using botnets, and 1992 are difficult to detect and prevent. Implementors of TURN should 1993 keep up with best practices around detection of anomalous botnet 1994 attacks. 1996 A client will use the transport address learned from the RELAYED- 1997 ADDRESS attribute of the Allocate response to tell other users how to 1998 reach them. Therefore, a client needs to be certain that this 1999 address is valid, and will actually route to them. Such validation 2000 occurs through the message integrity checks provided in the Allocate 2001 response. They can guarantee the authenticity and integrity of the 2002 allocated addresses. Note that TURN is not susceptible to the 2003 attacks described in Section 12.2.3, 12.2.4, 12.2.5 or 12.2.6 of 2004 [I-D.ietf-behave-rfc3489bis] [[TODO: Update section number references 2005 to 3489bis]]. These attacks are based on the fact that a STUN server 2006 mirrors the source IP address, which cannot be authenticated. STUN 2007 does not use the source address of the Allocate request in providing 2008 the RELAYED-ADDRESS, and therefore, those attacks do not apply. 2010 TURN attempts to adhere as closely as possible to common firewall 2011 policies, consistent with allowing data to flow. TURN has fairly 2012 limited applicability, requiring a user to explicitly authorize 2013 permission to receive data from a peer, one IP address at a time. 2014 Thus, it does not provide a general technique for externalizing 2015 sockets. Rather, it has similar security properties to the placement 2016 of an address-restricted NAT in the network, allowing messaging in 2017 from a peer only if the internal client has sent a packet out towards 2018 the IP address of that peer. This limitation means that TURN cannot 2019 be used to run, for example, SIP servers, NTP servers, FTP servers or 2020 other network servers that service a large number of clients. 2021 Rather, it facilitates rendezvous of NATted clients that use some 2022 other protocol, such as SIP, to communicate IP addresses and ports 2023 for communications. 2025 Confidentiality of the transport addresses learned through Allocate 2026 transactions does not appear to be that important. If required, it 2027 can be provided by running TURN over TLS. 2029 TURN does not and cannot guarantee that UDP data is delivered in 2030 sequence or to the correct address. As most TURN clients will only 2031 communicate with a single peer, the use of a single channel number 2032 will be very common. Consider an enterprise where Alice and Bob are 2033 involved in separate calls through the enterprise NAT to their 2034 corporate TURN server. If the corporate NAT reboots, it is possible 2035 that Bob will obtain the exact NAT binding originally used by Alice. 2036 If Alice and Bob were using identical channel numbers, Bob will 2037 receive unencapsulated data intended for Alice and will send data 2038 accidentally to Alice's peer. This is not a problem with TURN. This 2039 is precisely what would happen if there was no TURN server and Bob 2040 and Alice instead provided a (STUN) reflexive transport address to 2041 their peers. If detecting this misdelivery is a problem, the client 2042 and its peer need to use message integrity on their data. 2044 Relay servers are useful even for users not behind a NAT. They can 2045 provide a way for truly anonymous communications. A user can cause a 2046 call to have its media routed through a TURN server, so that the 2047 user's IP addresses are never revealed. 2049 Any relay addresses learned through an Allocate request will not 2050 operate properly with IPSec Authentication Header (AH) [RFC4302] in 2051 transport or tunnel mode. However, tunnel-mode IPSec ESP [RFC4303] 2052 should still operate. 2054 16. IANA Considerations 2056 Since TURN is an extension to STUN [I-D.ietf-behave-rfc3489bis], the 2057 methods, attributes and error codes defined in this specification are 2058 new method, attributes, and error codes for STUN. This section 2059 directs IANA to add these new protocol elements to the IANA registry 2060 of STUN protocol elements. 2062 The codepoints for the new STUN methods defined in this specification 2063 are listed in Section 12. 2065 The codepoints for the new STUN attributes defined in this 2066 specification are listed in Section 13. 2068 The codepoints for the new STUN error codes defined in this 2069 specification are listed in Section 14. 2071 Extensions to TURN can be made through IETF consensus. 2073 17. IAB Considerations 2075 The IAB has studied the problem of "Unilateral Self Address Fixing", 2076 which is the general process by which a client attempts to determine 2077 its address in another realm on the other side of a NAT through a 2078 collaborative protocol reflection mechanism [RFC3424]. The TURN 2079 extension is an example of a protocol that performs this type of 2080 function. The IAB has mandated that any protocols developed for this 2081 purpose document a specific set of considerations. 2083 TURN is an extension of the STUN protocol. As such, the specific 2084 usages of STUN that use the TURN extensions need to specifically 2085 address these considerations. Currently the only STUN usage that 2086 uses TURN is ICE [I-D.ietf-mmusic-ice]. 2088 18. Example 2090 TBD 2092 19. Open Issues 2094 This section lists the known issues in this version of the 2095 specification. 2097 1. Detecting in-use channels. Do we need a way for a client to 2098 determine if a channel is currently bound? Right now, the only 2099 way is to try to bind it to an address. 2101 2. Public TURN servers. The spec currently hints (but does not say 2102 anything solid) that the way to run a publicly-accessable TURN 2103 server is to not require authentication. But perhaps a better 2104 way is to require authentication but have some unspecified method 2105 to allow any user to create an account on the server. 2107 3. IPv6. Currently, TURN supports IPv4-to-IPv4 relaying, and IPv6- 2108 to-IPv6 relaying, but does not support IPv4-to-IPv6 relaying. To 2109 ensure this, a server requires that the family of the relayed 2110 address match that of the 5-tuple as seen by the server. 2111 However, some people would like to see a different rule. 2113 4. ALTERNATE-SERVER and Anycast. The details of ALTERNATE-SERVER 2114 support are still under discussion. In particular, some people 2115 would like to use ALTERNATE-SERVER to support anycast discovery 2116 of a TURN server. 2118 5. Authenticated Permission Refresh. Currently, permissions can be 2119 refreshed by unauthenticated Send indications and ChannelData 2120 messages. Some have suggested that this is a security issue. 2122 6. PMTUD for non-preserving allocations. Some people would like a 2123 way to do PMTUD even if the allocation is non-preserving, and 2124 have suggested that a way for the client to indicate to the 2125 server (in a Send indication) that the DF bit should be set when 2126 sending to the peer might allow this. 2128 7. Security. The security consideration section is out-of-date with 2129 the changes to the rest of the draft, and it has been suggested 2130 that TURN might require TLS to provide proper security. Updating 2131 the security consideration section will answer this question. 2133 20. Changes from Previous Versions 2135 Note to RFC Editor: Please remove this section prior to publication 2136 of this document as an RFC. 2138 This section lists the changes between the various versions of this 2139 specification. 2141 20.1. Changes from -08 to -09 2143 o Added text to properly define the ICMP attribute. This attribute 2144 was introduced in TURN-08, but not fully defined due to an 2145 oversight. Clarified that the attribute can appear in a Data 2146 indication, but not a Send indication. Added text to the section 2147 on receiving a Data indication that points out that this attribute 2148 may be present. 2150 o Changed the wording around the handling of the DSCP field to allow 2151 the server to set the DSCP to an arbitrary value if the next hop 2152 is a Diff-Serv classifier and marker. 2154 o When the server generates a 508 response due to an unsupported 2155 flag in the REQUESTED-PROPS attribute, the server now includes the 2156 REQUESTED-PROPS attribute in the response with all the flags it 2157 supports set to 1. This allows the client to see if the server 2158 does not understand one of its flags. Similarly, the client is 2159 now allowed to immediately retry the request if it modifies the 2160 included REQUESTED-PROPS attribute. 2162 o Clarified that the REQUESTED-PROPS attribute can be used in 2163 conjunction with the RESERVATION-TOKEN attribute as long as both 2164 the E and R bits are 0. The spec previously contradicted itself 2165 on this point. 2167 o Clarified that when the server receives a ChannelData message with 2168 a length field of 0, it sends a UDP Datagram to the peer that 2169 contains no application data. 2171 o Rewrote some text around relaying incoming UDP Datagrams to avoid 2172 duplication of text in the Data indication and Channel sections. 2174 o Added a note that points out that the on-going work on randomizing 2175 port allocations [I-D.ietf-tsvwg-port-randomization] may be 2176 applicable to TURN. 2178 o Clarified that the Allocate request containing a RESERVATION-TOKEN 2179 attribute can use any 5-tuple, and that 5-tuple need not have any 2180 specific relationship to the 5-tuple of the Allocate request that 2181 created the reservation. 2183 o Added a note that discusses retransmitted Allocate requests over 2184 UDP where the first request receives a failure response, but the 2185 second receives a success response. The server may elect to 2186 remember transmitted failure responses to avoid this situation. 2188 o Added text about the usage of the SOFTWARE-TYPE attribute 2189 (formerly known as the SERVER attribute) in TURN messages. 2191 o Rewrote the text in the Overview that motivates why TURN supports 2192 TCP and TLS between the client and the server. The previous text 2193 had been identified by various readers as inadequate and 2194 misleading. 2196 o Rewrote the section how a server handles a Refresh request to 2197 clarify processing in various error conditions. The new text 2198 makes it clear that it is OK to delete a non-existent allocation. 2199 It also clarifies how to handle retransmissions of Refresh 2200 requests over UDP. 2202 o Renamed the "RELAY-ADDRESS" attribute to "RELAYED-ADDRESS", since 2203 the text consistently uses the term "relayed transport address" 2204 for the concept and ICE uses the term "relayed candidate". 2206 o Changed the codepoint assigned to the error code "Wrong 2207 Credentials" from 438 to 441 to avoid a conflict with the "Stale 2208 Nonce" error code of STUN. 2210 o Changed the text to consistently use non-capitalized "request", 2211 "response" and "indication", except in headings, error code names, 2212 etc. 2214 o Added a note mentioning that TURN packets can be demuxed from 2215 other packets arriving on the same socket by looking at the 2216 5-tuple of the arriving packet. 2218 o Clarified that there are no required attributes is a ChannelBind 2219 success response. 2221 20.2. Changes from -07 to -08 2223 o Removed the BANDWIDTH attribute and all associated text (including 2224 error code 507 "Insufficient Bandwidth Capacity"), as the 2225 requirements for this feature were not clear and it was felt the 2226 feature could be easily added later. 2228 o Changed the format of the REQUESTED-PROPS attribute from a one- 2229 byte field to a set of bit flags. Changed the semantics of the 2230 unused portion of the value from RFFU to "MUST be 0" to give a 2231 more desirable behavior when new flags are defined. 2233 o Introduced the concept of Preserving vs. Non-Preserving 2234 allocations. As a result, completely revamped the rules for how 2235 to set the fields in the IP header, and added rules for relaying 2236 ICMP messages when the allocation is Preserving. 2238 20.3. Changes from -06 to -07 2240 o Rewrote the General Behavior section, making various changes in 2241 the process. 2243 o Changed the usage of authentication from MUST to SHOULD. 2245 o Changed the requirement that subsequent requests use the same 2246 username and password from MUST to SHOULD to allow for the 2247 possibility of changing the credentials using some unspecified 2248 mechanism. 2250 o Introduced a 438 (Wrong Credentials) error which is used when a 2251 non-Allocate request authenticates but does not use the same 2252 username and password as the Allocate request. Having a separate 2253 error code for this case avoids the client being confused over 2254 what the error actually is. 2256 o The server must now prevent the relayed transport address and the 2257 5-tuple from being reused in different allocations for 2 minutes 2258 after the allocation expires. 2260 o Changed the usage of FINGERPRINT from MUST NOT to MAY, to allow 2261 for the possible multiplexing of TURN with some other protocol. 2263 o Rewrote much of the section on Allocations, splitting it into 2264 three new sections (one on allocations in general, one on creating 2265 an allocation, and one on refreshing an allocation). 2267 o Replaced the mechanism for requesting relayed transport addresses 2268 with specific properties. The new mechanism is less powerful: a 2269 client can request an even port, or a pair of ports, but cannot 2270 request a single odd port or a specific port as was possible under 2271 the old mechanism. Nor can the client request a specific IP 2272 address. 2274 o Changed the rules for handling ALTERNATE-SERVER, removing the 2275 requirement that the referring server have "positive knowledge" 2276 about the state of the alternate server. The new rules instead 2277 rely on text in STUN to prevent referral loops. 2279 o Changed the rules for allocation lifetimes. Allocations lifetimes 2280 are now a minimum of 10 minutes; the client can ask for longer 2281 values, but requests for shorter values are ignored. The text now 2282 recommends that the client refresh an allocation one minute before 2283 it expires. 2285 o Put in temporary procedures for handling the BANDWIDTH attribute, 2286 modelled on the LIFETIME attribute. These procedures are mostly 2287 placeholders and likely to change in the next revision. 2289 o Added a detailed description of how a client reacts to the various 2290 errors it can receive in reply to an Allocate request. This 2291 replaces the various descriptions that were previously scattered 2292 throughout the document, which were inconsistent and sometimes 2293 contradictory. 2295 o Added a new section that gives the normative rules for 2296 permissions. 2298 o Changed the rules around permission lifetimes. The text used to 2299 recommend a value of one minute; it MUST now be 5 minutes. 2301 o Removed the errors "Channel Missing or Invalid", "Peer Address 2302 Missing or Invalid" and "Lifetime Malformed or Invalid" and used 2303 400 "Bad Request" instead. 2305 o Rewrote portions of the section on Send and Data indications and 2306 the section on Channels to try to make the client vs. server 2307 behavior clearer. 2309 o Channel bindings now expire after 10 minutes, and must be 2310 refreshed to keep them alive. 2312 o Binding a channel now installs or refreshes a permission for the 2313 IP address of corresponding peer. 2315 o Changed the wording describing the situation when the client sends 2316 a ChannelData message before receiving the ChannelBind success 2317 response. -06 said that client SHOULD NOT do this; -07 now says 2318 that a client MAY, but describes the consequences of doing it. 2320 o Added a section discussing the setting of fields in the IP header. 2322 o Replaced the REQUESTED-PORT-PROPS attribute with the REQUESTED- 2323 PROPS attribute that has a different format and semantics, but 2324 reuses the same code point. 2326 o Replaced the REQUESTED-IP attribute with the RESERVATION-TOKEN 2327 attribute, which has a different format and semantics, but reuses 2328 the same code point. 2330 o Removed error codes 443 and 444, and replaced them with 508 2331 (Insufficient Port Capacity). Also changed the error text for 2332 code 507 from "Insufficient Capacity" to "Insufficient Bandwidth 2333 Capacity". 2335 20.4. Changes from -05 to -06 2337 o Changed the mechanism for allocating channels to the one proposed 2338 by Eric Rescorla at the Dec 2007 IETF meeting. 2340 o Removed the framing mechanism (which was used to frame all 2341 messages) and replaced it with the ChannelData message. As part 2342 of this change, noted that the demux of ChannelData messages from 2343 TURN messages can be done using the first two bits of the message. 2345 o Rewrote the sections on transmitted and receiving data as a result 2346 of the above to changes, splitting it into a section on Send and 2347 Data indications and a separate section on channels. 2349 o Clarified the handling of Allocate request messages. In 2350 particular, subsequent Allocate request messages over UDP with the 2351 same transaction id are not an error but a retransmission. 2353 o Restricted the range of ports available for allocation to the 2354 Dynamic and/or Private Port range, and noted when ports outside 2355 this range can be used. 2357 o Changed the format of the REQUESTED-TRANSPORT attribute. The 2358 previous version used 00 for UDP and 01 for TCP; the new version 2359 uses protocol numbers from the IANA protocol number registry. The 2360 format of the attribute also changed. 2362 o Made a large number of changes to the non-normative portion of the 2363 document to reflect technical changes and improve the 2364 presentation. 2366 o Added the Issues section. 2368 20.5. Changes from -04 to -05 2370 o Removed the ability to allocate addresses for TCP relaying. This 2371 is now covered in a separate document. However, communication 2372 between the client and the server can still run over TCP or TLS/ 2373 TCP. This resulted in the removal of the Connect method and the 2374 TIMER-VAL and CONNECT-STAT attributes. 2376 o Added the concept of channels. All communication between the 2377 client and the server flows on a channel. Channels are numbered 2378 0..65535. Channel 0 is used for TURN messages, while the 2379 remaining channels are used for sending unencapsulated data to/ 2380 from a remote peer. This concept adds a new Channel Confirmation 2381 method and a new CHANNEL-NUMBER attribute. The new attribute is 2382 also used in the Send and Data methods. 2384 o The framing mechanism formally used just for stream-oriented 2385 transports is now also used for UDP, and the former Type and 2386 Reserved fields in the header have been replaced by a Channel 2387 Number field. The length field is zero when running over UDP. 2389 o TURN now runs on its own port, rather than using the STUN port. 2390 The use of channels requires this. 2392 o Removed the SetActiveDestination concept. This has been replaced 2393 by the concept of channels. 2395 o Changed the allocation refresh mechanism. The new mechanism uses 2396 a new Refresh method, rather than repeating the Allocation 2397 transaction. 2399 o Changed the syntax of SRV requests for secure transport. The new 2400 syntax is "_turns._tcp" rather than the old "_turn._tls". This 2401 change mirrors the corresponding change in STUN SRV syntax. 2403 o Renamed the old REMOTE-ADDRESS attribute to PEER-ADDRESS, and 2404 changed it to use the XOR-MAPPED-ADDRESS format. 2406 o Changed the RELAY-ADDRESS attribute to use the XOR-MAPPED-ADDRESS 2407 format (instead of the MAPPED-ADDRESS format)). 2409 o Renamed the 437 error code from "No Binding" to "Allocation 2410 Mismatch". 2412 o Added a discussion of what happens if a client's public binding on 2413 its outermost NAT changes. 2415 o The document now consistently uses the term "peer" as the name of 2416 a remote endpoint with which the client wishes to communicate. 2418 o Rewrote much of the document to describe the new concepts. At the 2419 same time, tried to make the presentation clearer and less 2420 repetitive. 2422 21. Open Issues 2424 NOTE to RFC Editor: Please remove this section prior to publication 2425 of this document as an RFC. 2427 Bandwidth: How should bandwidth be specified? What are the right 2428 rules around bandwidth? 2430 Alternate Server: Do we still want this mechanism? Is the current 2431 proposal acceptable? Note that the usage of the ALTERNATE-SERVER 2432 attribute in this document is inconsistent with its usage in STUN. 2433 In STUN, if the ALTERNATE-SERVER attribute is used, then the error 2434 that the server would otherwise generate is replaced by a 300 (Try 2435 Alternate) code. In this document, the 300 error code is not used, 2436 and the server returns an appropriate error code and then includes 2437 the ALTERNATE-SERVER attribute in the response. In this way, the 2438 client can see the actual error code, rather than always seeing error 2439 code 300, and can thus make a more intelligent decision on whether it 2440 wishes to try the alternate server. 2442 Public TURN servers: The text currently says that a server "SHOULD" 2443 use the Long-Term Credential mechanism, with the unstated idea that a 2444 public TURN server would not use it. But this really weakens the 2445 security of TURN. Is there a better way to allow public servers? Or 2446 should we just drop the notion of a public server entirely? 2448 22. Acknowledgements 2450 The authors would like to thank the various participants in the 2451 BEHAVE working group for their many comments on this draft. Marc 2452 Petit-Huguenin, Remi Denis-Courmont, Derek MacDonald, Cullen 2453 Jennings, Lars Eggert, Magnus Westerlund, and Eric Rescorla have been 2454 particularly helpful, with Eric also suggesting the channel 2455 allocation mechanism, and Cullen suggesting the REQUESTED-PROPS 2456 mechanism. Christian Huitema was an early contributor to this 2457 document and was a co-author on the first few drafts. Finally, the 2458 authors would like to thank Dan Wing for both his contributions to 2459 the text and his huge help in restarting progress on this draft after 2460 work had stalled. 2462 23. References 2464 23.1. Normative References 2466 [I-D.ietf-behave-rfc3489bis] 2467 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2468 "Session Traversal Utilities for (NAT) (STUN)", 2469 draft-ietf-behave-rfc3489bis-16 (work in progress), 2470 July 2008. 2472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2473 Requirement Levels", BCP 14, RFC 2119, March 1997. 2475 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2476 "Definition of the Differentiated Services Field (DS 2477 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2478 December 1998. 2480 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 2481 "IPv6 Flow Label Specification", RFC 3697, March 2004. 2483 23.2. Informative References 2485 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2486 E. Lear, "Address Allocation for Private Internets", 2487 BCP 5, RFC 1918, February 1996. 2489 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2490 for IP version 6", RFC 1981, August 1996. 2492 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2493 with Session Description Protocol (SDP)", RFC 3264, 2494 June 2002. 2496 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2497 December 2005. 2499 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2500 RFC 4303, December 2005. 2502 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 2503 Self-Address Fixing (UNSAF) Across Network Address 2504 Translation", RFC 3424, November 2002. 2506 [I-D.ietf-mmusic-ice] 2507 Rosenberg, J., "Interactive Connectivity Establishment 2508 (ICE): A Protocol for Network Address Translator (NAT) 2509 Traversal for Offer/Answer Protocols", 2510 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 2512 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2513 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2514 RFC 4787, January 2007. 2516 [I-D.ietf-behave-turn-tcp] 2517 Rosenberg, J. and R. Mahy, "Traversal Using Relays around 2518 NAT (TURN) Extensions for TCP Allocations", 2519 draft-ietf-behave-turn-tcp-00 (work in progress), 2520 November 2007. 2522 [I-D.ietf-behave-turn-ipv6] 2523 Camarillo, G. and O. Novo, "Traversal Using Relays around 2524 NAT (TURN) Extension for IPv4/IPv6 Transition", 2525 draft-ietf-behave-turn-ipv6-04 (work in progress), 2526 January 2008. 2528 [I-D.ietf-tsvwg-udp-guidelines] 2529 Eggert, L. and G. Fairhurst, "Guidelines for Application 2530 Designers on Using Unicast UDP", 2531 draft-ietf-tsvwg-udp-guidelines-09 (work in progress), 2532 July 2008. 2534 [I-D.ietf-tsvwg-port-randomization] 2535 Larsen, M. and F. Gont, "Port Randomization", 2536 draft-ietf-tsvwg-port-randomization-01 (work in progress), 2537 February 2008. 2539 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2540 November 1990. 2542 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2543 Discovery", RFC 4821, March 2007. 2545 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 2546 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 2547 March 1996. 2549 [Port-Numbers] 2550 "IANA Port Numbers Registry", 2551 . 2553 [Protocol-Numbers] 2554 "IANA Protocol Numbers Registry", 2005, 2555 . 2557 Authors' Addresses 2559 Jonathan Rosenberg 2560 Cisco Systems, Inc. 2561 Edison, NJ 2562 USA 2564 Email: jdrosen@cisco.com 2565 URI: http://www.jdrosen.net 2567 Rohan Mahy 2568 Plantronics, Inc. 2570 Email: rohan@ekabal.com 2572 Philip Matthews 2573 (Unaffiliated) 2575 Fax: 2576 Email: philip_matthews@magma.ca 2577 URI: 2579 Full Copyright Statement 2581 Copyright (C) The IETF Trust (2008). 2583 This document is subject to the rights, licenses and restrictions 2584 contained in BCP 78, and except as set forth therein, the authors 2585 retain all their rights. 2587 This document and the information contained herein are provided on an 2588 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2589 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2590 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2591 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2592 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2595 Intellectual Property 2597 The IETF takes no position regarding the validity or scope of any 2598 Intellectual Property Rights or other rights that might be claimed to 2599 pertain to the implementation or use of the technology described in 2600 this document or the extent to which any license under such rights 2601 might or might not be available; nor does it represent that it has 2602 made any independent effort to identify any such rights. Information 2603 on the procedures with respect to rights in RFC documents can be 2604 found in BCP 78 and BCP 79. 2606 Copies of IPR disclosures made to the IETF Secretariat and any 2607 assurances of licenses to be made available, or the result of an 2608 attempt made to obtain a general license or permission for the use of 2609 such proprietary rights by implementers or users of this 2610 specification can be obtained from the IETF on-line IPR repository at 2611 http://www.ietf.org/ipr. 2613 The IETF invites any interested party to bring to its attention any 2614 copyrights, patents or patent applications, or other proprietary 2615 rights that may cover technology that may be required to implement 2616 this standard. Please address the information to the IETF at 2617 ietf-ipr@ietf.org.