idnits 2.17.1 draft-ietf-behave-turn-06.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 1910. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1921. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1934. 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 (January 22, 2008) is 5937 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 450, but not defined == Missing Reference: '3489bis' is mentioned on line 1089, but not defined == Missing Reference: 'RFC 768' is mentioned on line 1183, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-13 -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) == Outdated reference: A later version (-07) exists of draft-ietf-behave-turn-tcp-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track R. Mahy 5 Expires: July 25, 2008 Plantronics 6 P. Matthews 7 Avaya 8 January 22, 2008 10 Traversal Using Relays around NAT (TURN): Relay Extensions to Session 11 Traversal Utilities for NAT (STUN) 12 draft-ietf-behave-turn-06 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 July 25, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 If a host is located behind a NAT, then in certain situations it can 46 be impossible for that host to communicate directly with other hosts 47 (peers) located behind other NATs. In these situations, it is 48 necessary for the host to use the services of an intermediate node 49 that acts as a communication relay. This specification defines a 50 protocol, called TURN (Traversal Using Relays around NAT), that 51 allows the host to control the operation of the relay and to exchange 52 packets with its peers using the relay. 54 The TURN protocol can be used in isolation, but is more properly used 55 as part of the ICE (Interactive Connectivity Establishment) approach 56 to NAT traversal. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.3. Exchanging Data with Peers . . . . . . . . . . . . . . . . 9 65 2.4. Permissions . . . . . . . . . . . . . . . . . . . . . . . 10 66 2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4. General Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 69 5. Managing Allocations . . . . . . . . . . . . . . . . . . . . . 14 70 5.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 14 71 5.1.1. Initial Allocate Requests . . . . . . . . . . . . . . 14 72 5.1.2. Refresh Requests . . . . . . . . . . . . . . . . . . . 15 73 5.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 16 74 5.2.1. Receiving an Allocate Request . . . . . . . . . . . . 16 75 5.2.2. Refresh Requests . . . . . . . . . . . . . . . . . . . 20 76 6. Send and Data Indications . . . . . . . . . . . . . . . . . . 21 77 6.1. Forming and Sending an Indication . . . . . . . . . . . . 21 78 6.2. Receiving an Indication . . . . . . . . . . . . . . . . . 22 79 6.3. Relaying . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 7. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . 23 81 7.1. Forming and Sending a ChannelBind Request . . . . . . . . 23 82 7.2. Receiving a ChannelBind Request and Sending a Response . . 24 83 7.3. Receiving a ChannelBind Response . . . . . . . . . . . . . 25 84 7.4. The ChannelData Message . . . . . . . . . . . . . . . . . 25 85 7.5. Forming and Sending a ChannelData Message . . . . . . . . 25 86 7.6. Receiving a ChannelData Message . . . . . . . . . . . . . 26 87 7.7. Relaying . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 8. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . . 27 89 9. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 27 90 9.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . . 28 91 9.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 9.3. BANDWIDTH . . . . . . . . . . . . . . . . . . . . . . . . 28 93 9.4. PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . . 28 94 9.5. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 9.6. RELAY-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 28 96 9.7. REQUESTED-PORT-PROPS . . . . . . . . . . . . . . . . . . . 28 97 9.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 30 98 9.9. REQUESTED-IP . . . . . . . . . . . . . . . . . . . . . . . 30 99 10. New STUN Error Response Codes . . . . . . . . . . . . . . . . 30 100 11. Client Discovery of TURN Servers . . . . . . . . . . . . . . . 31 101 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 102 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 103 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 34 104 15. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 105 16. Changes from Previous Versions . . . . . . . . . . . . . . . . 35 106 16.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 35 107 16.2. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 35 108 17. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 109 17.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 37 110 17.2. Closed Issues . . . . . . . . . . . . . . . . . . . . . . 39 111 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 112 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 113 19.1. Normative References . . . . . . . . . . . . . . . . . . . 40 114 19.2. Informative References . . . . . . . . . . . . . . . . . . 40 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 116 Intellectual Property and Copyright Statements . . . . . . . . . . 43 118 1. Introduction 120 NOTE TO THE READER: This document is a work-in-progress. Please see 121 the list of open and closed issues in Section 17. With only a few 122 exceptions, if there is an open issue the text has NOT been updated 123 in this area pending resolution of this issue - keep this in mind 124 when reading the text. In addition, in the interest of getting the 125 document out quickly in order to make progress on open issues, the 126 authors have elected to release the document is a bit more "raw" 127 state than they would prefer, resulting in some rough spots in the 128 presentation. 130 Session Traversal Utilities for NAT (STUN) 131 [I-D.ietf-behave-rfc3489bis] provides a suite of tools for 132 facilitating the traversal of NAT. Specifically, it defines the 133 Binding method, which is used by a client to determine its reflexive 134 transport address towards the STUN server. The reflexive transport 135 address can be used by the client for receiving packets from peers, 136 but only when the client is behind "good" NATs. In particular, if a 137 client is behind a NAT whose mapping behavior [RFC4787] is address or 138 address and port dependent (sometimes called "bad" NATs), the 139 reflexive transport address will not be usable for communicating with 140 a peer. 142 The only way to obtain a UDP transport address that can be used for 143 corresponding with a peer through such a NAT is to make use of a 144 relay. The relay sits on the public side of the NAT, and allocates 145 transport addresses to clients reaching it from behind the private 146 side of the NAT. These allocated transport addresses are from IP 147 addresses belonging to the relay. When the relay receives a packet 148 on one of these allocated addresses, the relay forwards it toward the 149 client. 151 This specification defines an extension to STUN, called TURN, that 152 allows a client to request an address on the TURN server, so that the 153 TURN server acts as a relay. This extension defines a handful of new 154 STUN methods. The Allocate method is the most fundamental component 155 of this set of extensions. It is used to provide the client with a 156 transport address that is relayed through the TURN server. A 157 transport address which relays through an intermediary is called a 158 relayed transport address. 160 Though a relayed transport address is highly likely to work when 161 corresponding with a peer, it comes at high cost to the provider of 162 the relay service. As a consequence, relayed transport addresses 163 should only be used as a last resort. Protocols using relayed 164 transport addresses should make use of mechanisms to dynamically 165 determine whether such an address is actually needed. One such 166 mechanism, defined for multimedia session establishment protocols 167 based on the offer/answer protocol in RFC 3264 [RFC3264], is 168 Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice]. 170 Though originally invented for Voice over IP applications, TURN is 171 designed to be a general-purpose relay mechanism for NAT traversal. 173 2. Overview of Operation 175 This section gives an overview of the operation of TURN. It is non- 176 normative. 178 In a typical configuration, a TURN client is connected to a private 179 network [RFC1918] and through one or more NATs to the public 180 Internet. On the public Internet is a TURN server. Elsewhere in the 181 Internet are one or more peers that the TURN client wishes to 182 communicate with. These peers may or may not be behind one or more 183 NATs. 185 +---------+ 186 | | 187 | | 188 / | Peer A | 189 Client's TURN // | | 190 Host Transport Server / | | 191 Address Address +-+ // +---------+ 192 10.1.1.2:17240 192.0.2.15:3478 |N|/ 192.168.100.2:16400 193 | | |A| 194 | +-+ | /|T| 195 | | | | / +-+ 196 v | | | / 192.0.2.210:18200 197 +---------+ | | |+---------+ / +---------+ 198 | | |N| || | // | | 199 | TURN | | | v| TURN |/ | | 200 | Client |----|A|----------| Server |------------------| Peer B | 201 | | | |^ | |^ ^| | 202 | | |T|| | || || | 203 +---------+ | || +---------+| |+---------+ 204 | || | | 205 | || | | 206 +-+| | | 207 | | | 208 | | | 209 Client's | Peer B 210 Server-Reflexive Relayed Transport 211 Transport Address Transport Address Address 212 192.0.2.1:7000 192.0.2.15:9000 192.0.2.210:18200 214 Figure 1 216 Figure 1 shows a typical deployment. In this figure, the TURN client 217 and the TURN server are separated by a NAT, with the client on the 218 private side and the server on the public side of the NAT. This NAT 219 is assumed to be a "bad" NAT; for example, it might have a mapping 220 property of address-and-port-dependent mapping (see [RFC4787]) for a 221 description of what this means). 223 The client has allocated a local port on one of its addresses for use 224 in communicating with the server. The combination of an IP address 225 and a port is called a TRANSPORT ADDRESS and since this (IP address, 226 port) combination is located on the client and not on the NAT, it is 227 called the client's HOST transport address. 229 The client sends TURN messages from its host transport address to a 230 transport address on the TURN server which is known as the TURN 231 SERVER ADDRESS. The client learns the server's address through some 232 unspecified means (e.g., configuration), and this address is 233 typically used by many clients simultaneously. The TURN server 234 address is used by the client to send both commands and data to the 235 server; the commands are processed by the TURN server, while the data 236 is relayed on to the peers. 238 Since the client is behind a NAT, the server sees these packets as 239 coming from a transport address on the NAT itself. This address is 240 known as the client's SERVER-REFLEXIVE transport address; packets 241 sent by the server to the client's server-reflexive transport address 242 will be forwarded by the NAT to the client's host transport address. 244 The client uses TURN commands to allocate a RELAYED transport 245 address, which is an transport address located on the server. The 246 server ensures that there is a one-to-one relationship between the 247 client's server-reflexive transport address and the relayed transport 248 address; thus a packet received at the relayed transport address can 249 be unambiguously relayed by the server to the client. 251 The client will typically communicate this relayed transport address 252 to one or more peers through some mechanism not specified here (e.g., 253 an ICE offer or answer [I-D.ietf-mmusic-ice]). Once this is done, 254 peers can send data packets to the relayed transport address and the 255 server will forward them to the client. In the reverse direction, 256 the client can send data packets to the server (at its TURN server 257 address) and these will be forwarded by the server to the appropriate 258 peer, and the peer will see them as coming from the relayed transport 259 address; in this direction, the client must specify the appropriate 260 peer. 262 2.1. Transports 264 TURN as defined in this specification only allows the use of UDP 265 between the server and the peer. However, this specification allows 266 the use of any one of UDP, TCP, or TLS over TCP to carry the TURN 267 messages between the client and the server. 269 +----------------------------+---------------------+ 270 | TURN client to TURN server | TURN server to peer | 271 +----------------------------+---------------------+ 272 | UDP | UDP | 273 | TCP | UDP | 274 | TLS over TCP | UDP | 275 +----------------------------+---------------------+ 277 For TURN clients, using TLS over TCP to communicate with the TURN 278 server provides two benefits. First, the client can be assured that 279 the addresses of its peers are not visible to any attackers between 280 it and the server. Second, the client may be able to communicate 281 with TURN servers using TLS when it would not be able to communicate 282 with the same server using TCP or UDP, due to the policy of a 283 firewall between the TURN client and its server. In this second 284 case, TLS between the client and TURN server facilitates traversal. 286 There is a planned extension to TURN to add support for TCP between 287 the server and the peers [I-D.ietf-behave-turn-tcp]. For this 288 reason, allocations that use UDP between the server and the peers are 289 known as UDP allocations, while allocations that use TCP between the 290 server and the peers are known as TCP allocations. This 291 specification describes only UDP allocations. 293 2.2. Allocations 295 To allocate a relayed transport address, the client uses an Allocate 296 transaction. The client sends a Allocate Request to the server, and 297 the server replies with an Allocate Response containing the allocated 298 relayed transport address. The client can include attributes in the 299 Allocate Request that describe the type of allocation it desires 300 (e.g., the lifetime of the allocation). And since relaying data can 301 require lots of bandwidth, the server may require that the client 302 authenticate itself using STUN's long-term credential mechanism, to 303 show that it is authorized to use the server. 305 Once a relayed transport address is allocated, a client must keep the 306 allocation alive. This is done by the client periodically doing a 307 Refresh transaction with the server, where the client includes the 308 allocated relayed transport address in the Refresh Request. TURN 309 deliberately uses a different method (Refresh rather than Allocate) 310 for refreshes to ensure that the client is informed if the allocation 311 vanishes for some reason. 313 The frequency of the Refresh transaction is determined by the 314 lifetime of the allocation. The client can request a lifetime in the 315 Allocate Request and may modify its request in a Refresh Request, and 316 the server always indicates the actual lifetime in the response. The 317 client must issue a new Refresh transaction within 'lifetime' seconds 318 of the previous Allocate or Refresh transaction. If a client no 319 longer wishes to use an Allocation, it should do a Refresh 320 transaction with a requested lifetime of 0. 322 Note that sending or receiving data from a peer DOES NOT refresh the 323 allocation. 325 The server remembers the 5-tuple used in the Allocate Request. 326 Subsequent transactions between the client and the server use this 327 same 5-tuple. In this way, the server knows which client owns the 328 allocated relayed transport address. If the client wishes to 329 allocate a second relayed transport address, it must use a different 330 5-tuple for this allocation (e.g., by using a different client host 331 address). 333 While the terminology used in this document refers to 5-tuples, 334 the TURN server can store whatever identifier it likes that yields 335 identical results. Specifically, many implementations use a file- 336 descriptor in place of a 5-tuple to represent a TCP connection. 338 2.3. Exchanging Data with Peers 340 The client can use the relayed transport address to exchange data 341 with its peers by using Send and Data indications. A Send Indication 342 is sent from a client to the TURN server and contains, in attributes 343 inside the message, the transport address of the peer and the data to 344 be sent to that peer. When the TURN server receives the Send 345 Indication, it extracts the data from the Send Indication and sends 346 it in a UDP datagram to the peer, using the allocated relay address 347 as the source address. In the reverse direction, UDP datagrams 348 arriving at the relay address on the TURN server are converted into 349 Data Indications and sent to the client, with the transport address 350 of the peer included in an attribute in the Data Indication. 352 Note that a client can use a single relayed transport address to 353 exchange data with multiple peers at the same time. 354 TURN TURN Peer Peer 355 client server A B 356 |--- Allocate Req -->| | | 357 |<-- Allocate Resp ---| | | 358 | | | | 359 |--- Send (Peer A)--->| | | 360 | |=== data ===>| | 361 | | | | 362 | |<== data ====| | 363 |<-- Data (Peer A)----| | | 364 | | | | 365 |--- Send (Peer B)--->| | | 366 | |=== data =================>| 367 | | | | 368 | |<== data ==================| 369 |<-- Data (Peer B)----| | | 371 Figure 2 373 In the figure above, the client first allocates a relayed transport 374 address. It then sends data to Peer A using a Send Indication; at 375 the server, the data is extracted and forwarded in a UDP datagram to 376 Peer A, using the relayed transport address as the source transport 377 address. When a UDP datagram from Peer A is received at the relayed 378 transport address, the contents are placed into a Data Indication and 379 forwarded to the client. A similar exchange happens with Peer B. 381 2.4. Permissions 383 To ease concerns amongst enterprise IT administrators that TURN could 384 be used to bypass corporate firewall security, TURN includes the 385 notion of permissions. TURN permissions mimic the address-restricted 386 filtering mechanism of NATs that comply with [RFC4787]. 388 A TURN server will drop a UDP datagram arriving at a relayed 389 transport address from a peer unless the client has recently sent 390 data to a peer with the same IP address (the port numbers can 391 differ). See the normative description for the precise definition of 392 "recently". 394 A permission will timeout if not refreshed periodically. The client 395 refreshes a permission by sending data to the corresponding peer. 396 Data received from the peer DOES NOT refresh the permission. 398 2.5. Channels 400 In some applications, the overhead of using Send and Data indications 401 can be substantial. For example, for applications like VoIP which 402 utilize small packets, Send and Data Indications, with 36 bytes of 403 overhead, can have a substantial impact on overall bandwidth usage. 404 To remedy this, TURN clients can assign a CHANNEL to a peer. Data to 405 and from such a peer can then be sent using an alternate packet 406 format that adds only 4 bytes per packet of overhead. 408 The alternate packet format is known as the ChannelData message. The 409 ChannelData message does not use the STUN header used by other TURN 410 messages, but instead has a 4-byte header that includes a number 411 known as a channel number. 413 To create a channel, the client sends a ChannelBind request to the 414 server, and includes an unallocated channel number and the transport 415 address of the peer. Once the client receives the response to the 416 ChannelBind request, it can send data to that peer using a 417 ChannelData message. Similarly, once the server has received the 418 request, it can relay data from that peer towards the client using a 419 ChannelData message. There is no way to modify channel bindings, so 420 once a channel is bound to a peer, it remains bound for the lifetime 421 of the allocation. 423 When the server receives a ChannelData message from the client, it 424 uses the channel number to determine the destination peer and then 425 forwards the data inside a UDP datagram to the peer. In the reverse 426 direction, when a UDP datagram arives at the relayed transport 427 address from that peer, the server inserts it into a ChannelData 428 message containing the channel number bound to that peer; in this way 429 the client can determine the peer that send the UDP datagram. 430 TURN TURN Peer Peer 431 client server A B 432 |--- Allocate Req -->| | | 433 |<-- Allocate Resp ---| | | 434 | | | | 435 |--- Send (Peer A)--->| | | 436 | |=== data ===>| | 437 | | | | 438 | |<== data ====| | 439 |<-- Data (Peer A)----| | | 440 | | | | 441 |- ChannelBind Req -->| | | 442 | (Peer A to 0x4001) | | | 443 | | | | 444 |<- ChannelBind Resp -| | | 445 | | | | 446 |-- [0x4001] data --->| | | 447 | |=== data ===>| | 448 | | | | 449 | |<== data ====| | 450 |<- [0x4001] data --->| | | 451 | | | | 452 |--- Send (Peer B)--->| | | 453 | |=== data =================>| 454 | | | | 455 | |<== data ==================| 456 |<-- Data (Peer B)----| | | 458 Figure 3 460 The figure above shows the channel mechanism in use. The client 461 begins by allocating a relayed transport address, and then uses that 462 address to exchange data with Peer A. After a bit, the client decides 463 to bind a channel to Peer A. To do this, it sends a ChannelBind 464 Request to the server, specifying the transport address of Peer A and 465 a channel number (0x4001). After that, the client can send 466 application data encapsulated inside ChannelData messages to Peer A: 467 this is shown as "[0x4001] data" where 0x4001 is the channel number. 469 Note that ChannelData messages can only be used for peers to which 470 the client has bound a channel. In the example above, Peer A has 471 been bound to a channel, but Peer B has not, so application data to 472 and from Peer B uses Send and Data indications. 474 Channel bindings are always initiated by the client. 476 3. Terminology 478 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 479 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 480 document are to be interpreted as described in RFC 2119 [RFC2119]. 482 Readers are expected to be familar with [I-D.ietf-behave-rfc3489bis] 483 and the terms defined there. 485 The following terms are used in this document: 487 TURN: A protocol spoken between a TURN client and a TURN server. It 488 is an extension to the STUN protocol [I-D.ietf-behave-rfc3489bis]. 489 The protocol allows a client to allocate and use a relayed 490 transport address. 492 TURN client: A STUN client that implements this specification. 494 TURN server: A STUN server that implements this specification. It 495 relays data between a TURN client and its peer(s). 497 Peer: A host with which the TURN client wishes to communicate. The 498 TURN server relays traffic between the TURN client and its 499 peer(s). The peer does not interact with the TURN server using 500 the protocol defined in this document; rather, the peer receives 501 data sent by the TURN server and the peer sends data towards the 502 TURN server. 504 Host Transport Address: A transport address allocated on a host. 506 Server-Reflexive Transport Address: A transport address on the 507 "public side" of a NAT. This address is allocated by the NAT to 508 correspond to a specific host transport address. 510 Relayed Transport Address: A transport address that exists on a TURN 511 server. If a permission exists, packets that arrive at this 512 address are relayed towards the TURN client. 514 Allocation: The transport address granted to a client through an 515 Allocate request, along with related state, such as permissions 516 and expiration timers. See also Relayed Transport Address. 518 5-tuple: A combination of the source IP address and port, 519 destination IP address and port, and transport protocol (UDP or 520 TCP). A 5-tuple uniquely identifies a TCP connection or the bi- 521 directional flow of UDP datagrams. 523 Permission: The IP address and transport protocol (but not the port) 524 of a peer that is permitted to send traffic to the TURN server and 525 have that traffic relayed to the TURN client. The TURN server 526 will only forward traffic to its client from peers that match an 527 existing permission. 529 4. General Behavior 531 After the initial Allocate transaction, all subsequent TURN 532 transactions need to be sent in the context of a valid allocation. 533 The source and destination IP address and ports for these TURN 534 messages MUST match the those used in the initial Allocate Request. 535 These are processed using the general server procedures in 536 [I-D.ietf-behave-rfc3489bis] with a few important additions. For 537 requests, if there is no matching allocation, the server MUST 538 generate a 437 (Allocation Mismatch) error response. For 539 indications, if there is no matching allocation, the indication is 540 silently discarded. An Allocate request MUST NOT be sent by a client 541 within the context of an existing allocation. Such a request MUST be 542 rejected by the server with a 437 (Allocation Mismatch) error 543 response. 545 A subsequent request MUST be authenticated using the same username, 546 password and realm as the one used in the Allocate request that 547 created the allocation. If the request was authenticated but not 548 with the matching credential, the server MUST reject the request with 549 a 401 (Unauthorized) error response. 551 When a server returns an error response, it MAY include an ALTERNATE- 552 SERVER attribute if it has positive knowledge that the problem 553 reported in the error response will not be a problem on the alternate 554 server. For example, a 443 response (Invalid IP Address) with an 555 ALTERNATE-SERVER means that the other server is responsible for that 556 IP address. A 442 (Unsupported Transport Protocol) with this 557 attribute means that the other server is known to support that 558 transport protocol. A 507 (Insufficient Capacity) means that the 559 other server is known to have sufficient capacity. Using the 560 ALTERNATE-SERVER mechanism in the 507 (Insufficient Capacity) 561 response can only be done if the rejecting server has definitive 562 knowledge of available capacity on the target. This will require 563 some kind of state sharing mechanism between TURN servers, which is 564 beyond the scope of this specification. If a TURN server attempts to 565 redirect to another server without knowledge of available capacity, 566 it is possible that all servers are in a congested state, resulting 567 in series of rejections that only serve to further increase the load 568 on the system. This can cause congestion collapse. 570 If a client sends a request to a server and gets a 500 class error 571 response without an ALTERNATE-SERVER, or the STUN transaction times 572 out without a response, and the client was utilizing the SRV 573 procedures of [I-D.ietf-behave-rfc3489bis] to contact the server, the 574 client SHOULD try another server based on those procedures. However, 575 the client SHOULD cache the fact that the request to this server 576 failed, and not retry that server again for a configurable period of 577 time. Five minutes is RECOMMENDED. 579 TURN clients and servers MUST NOT include the FINGERPRINT attribute 580 in any of the methods defined in this document. 582 5. Managing Allocations 584 Communications between a TURN client and a TURN server begin with an 585 Allocate transaction. All subsequent transactions happen in the 586 context of that allocation, and happen on the same 5-tuple. The 587 client refreshes allocations and deallocates them using a Refresh 588 transaction. 590 5.1. Client Behavior 592 5.1.1. Initial Allocate Requests 594 When a client wishes to obtain a transport address, it sends an 595 Allocate request to the server. This request is constructed and sent 596 using the general procedures defined in [I-D.ietf-behave-rfc3489bis]. 597 Clients MUST implement the long term credential mechanism defined in 598 [I-D.ietf-behave-rfc3489bis], and be prepared for the server to 599 demand credentials for requests. 601 The client SHOULD include a BANDWIDTH attribute, which indicates the 602 maximum bandwidth that will be used with this binding. If the 603 maximum is unknown, the attribute is not included in the request. 605 The client MAY request a particular lifetime for the allocation by 606 including it in the LIFETIME attribute in the request. 608 The client MUST include a REQUESTED-TRANSPORT attribute. In this 609 specification, the REQUESTED-TRANSPORT MUST always be UDP. This 610 attribute is included to allow for future extensions to TURN (e.g., 611 [I-D.ietf-behave-turn-tcp]) 612 The client MAY include a REQUESTED-PORT-PROPS or REQUESTED-IP 613 attribute in the request to obtain specific types of transport 614 addresses, if desired. 616 Processing of the response follows the general procedures of 617 [I-D.ietf-behave-rfc3489bis]. A successful response will include 618 both a RELAY-ADDRESS and an XOR-MAPPED-ADDRESS attribute, providing 619 both a relayed transport address and a reflexive transport address, 620 respectively, to the client. The value of the LIFETIME attribute in 621 the response indicates the amount of time after which the server will 622 expire the allocation, if not refreshed with a Refresh request. The 623 server will allow the user to send and receive at least the amount of 624 data indicated in the BANDWIDTH attribute per allocation. (At its 625 discretion the server can optionally discard UDP data above this 626 threshold.) 628 If the response is an error response and contains a 442, 443 or 444 629 error code, the client knows that its requested properties could not 630 be met. The client MAY retry with different properties, with the 631 same properties (in a hope that something has changed on the server), 632 or give up, depending on the needs of the application. However, if 633 the client retries, it SHOULD wait 500ms, and if the request fails 634 again, wait 1 second, then 2 seconds, and so on, exponentially 635 backing off. 637 5.1.2. Refresh Requests 639 TURN permissions are kept alive by traffic flowing through them, and 640 persist for the lifetime of the allocation. However, The allocations 641 themselves have to be kept alive through Refresh Requests. 643 Before 3/4 of the lifetime of the allocation has passed (the lifetime 644 of the allocation is conveyed in the LIFETIME attribute of the 645 Allocate Response), the client SHOULD refresh the allocation with a 646 Refresh transaction if it wishes to keep the allocation. 648 To perform a refresh, the client generates a Refresh Request. The 649 client MUST use the same username, realm and password for the Refresh 650 request as it used in its initial Allocate Request. The Refresh 651 request MAY contain a proposed LIFETIME attribute. The client MAY 652 include a BANDWIDTH attribute if it wishes to request more or less 653 bandwidth than in the original request (this might also be the first 654 time the TURN client indicates bandwidth to the TURN server). If the 655 BANDWIDTH attribute is absent, it indicates no change in the 656 requested bandwidth from the Allocate request. The client MUST NOT 657 include a REQUESTED-IP, REQUESTED-TRANSPORT, or REQUESTED-PORT-PROPS 658 attribute in the Refresh request. 660 In a successful response, the LIFETIME attribute indicates the amount 661 of additional time (the number of seconds after the response is 662 received) that the allocation will live without being refreshed. A 663 successful response will also contain a BANDWIDTH attribute, 664 indicating the bandwidth the server is allowing for this allocation. 665 Note that an error response does not imply that the allocation has 666 expired, just that the refresh has failed. 668 If a client no longer needs an allocation, it SHOULD perform an 669 explicit deallocation. If the client wishes to explicitly remove the 670 allocation because it no longer needs it, it sends a Refresh request, 671 but sets the LIFETIME attribute to zero. This will cause the server 672 to remove the allocation, and all associated permissions and channel 673 numbers. For connection-oriented transports such as TCP, the client 674 can also remove the allocation (and all associated bindings) by 675 closing the relevant connection with the TURN server. 677 5.2. Server Behavior 679 5.2.1. Receiving an Allocate Request 681 When the server receives an Allocate request, the server attempts to 682 allocate a relayed transport address. 684 When the server receives the Allocate Request, it begins by 685 processing it according to the base protocol procedures described in 686 [I-D.ietf-behave-rfc3489bis], plus the Long-Term Credential Mechanism 687 procedures if the server is using this mechanism. 689 It then checks if the 5-tuple used for the Allocate Request matches 690 the 5-tuple used for an existing allocation. If there is a match, 691 then: 693 o If the transport protocol is UDP, and the transaction id in the 694 request message matches the transaction id used for the original 695 allocation, then the server treats this as a retransmission of the 696 original request, and replies with the same response as it did to 697 the original request. The server may do this by either storing 698 its original response and resending it, or by rebuilding its 699 original response from other state data. 701 o If the transport protocol is not UDP, or if the transaction id in 702 the request message does not match the transaction id used for the 703 original allocation, then the server replies with an error 704 response containing the error code 437 Allocation Mismatch. 706 If the 5-tuple does not match an existing allocation, then processing 707 continues as described below. 709 5.2.1.1. BANDWIDTH 711 The server checks for the BANDWIDTH attribute in the request. If 712 present, the server determines whether or not it has sufficient 713 capacity to handle a binding that will generate the requested 714 bandwidth. 716 If it does, the server attempts to allocate a transport address for 717 the client. The Allocate Request can contain several additional 718 attributes that allow the client to request specific characteristics 719 of the transport address. If it doesn't, it sends an error response. 721 5.2.1.2. REQUESTED-TRANSPORT 723 The server checks for the REQUESTED-TRANSPORT attribute. This 724 indicates the transport protocol requested by the client. This 725 specification defines a value for UDP only, but support for TCP 726 allocations is planned in [I-D.ietf-behave-turn-tcp]. 728 As a consequence of the REQUESTED-TRANSPORT attribute, it is 729 possible for a client to connect to the server over TCP or TLS 730 over TCP and request a UDP transport address. In this case, the 731 server will relay data between the transports. 733 If the requested transport is supported, the server allocates a port 734 using the requested transport protocol. If the REQUESTED-TRANSPORT 735 attribute contains a value of the transport protocol unknown to the 736 server, or known to the server but not supported by the server in the 737 context of this request, the server MUST reject the request and 738 include a 442 (Unsupported Transport Protocol) in the response. If 739 the request did not contain a REQUESTED-TRANSPORT attribute, the 740 server MUST use the same transport protocol as the request arrived 741 on. 743 5.2.1.3. REQUESTED-IP 745 The server checks for the REQUESTED-IP attribute. If present, it 746 indicates a specific IP address from which the client would like its 747 transport address allocated. (The client could do this if it 748 requesting the second address in a specific port pair). If this IP 749 address is not a valid one for allocations on the server, the server 750 MUST reject the request and include a 443 (Invalid IP Address) error 751 code in the response, or else redirect the request to a server that 752 is known to support this IP address. If the IP address is one that 753 is valid for allocations (presumably, the server is configured to 754 know the set of IP addresses from which it performs allocations), the 755 server MUST provide an allocation from that IP address. If the 756 attribute is not present, the selection of an IP address is at the 757 discretion of the server. 759 5.2.1.4. REQUESTED-PORT-PROPS 761 The server checks for the REQUESTED-PORT-PROPS attribute. If 762 present, it indicates specific port properties desired by the client. 763 This attribute is split into two portions: one portion for port 764 behavior and the other for requested port alignment (whether the 765 allocated port is odd, even, reserved as a pair, or at the discretion 766 of the server). 768 If the port behavior requested is for a Specific Port, the server 769 MUST attempt to allocate that specific port for the client. If the 770 specific port is not available (in use or reserved), the server MUST 771 reject the request with a 444 (Invalid Port) response. For example, 772 the STUN server could reject a request for a Specific Port because 773 the port is temporarily reserved as part of an adjacent pair of 774 ports, or because the requested port is a well-known port (1-1023). 776 If the client requests "even" port alignment, the server MUST attempt 777 to allocate an even port for the client. If an even port cannot be 778 obtained, the server MUST reject the request with a 444 (Invalid 779 Port) response or redirect to an alternate server. If the client 780 requests odd port alignment, the server MUST attempt to allocate an 781 odd port for the client. If an odd port cannot be obtained, the 782 server MUST reject the request with a 444 (Invalid Port) response or 783 redirect to an alternate server. Finally, the "Even port with hold 784 of the next higher port" alignment is similar to requesting an even 785 port. It is a request for an even port, and MUST be rejected by the 786 server if an even port cannot be provided, or redirected to an 787 alternate server. However, it is also a hint from the client that 788 the client will request the next higher port with a separate Allocate 789 request. As such, it is a request for the server to allocate an even 790 port whose next higher port is also available, and furthermore, a 791 request for the server to not allocate that one higher port to any 792 other request except for one that asks for that port explicitly. The 793 server can honor this request for adjacency at its discretion. The 794 only constraint is that the allocated port number MUST be even. 796 Port alignment requests exist for compatibility with 797 implementations of RTP which predate [RFC3550]. These 798 implementations use the port numbering conventions in (now 799 obsolete) [RFC1889]. 801 5.2.1.5. Lifetime 803 The server checks for a LIFETIME attribute. If present, it indicates 804 the lifetime the client would like the server to assign to the 805 allocation. 807 If the LIFETIME attribute is malformed, or if the requested lifetime 808 value is less than 32 seconds, the server replies with an error 809 response with an error code of XXX Lifetime Malformed or Invalid. 811 5.2.1.6. Creating the Allocation 813 If any of the requested or desired constraints cannot be met, whether 814 it be bandwidth, transport protocol, IP address or port, the server 815 can redirect the client to a different server that may be able to 816 fulfill the request. This is accomplished using the 300 error 817 response and ALTERNATE-SERVER attribute. If the server does not 818 redirect and cannot service the request because the server has 819 reached capacity, it sends a 507 (Insufficient Capacity) response. 820 The server can also reject the request with a 486 (Allocation Quota 821 Reached) if the user or client is not authorized to request 822 additional allocations. 824 The server SHOULD only allocate ports from the range 49152 - 65535 825 (the Dynamic and/or Private Port range [Port-Numbers]), unless the 826 TURN server application knows, through some means not specified here, 827 that other applications running on the same host as the TURN server 828 application will not be impacted by allocating ports outside this 829 range. This condition can often be satisfied by running the TURN 830 server application on a dedicated machine and/or by arranging that 831 any other applications on the machine allocate ports before the TURN 832 server application starts. In any case, the TURN server SHOULD NOT 833 allocate ports in the range 0 - 1023 (the Well-Known Port range) to 834 discourage clients from using TURN to run standard services. 836 Once a port is allocated, the server associates the allocation with 837 the 5-tuple used to communicate between the client and the server. 838 For TCP, this amounts to associating the TCP connection from the TURN 839 client with the allocated transport address. 841 The new allocation MUST also be associated with the username, 842 password and realm used to authenticate the request. These 843 credentials are used in all subsequent requests to ensure that only 844 the same client can use or modify the allocation it was given. 846 In addition, the allocation created by the server is associated with 847 a set of permissions and a set of channel bindings. Each set is 848 initially empty. 850 If the LIFETIME attribute was present in the request, and the value 851 is larger than the maximum duration the server is willing to use for 852 the lifetime of the allocation, the server MAY lower it to that 853 maximum. However, the server MUST NOT increase the duration 854 requested in the LIFETIME attribute. If there was no LIFETIME 855 attribute, the server may choose a duration at its discretion. Ten 856 minutes is RECOMMENDED. In either case, the resulting duration is 857 added to the current time, and a timer, called the allocation 858 expiration timer, is set to expire at or after that time. Note that 859 the LIFETIME attribute in an Allocate request can be zero, though 860 this is effectively a no-op, since it will create and destroy the 861 allocation in one transaction. 863 5.2.1.7. Sending the Allocate Response 865 Once the port has been obtained and the allocation expiration timer 866 has been started, the server generates an Allocate Response using the 867 general procedures defined in [I-D.ietf-behave-rfc3489bis], including 868 the ones for long term authentication. The transport address 869 allocated to the client MUST be included in the RELAY-ADDRESS 870 attribute in the response. In addition, this response MUST contain 871 the XOR-MAPPED-ADDRESS attribute. This allows the client to 872 determine its reflexive transport address in addition to a relayed 873 transport address, from the same Allocate request. 875 The server MUST add a LIFETIME attribute to the Allocate Response. 876 This attribute contains the duration, in seconds, of the allocation 877 expiration timer associated with this allocation. 879 The server MUST add a BANDWIDTH attribute to the Allocate Response. 880 This MUST be equal to the attribute from the request, if one was 881 present. Otherwise, it indicates a per-allocation limit that the 882 server is placing on the bandwidth usage on each binding. Such 883 limits are needed to prevent against denial-of-service attacks (see 884 Section 12). 886 5.2.2. Refresh Requests 888 A Refresh request is processed using the general server and long term 889 authentication procedures in [I-D.ietf-behave-rfc3489bis]. It is 890 used to refresh and extend an allocation, or to cause an immediate 891 deallocation. It is processed as follows. 893 First, the request MUST be authenticated using the same shared secret 894 as the one associated with the allocation. If the request was 895 authenticated but not with such a matching credential, the server 896 MUST generate a Refresh Error Response with a 401 response. 898 If the Refresh request contains a BANDWIDTH attribute, the server 899 checks that it can relay the requested volume of traffic. 901 Finally, a Refresh Request will set a new allocation expiration timer 902 for the allocation, effectively canceling the previous allocation 903 expiration timer. As with an Allocate request, the server MAY 904 utilize a shorter allocation lifetime, but MUST NOT utilize a longer 905 lifetime. 907 A success Refresh response MUST contain a LIFETIME attribute. If its 908 associated Allocate request contained the BANDWIDTH attribute, or 909 this Refresh request contained a new BANDWIDTH attribute, the 910 response MUST also contain the BANDWIDTH attribute. 912 6. Send and Data Indications 914 TURN supports two ways to send and receive data from peers. This 915 section describes the use of Send and Data indications, while 916 Section 7 describes the use of the Channel Mechanism. 918 6.1. Forming and Sending an Indication 920 When the client has data to send to a peer, it uses a Send Indication 921 to pass the data to the server. When the server has data to send to 922 the client, it uses a Data Indication to pass the data to the client. 923 A client can also use a Send Indication without a DATA attribute to 924 install or refresh a permission for the specified IP address. Both 925 indications are formed following the general rules described in [ref 926 3489bis] with the extra considerations described below. 928 A Send Indication MUST contain a PEER-ADDRESS attribute and MAY 929 contain a DATA attribute, while a Data Indication MUST contain both 930 attributes. The PEER-ADDRESS attribute contains the transport 931 address of the peer to which the data is to be sent (in the case of a 932 Send Indication) or from which the data was received (in the case of 933 a Data Indication). This peer address is the transport address of 934 the peer as seen by the server, which may not be the same as the host 935 transport address of the peer. The DATA attribute contains the 936 actual application data. Note that the application data may need to 937 be padded to ensure the DATA attribute length is a multiple of 4. 939 No other attributes are included. For example, neither the 940 FINGERPRINT attribute nor any authentication attributes are included. 941 The latter holds even if the server is using the Long-Term Credential 942 Mechanism, since indications cannot be authenticated using this 943 mechanism. 945 Both the Send and Data indications MUST be sent using the 5-tuple of 946 the original allocation. Thus, in the case of the Send Indication, 947 the source transport address is the client's host transport address, 948 the destination transport address is the TURN server address, and the 949 transport protocol is the same as was used for the Allocate request. 950 For the Data Indication, the source and destination transport 951 addresses are the reverse. 953 6.2. Receiving an Indication 955 When a Send Indication is received at the server, or a Data 956 Indication is received at the client, the receiver first does the 957 basic indication processing described in [3489bis]. Once this is 958 done, it does the processing specific to the Send and Data methods 959 described below. 961 A Send Indication MUST contain a PEER-ADDRESS attribute and MAY 962 contain a DATA attribute, while a Data Indication MUST contain both 963 attributes. Any other attributes appearing in the message are 964 treated as unexpected. 966 TODO: Add check that Send or Data indication arrives with 967 appropriate 5-tuple. Since this check applies to all STUN 968 messages, not just Send and Data indications, perhaps this goes 969 under the general processing section. 971 6.3. Relaying 973 When the server receives a valid Send Indication contains a DATA 974 attribute, it forms a UDP datagram as follows: 976 o the source transport address is the relayed transport address of 977 the allocation, where the allocation is determined by the 5-tuple 978 on which the Send Indication arrived; 980 o the destination transport address is taken from the PEER-ADDRESS 981 attribute; 983 o the data following the UDP header is the contents of the value 984 field of the DATA attribute; 986 o the Length field in the UDP header is set to the Length field of 987 the DATA attribute; 989 o the Checksum field in the UDP header is computed as described in 990 [RFC 768]. 992 The resulting UDP datagram is then sent to the peer. 994 When the server receives a valid Send Indication (with or without a 995 DATA attribute), it also updates the permission associated with the 996 IP address contained in the PEER-ADDRESS attribute. For a certain 997 interval after the permission is updated, UDP datagrams received from 998 peers with source IP address equal to the IP address contained in the 999 PEER-ADDRESS attribute can be forwarded to the client. Note that 1000 only the IP addresses are considered and the port numbers are 1001 irrelevent. This permission is specific to the allocation and has no 1002 affect on any other allocation. The recommended length of time is 60 1003 seconds from when the Send Indication is received. 1005 When the server receives a UDP datagram with a destination transport 1006 address corresponding to an active (i.e., still alive) allocation, 1007 then it first checks to see if it is permitted to relay the datagram. 1008 If it is not permitted, the UDP datagram MUST be discarded. 1010 If relaying is permitted, the server forms and send a Data Indication 1011 as described in Section 6.1, using the data following the UDP header 1012 as the application data. 1014 7. Channel Mechanism 1016 As described in the overview, channel mechanism provides a way for a 1017 client and server to send application data using ChannelData 1018 messages, which have less overhead than Send and Data indications. 1020 Channel bindings are always initiated by the client. The client can 1021 bind a channel to a peer at any time during the lifetime of the 1022 allocation. The client may bind a channel to a peer before 1023 exchanging data with it, or after exchanging data with it (using Send 1024 and Data indications) for some time, or may choose never to bind a 1025 channel it. The client can also bind channels to some peers while 1026 not binding channels to other peers. 1028 Once a channel is bound to a peer, the channel binding cannot be 1029 changed. There is no way to unbind a channel or bind it to a 1030 different peer. 1032 Channel bindings are specific to an allocation, so that a binding in 1033 one allocation has no relationship to a binding in any other 1034 allocation. If an allocation expires, all its channel bindings 1035 expire with it. 1037 7.1. Forming and Sending a ChannelBind Request 1039 When a client wishes to bind a channel to a peer in an allocation, it 1040 forms a ChannelBind Request. The Request formed following the 1041 general rules described in [I-D.ietf-behave-rfc3489bis] with the 1042 extra considerations described below. 1044 A ChannelBind Request MUST contain both a CHANNEL-NUMBER attribute 1045 and a PEER-ADDRESS attribute. The CHANNEL-NUMBER attribute specifies 1046 the number of the channel that the client wishes to bind to the peer. 1047 The channel number MUST be in the range 0x4000 to 0xFFFE (inclusive) 1048 and the channel MUST NOT be already bound to a different peer. It is 1049 acceptable to rebind a channel to the peer it is already bound to. 1050 The PEER-ADDRESS attribute specifies the peer address to bind the 1051 channel to. 1053 Once formed, the ChannelBind Request is sent using the 5-tuple for 1054 the allocation. 1056 The client SHOULD be prepared to receive ChannelData messages on the 1057 channel as soon as it has sent the ChannelBind Request. Over UDP, it 1058 is possible for the client to receive these before it receives a 1059 ChannelBind Success Response. 1061 Over UDP, the client SHOULD NOT send ChannelData messages on the 1062 channel until it has received a ChannelBind Success Response for the 1063 binding attempt. Sending them before the success response is 1064 received risks having them dropped by the server if he ChannelBind 1065 Request was lost. 1067 7.2. Receiving a ChannelBind Request and Sending a Response 1069 When the server receives a ChannelBind Request, it first does the 1070 basic request processing described in [I-D.ietf-behave-rfc3489bis]. 1071 Once this is done, it does the processing specific to the ChannelBind 1072 method described below. 1074 The server checks that the ChannelBind Request contains both a 1075 CHANNEL-NUMBER attribute and a PEER-ADDRESS attribute. If the PEER- 1076 ADDRESS attribute is missing or malformed, then the server rejects 1077 the request with an Error Response containing the error code XXX 1078 "Peer address missing or invalid". If the CHANNEL-NUMBER attribute 1079 is missing or malformed, or the channel number is not in the range 1080 0x4000 to 0xFFFE (inclusive), or the channel is already bound to 1081 another peer (already bound to the same peer is OK) the server 1082 rejects the request with an Error Response containing the error code 1083 XXX "Channel number missing or invalid". Otherwise, if no errors are 1084 detected, the server replies with a ChannelBind Success Response. 1086 7.3. Receiving a ChannelBind Response 1088 When the client receives a ChannelBind response (either success or 1089 error), it processes it as specified in [3489bis]. Any additional 1090 processing is implementation specific. 1092 7.4. The ChannelData Message 1094 The ChannelData message is used to carry application data between the 1095 client and the server. It has the following format: 1097 0 1 2 3 1098 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 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Channel Number | Length | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | | 1103 / Application Data / 1104 / / 1105 | | 1106 | +-------------------------------+ 1107 | | 1108 +-------------------------------+ 1110 The Channel Number field specifies the number of the channel on which 1111 the data is traveling, and thus the address of the peer that is 1112 sending or is to receive the data. The channel number MUST be in the 1113 range 0x4000 - 0xFFFF, with channel number 0xFFFF being reserved for 1114 possible future extensions. 1116 Channel numbers 0x0000 - 0x3FFF cannot be used because bits 0 and 1 1117 are used to distinguish ChannelData messages from STUN-formatted 1118 messages (i.e., Allocate, Send, Data, ChannelBind, etc). STUN- 1119 formatted messages always have bits 0 and 1 as "00", while 1120 ChannelData messages use combinations "01", "10", and "11". 1122 The Length field specifies the length in bytes of the application 1123 data field (i.e., it does not include the size of the ChannelData 1124 header). Note that 0 is a valid length. 1126 The Application Data field carries the data the client is trying to 1127 send to the peer, or that the peer is sending to the client. 1129 7.5. Forming and Sending a ChannelData Message 1131 Once a client has bound a channel to a peer, then when the client has 1132 data to send to that peer it may use either a ChannelData message or 1133 a Send Indication; that is, the client is not obligated to use the 1134 channel when it exists and may freely intermix the two message types 1135 when sending data to the peer. The server, on the other hand, SHOULD 1136 use the ChannelData message if a channel has been bound to the peer. 1138 The fields of the ChannelData message are filled in as described in 1139 Section 7.4. 1141 Over stream transports, the ChannelData message MUST be padded to a 1142 multiple of four bytes in order to ensure the alignment of subsequent 1143 messages. The padding is not reflected in the length field of the 1144 ChannelData message, so the actual size of a ChannelData message 1145 (including padding) is (4 + Length) rounded up to the nearest 1146 multiple of 4. Over UDP, the padding is not required but MAY be 1147 included. 1149 The ChannelData message is then sent on the 5-tuple associated with 1150 the allocation. 1152 7.6. Receiving a ChannelData Message 1154 The receiver of the ChannelData message uses bits 0 and 1 to 1155 distinguish it from STUN-formatted messages, as described in 1156 Section 7.4. 1158 If the ChannelData message is received in a UDP datagram, and if the 1159 UDP datagram is too short to contain the claimed length of the 1160 ChannelData message (i.e., the UDP header length field value is less 1161 than the ChannelData header length field value + 4 + 8), then the 1162 message is silently discarded. 1164 If the ChannelData message is received over TCP or over TLS over TCP, 1165 then the actual length of the ChannelData message is as described in 1166 Section 7.5. 1168 If the ChannelData message is received on a channel which is not 1169 bound to any peer, then the message is silently discarded. 1171 7.7. Relaying 1173 When the server receives a valid ChannelData message, it forms a UDP 1174 datagram as follows: the source transport address is the relayed 1175 transport address of the allocation, where the allocation is 1176 determined by the 5-tuple on which the ChannelData message arrived; 1177 the destination transport address is the peer address to which the 1178 channel is bound; the data following the UDP header is the contents 1179 of the data field of the ChannelData message; the Length field in the 1180 UDP header is set to the Length field of the ChannelData message + 8; 1181 and the Checksum field in the UDP header is computed as described in 1183 [RFC 768]. The resulting UDP datagram is then sent to the peer. 1185 The server also updates the permission associated with the IP address 1186 part of the peer address to which the UDP datagram is sent. 1188 When the server receives a UDP datagram with a destination transport 1189 address corresponding to an active (i.e., still alive) allocation, 1190 then it first checks to see if it is permitted to relay the datagram. 1191 If the allocation contains an active permission for the source IP 1192 address (from the IP header) of the received UDP datagram, then the 1193 UDP datagram is permitted. Otherwise, the UDP datagram MUST be 1194 discarded. 1196 To relay the UDP datagram, the server forms and send a ChannelData 1197 message as described in Section 7.5 1199 8. New STUN Methods 1201 This section lists the codepoints for the new STUN methods defined in 1202 this specification. See elsewhere in this document for the semantics 1203 of these new methods. 1205 Request/Response Transactions 1206 0x003 : Allocate 1207 0x004 : Refresh 1209 Indications 1210 0x006 : Send 1211 0x007 : Data 1213 9. New STUN Attributes 1215 This STUN extension defines the following new attributes: 1217 0x000C: CHANNEL-NUMBER 1218 0x000D: LIFETIME 1219 0x0010: BANDWIDTH 1220 0x0012: PEER-ADDRESS 1221 0x0013: DATA 1222 0x0016: RELAY-ADDRESS 1223 0x0018: REQUESTED-PORT-PROPS 1224 0x0019: REQUESTED-TRANSPORT 1225 0x0022: REQUESTED-IP 1227 9.1. CHANNEL-NUMBER 1229 The CHANNEL-NUMBER attribute contains the number of the channel. It 1230 is a 16-bit unsigned integer, followed by a two-octet RFFU field 1231 which MUST be set to 0 on transmission and ignored on reception. 1233 0 1 2 3 1234 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 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Channel Number | RFFU | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 9.2. LIFETIME 1241 The lifetime attribute represents the duration for which the server 1242 will maintain an allocation in the absence of a refresh. It is a 32 1243 bit unsigned integral value representing the number of seconds 1244 remaining until expiration. 1246 9.3. BANDWIDTH 1248 The bandwidth attribute represents the peak bandwidth, measured in 1249 kilobits per second, that the client expects to use on the allocation 1250 in each direction. 1252 9.4. PEER-ADDRESS 1254 The PEER-ADDRESS specifies the address and port of the peer as seen 1255 from the TURN server. It is encoded in the same way as XOR-MAPPED- 1256 ADDRESS. 1258 9.5. DATA 1260 The DATA attribute is present in most Send Indications and Data 1261 Indications. It contains raw payload data that is to be sent (in the 1262 case of a Send Request) or was received (in the case of a Data 1263 Indication). 1265 9.6. RELAY-ADDRESS 1267 The RELAY-ADDRESS is present in Allocate responses. It specifies the 1268 address and port that the server allocated to the client. It is 1269 encoded in the same way as XOR-MAPPED-ADDRESS. 1271 9.7. REQUESTED-PORT-PROPS 1273 This attribute allows the client to request certain properties for 1274 the port that is allocated by the server. The attribute can be used 1275 with any transport protocol that has the notion of a 16 bit port 1276 space (including TCP and UDP). The attribute is 32 bits long. Its 1277 format is: 1279 0 1 2 3 1280 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 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Reserved = 0 | A | Specific Port Number | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 The two bits labeled A in the diagram above are for requested port 1286 alignment and have the following meaning: 1288 00 no specific port alignment 1289 01 odd port number 1290 10 even port number 1291 11 even port number; reserve next higher port 1293 If the value of the A field is 00 (no specific port alignment), then 1294 the Specific Port Number field can either be 0 or some non-zero port 1295 number. If the Specific Port Number field is 0, then the client is 1296 not putting any restrictions on the port number it would like 1297 allocated. If the Specific Port Number is some non-zero port number, 1298 then the client is requesting that the server allocate the specified 1299 port and the server MUST provide that port. 1301 If the value of the A field is 01 (odd port number), then the 1302 Specific Port Number field MUST be zero, and the client is requesting 1303 the server allocate an odd-numbered port. The server MUST provide an 1304 odd port number. 1306 If the value of the A field is 10 (even port number), then the 1307 Specific Port number field MUST be zero, and the client is requesting 1308 the server allocate an even-numbered port. The server MUST provide 1309 an even port number. 1311 If the value of the A field is 11 (even port number; reserve next 1312 higher port), then the Specific Port Number field MUST be zero, and 1313 the client is requesting the server allocate an even-numbered port. 1314 The server MUST return an even port number. In addition, the client 1315 is requesting the server reserve the next higher port (i.e., N+1 if 1316 the server allocates port N). The server SHOULD only allocate the 1317 N+1 port number if it is explicitly requested (with a subsequent 1318 request specifying that exact port number by the same TURN client, 1319 over a different alllocation). 1321 In all cases, if a port with the requested properties cannot be 1322 allocated, the server MUST respond with a error response with an 1323 error code of 444 (Invalid Port). 1325 9.8. REQUESTED-TRANSPORT 1327 This attribute is used by the client to request a specific transport 1328 protocol for the allocated transport address. It has the following 1329 format: 1330 0 1 2 3 1331 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 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Protocol | RFFU | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 The Protocol field specifies the desired protocol. The codepoints 1337 used in this field are taken from those allowed in the Protocol field 1338 in the IPv4 header and the NextHeader field in the IPv6 header 1339 [Protocol-Numbers]. This specification only allows the use of 1340 codepoint 17 (User Datagram Protocol). 1342 The RFFU field is set to zero on transmission and ignored on 1343 receiption. It is reserved for future uses. 1345 9.9. REQUESTED-IP 1347 The REQUESTED-IP attribute is used by the client to request that a 1348 specific IP address be allocated by the TURN server. This attribute 1349 is needed since it is anticipated that TURN servers will be multi- 1350 homed so as to be able to allocate more than 64k transport addresses. 1351 As a consequence, a client needing a second transport address on the 1352 same interface as a previous one can use this attribute to request a 1353 remote address from the same TURN server interface as the TURN 1354 client's previous remote address. 1356 The format of this attribute is identical to XOR-MAPPED-ADDRESS. 1357 However, the port component of the attribute MUST be ignored by the 1358 server. If a client wishes to request a specific IP address and 1359 port, it uses both the REQUESTED-IP and REQUESTED-PORT-PROPS 1360 attributes. 1362 10. New STUN Error Response Codes 1364 This document defines the following new error response codes: 1366 437 (Allocation Mismatch): A request was received by the server that 1367 requires an allocation to be in place, but there is none, or a 1368 request was received which requires no allocation, but there is 1369 one. 1371 442 (Unsupported Transport Protocol): The Allocate request asked for 1372 a transport protocol to be allocated that is not supported by the 1373 server. If the server is aware of another server that supports 1374 the requested protocol, it SHOULD include the other server's 1375 address in an ALTERNATE-SERVER attribute in the error response. 1377 443 (Invalid IP Address): The Allocate request asked for a transport 1378 address to be allocated from a specific IP address that is not 1379 valid on the server. 1381 444 (Invalid Port): The Allocate request asked for a port to be 1382 allocated that is not available on the server. 1384 486 (Allocation Quota Reached): The user or client is not authorized 1385 to request additional allocations. 1387 (tbd) (Channel Number Missing or Invalid): The request requires a 1388 channel number, but the CHANNEL-NUMBER attribute is missing, or 1389 the specified channel number is invalid in some way. 1391 (tbd) (Peer Address Missing or Invalid): The request requires a peer 1392 transport address, but the PEER-ADDRESS attribute is missing, or 1393 the specified peer transport address is invalid in some way. 1395 (tbd) (Lifetime Malformed or Invalid): The LIFETIME attribute is 1396 malformed or the specified lifetime is invalid in some way. 1398 507 (Insufficient Capacity): The server cannot allocate a new port 1399 for this client as it has exhausted its relay capacity. 1401 11. Client Discovery of TURN Servers 1403 The STUN extensions introduced by TURN differ from the binding 1404 requests defined in [I-D.ietf-behave-rfc3489bis] in that they are 1405 sent with additional framing and demand substantial resources from 1406 the TURN server. In addition, it seems likely that administrators 1407 might want to block connections from clients to the TURN server for 1408 relaying separately from connections for the purposes of binding 1409 discovery. As a consequence, TURN runs on a separate port from STUN. 1410 The client discovers the address and port of the TURN server using 1411 the same DNS procedures defined in [I-D.ietf-behave-rfc3489bis], but 1412 using an SRV service name of "turn" (or "turns" for TURN over TLS) 1413 instead of just "stun". 1415 For example, to find TURN servers in the example.com domain, the TURN 1416 client performs a lookup for '_turn._udp.example.com', 1417 '_turn._tcp.example.com', and '_turns._tcp.example.com' if the STUN 1418 client wants to communicate with the TURN server using UDP, TCP, or 1419 TLS over TCP, respectively. 1421 12. Security Considerations 1423 TURN servers allocate bandwidth and port resources to clients, in 1424 contrast to the Binding method defined in 1425 [I-D.ietf-behave-rfc3489bis]. Therefore, a TURN server requires 1426 authentication and authorization of STUN requests. This 1427 authentication is provided by mechanisms defined in the STUN 1428 specification itself, in particular digest authentication. 1430 Because TURN servers allocate resources, they can be susceptible to 1431 denial-of-service attacks. All Allocate transactions are 1432 authenticated, so that an unknown attacker cannot launch an attack. 1433 An authenticated attacker can generate multiple Allocate Requests, 1434 however. To prevent a single malicious user from allocating all of 1435 the resources on the server, it is RECOMMENDED that a server 1436 implement a modest per user limit on the amount of bandwidth that can 1437 be allocated. Such a mechanism does not prevent a large number of 1438 malicious users from each requesting a small number of allocations. 1439 Attacks such as these are possible using botnets, and are difficult 1440 to detect and prevent. Implementors of TURN should keep up with best 1441 practices around detection of anomalous botnet attacks. 1443 A client will use the transport address learned from the RELAY- 1444 ADDRESS attribute of the Allocate Response to tell other users how to 1445 reach them. Therefore, a client needs to be certain that this 1446 address is valid, and will actually route to them. Such validation 1447 occurs through the message integrity checks provided in the Allocate 1448 response. They can guarantee the authenticity and integrity of the 1449 allocated addresses. Note that TURN is not susceptible to the 1450 attacks described in Section 12.2.3, 12.2.4, 12.2.5 or 12.2.6 of 1451 [I-D.ietf-behave-rfc3489bis] [[TODO: Update section number references 1452 to 3489bis]]. These attacks are based on the fact that a STUN server 1453 mirrors the source IP address, which cannot be authenticated. STUN 1454 does not use the source address of the Allocate Request in providing 1455 the RELAY-ADDRESS, and therefore, those attacks do not apply. 1457 TURN cannot be used by clients for subverting firewall policies. 1458 TURN has fairly limited applicability, requiring a user to explicitly 1459 authorize permission to receive data from a peer, one IP address at a 1460 time. Thus, it does not provide a general technique for 1461 externalizing sockets. Rather, it has similar security properties to 1462 the placement of an address-restricted NAT in the network, allowing 1463 messaging in from a peer only if the internal client has sent a 1464 packet out towards the IP address of that peer. This limitation 1465 means that TURN cannot be used to run web servers, email servers, SIP 1466 servers, or other network servers that service a large number of 1467 clients. Rather, it facilitates rendezvous of NATted clients that 1468 use some other protocol, such as SIP, to communicate IP addresses and 1469 ports for communications. 1471 Confidentiality of the transport addresses learned through Allocate 1472 transactions does not appear to be that important. If required, it 1473 can be provided by running TURN over TLS. 1475 TURN does not and cannot guarantee that UDP data is delivered in 1476 sequence or to the correct address. As most TURN clients will only 1477 communicate with a single peer, the use of a single channel number 1478 will be very common. Consider an enterprise where Alice and Bob are 1479 involved in separate calls through the enterprise NAT to their 1480 corporate TURN server. If the corporate NAT reboots, it is possible 1481 that Bob will obtain the exact NAT binding originally used by Alice. 1482 If Alice and Bob were using identical channel numbers, Bob will 1483 receive unencapsulated data intended for Alice and will send data 1484 accidentally to Alice's peer. This is not a problem with TURN. This 1485 is precisely what would happen if there was no TURN server and Bob 1486 and Alice instead provided a (STUN) reflexive transport address to 1487 their peers. If detecting this misdelivery is a problem, the client 1488 and its peer need to use message integrity on their data. 1490 One TURN-specific DoS attack bears extra discussion. An attacker who 1491 can corrupt, drop, or cause the loss of a Send or Data indication 1492 sent over UDP, and then forge a Channel Confirmation indication for 1493 the corresponding channel number, can cause a TURN client (server) to 1494 start sending unencapsulated data that the server (client) will 1495 discard. Since indications are not integrity protected, this attack 1496 is not prevented by cryptographic means. However, any attacker who 1497 can generate this level of network disruption could simply prevent a 1498 large fraction of the data from arriving at its destination, and 1499 therefore protecting against this attack does not seem important. 1500 The ChannelConfirmation forging attack is not possible when the 1501 client to server communication is over TCP or TLS over TCP. 1503 Relay servers are useful even for users not behind a NAT. They can 1504 provide a way for truly anonymous communications. A user can cause a 1505 call to have its media routed through a TURN server, so that the 1506 user's IP addresses are never revealed. 1508 Any relay addresses learned through an Allocate request will not 1509 operate properly with IPSec Authentication Header (AH) [RFC4302] in 1510 transport or tunnel mode. However, tunnel-mode IPSec ESP [RFC4303] 1511 should still operate. 1513 13. IANA Considerations 1515 Since TURN is an extension to STUN [I-D.ietf-behave-rfc3489bis], the 1516 methods, attributes and error codes defined in this specification are 1517 new method, attributes, and error codes for STUN. This section 1518 directs IANA to add these new protocol elements to the IANA registry 1519 of STUN protocol elements. 1521 The codepoints for the new STUN methods defined in this specification 1522 are listed in Section 8. 1524 The codepoints for the new STUN attributes defined in this 1525 specification are listed in Section 9. 1527 The codepoints for the new STUN error codes defined in this 1528 specification are listed in Section 10. 1530 Extensions to TURN can be made through IETF consensus. 1532 14. IAB Considerations 1534 The IAB has studied the problem of "Unilateral Self Address Fixing", 1535 which is the general process by which a client attempts to determine 1536 its address in another realm on the other side of a NAT through a 1537 collaborative protocol reflection mechanism [RFC3424]. The TURN 1538 extension is an example of a protocol that performs this type of 1539 function. The IAB has mandated that any protocols developed for this 1540 purpose document a specific set of considerations. 1542 TURN is an extension of the STUN protocol. As such, the specific 1543 usages of STUN that use the TURN extensions need to specifically 1544 address these considerations. Currently the only STUN usage that 1545 uses TURN is ICE [I-D.ietf-mmusic-ice]. 1547 15. Example 1549 TBD 1551 16. Changes from Previous Versions 1553 Note to RFC Editor: Please remove this section prior to publication 1554 of this document as an RFC. 1556 This section lists the changes between the various versions of this 1557 specification. 1559 16.1. Changes from -05 to -06 1561 o Changed the mechanism for allocating channels to the one proposed 1562 by Eric Rescorla at the Dec 2007 IETF meeting. 1564 o Removed the framing mechanism (which was used to frame all 1565 messages) and replaced it with the ChannelData message. As part 1566 of this change, noted that the demux of ChannelData messages from 1567 TURN messages can be done using the first two bits of the message. 1569 o Rewrote the sections on transmitted and receiving data as a result 1570 of the above to changes, splitting it into a section on Send and 1571 Data Indications and a separate section on channels. 1573 o Clarified the handling of Allocate Request messages. In 1574 particular, subsequent Allocate Request messages over UDP with the 1575 same transaction id are not an error but a retransmission. 1577 o Restricted the range of ports available for allocation to the 1578 Dynamic and/or Private Port range, and noted when ports outside 1579 this range can be used. 1581 o Changed the format of the REQUESTED-TRANSPORT attribute. The 1582 previous version used 00 for UDP and 01 for TCP; the new version 1583 uses protocol numbers from the IANA protocol number registry. The 1584 format of the attribute also changed. 1586 o Made a large number of changes to the non-normative portion of the 1587 document to reflect technical changes and improve the 1588 presentation. 1590 o Added the Issues section. 1592 16.2. Changes from -04 to -05 1594 o Removed the ability to allocate addresses for TCP relaying. This 1595 is now covered in a separate document. However, communication 1596 between the client and the server can still run over TCP or TLS/ 1597 TCP. This resulted in the removal of the Connect method and the 1598 TIMER-VAL and CONNECT-STAT attributes. 1600 o Added the concept of channels. All communication between the 1601 client and the server flows on a channel. Channels are numbered 1602 0..65535. Channel 0 is used for TURN messages, while the 1603 remaining channels are used for sending unencapsulated data to/ 1604 from a remote peer. This concept adds a new Channel Confirmation 1605 method and a new CHANNEL-NUMBER attribute. The new attribute is 1606 also used in the Send and Data methods. 1608 o The framing mechanism formally used just for stream-oriented 1609 transports is now also used for UDP, and the former Type and 1610 Reserved fields in the header have been replaced by a Channel 1611 Number field. The length field is zero when running over UDP. 1613 o TURN now runs on its own port, rather than using the STUN port. 1614 The use of channels requires this. 1616 o Removed the SetActiveDestination concept. This has been replaced 1617 by the concept of channels. 1619 o Changed the allocation refresh mechanism. The new mechanism uses 1620 a new Refresh method, rather than repeating the Allocation 1621 transaction. 1623 o Changed the syntax of SRV requests for secure transport. The new 1624 syntax is "_turns._tcp" rather than the old "_turn._tls". This 1625 change mirrors the corresponding change in STUN SRV syntax. 1627 o Renamed the old REMOTE-ADDRESS attribute to PEER-ADDRESS, and 1628 changed it to use the XOR-MAPPED-ADDRESS format. 1630 o Changed the RELAY-ADDRESS attribute to use the XOR-MAPPED-ADDRESS 1631 format (instead of the MAPPED-ADDRESS format)). 1633 o Renamed the 437 error code from "No Binding" to "Allocation 1634 Mismatch". 1636 o Added a discussion of what happens if a client's public binding on 1637 its outermost NAT changes. 1639 o The document now consistently uses the term "peer" as the name of 1640 a remote endpoint with which the client wishes to communicate. 1642 o Rewrote much of the document to describe the new concepts. At the 1643 same time, tried to make the presentation clearer and less 1644 repetitive. 1646 17. Issues 1648 NOTE to RFC Editor: Please remove this section prior to publication 1649 of this document as an RFC. 1651 This section lists the open and now closed issues in this document. 1652 The descriptions here are brief, and the reader should consult the 1653 corresponding thread on the mailing list for a more in-depth 1654 description of the issue and the resolutions being considered. 1656 17.1. Open Issues 1658 1. Bandwidth: What should we do with the BANDWIDTH attribute, which 1659 is currently ill-specified? Should we remove it? Or should we 1660 try to come up with a good specification, perhaps using ideas 1661 from RSVP? 1663 2. Permission Policy: What should the permission policy be? 1664 Address-restricted, as is currently specified in the document? 1665 Or address-and-port-restricted, as many firewalls implement 1666 today? Or should we leave this open to the implementor, under 1667 the assumption that the IT administrator will only allow clients 1668 to contact those servers that implement whatever permission 1669 policy the IT administrator can accept? 1671 3. Port Adjacency: The spec currently allows a client to request 1672 that the server allocate a port and also reserve the next higher 1673 port number for a possible future allocation (on a different 1674 5-tuple). However, the exact behavior of the server in this 1675 case is ill-specified. For example, must the next-higher-port 1676 be available for the allocation of the lower port number to 1677 succeed? How long is the next-higher-port reserved? 30 seconds? 1678 For the lifetime of the lower-numbered-port's allocation? Or 1679 should we just ditch this feature, since it is difficult to 1680 implement, it is at odds with port randomization, and paired 1681 port numbers applications don't work well with NATs anyway? 1683 4. Demuxing ChannelData messages: How does a client or server demux 1684 STUN-formatted messages from ChannelData messages? Does it use 1685 the first two bits (as currently specified) or just one bit? 1686 And how many channels do we need anyway? Some people are 1687 questioning the need for any more than 200 channels. If we 1688 don't need many channels, then the demux algorithm might become 1689 simpler. 1691 5. Deallocating Channels: Do we need a mechanism for deallocating 1692 channels? Some have argued for this feature, because a TURN 1693 server administrator will want a way to recover resources for 1694 channels no longer in active use. If yes, then what is the 1695 mechanism? For example, should a channel binding expire when 1696 the corresponding permission expires? 1698 6. Permissions and Channel Allocations: Should allocating a channel 1699 for a peer automatically install a permission for that peer's IP 1700 address? 1702 7. Permission and Allocation Lifetimes: What should the default 1703 permission lifetime be? Should there be a minumum value? 1704 Should there be a way for the client to modify the permission 1705 lifetime? Should there be a way for the client to learn the 1706 current permission lifetime? And what is the relationship of 1707 the permission lifetime to the allocation lifetime? Does it 1708 make sense for the allocation lifetime to be less than the 1709 permission lifetime? 1711 8. Preserving bits in the IP header: What bits (if any) should be 1712 preserved in the IP header when a packet is relayed by the 1713 server? The bits under consideration are currently the Don't 1714 Fragment (DF) bit, the Explicit Congestion Notification (ECN) 1715 bits, and the DiffServ (DS) bits. 1717 9. Exceeding the Path MTU Size: TURN adds an overhead of 4 bytes 1718 (ChannelData msg) or 36 bytes (Send or Data Indication), thus 1719 potentially exceeding the path MTU between the client and 1720 server. This could either cause IP fragmentation, or cause the 1721 packet to be dropped if the DF bit is set. Who handles this 1722 problem? Does TURN need to handle this, or is this left up to 1723 the application to handle? 1725 10. Allowed PEER-ADDRESS values: Should there be any restrictions on 1726 the IP address the client can specify in the PEER-ADDRESS 1727 attribute? Are multicast addresses allowed? What about 1728 0.0.0.0? Any other restrictions? 1730 11. Discarding UDP datagrams: If the server discards a received UDP 1731 datagram on the relayed transport address (because there is no 1732 corresponding permission), then does the server send an ICMP 1733 response? If so, what error code does it use? (What does RFC 1734 4787 say about the corresponding situation in NATs? I believe 1735 many NATs silently discard these packets by default, or have a 1736 "stealth mode" that enables this behavior.) 1738 12. Authentication: Is the use of STUN's Long-Term Authentication 1739 Mechanism by a TURN server mandatory? The document currently 1740 implicitly assumes "yes", but what about someone who wants to 1741 operate a public TURN server? 1743 13. Re-using the 5-tuple: If an allocation expires, is there any 1744 reason a client should not be able to immediately create a new 1745 allocation using the same 5-tuple? 1747 14. Password change: Is it possible to change the password for the 1748 Long-Term Authentication mechanism during the lifetime of an 1749 allocation? If so, how is it done? 1751 15. IPv6: TURN probably works fine in an all IPv6 environment, but 1752 there are a number of mixed IPv4/IPv6 cases that are ill- 1753 specified. As an example, the server needs to check that the 1754 PEER-ADDRESS in a Send Indication is of the same address family 1755 as the relayed transport address. Should we carefully work 1756 through all these cases and make sure we have caught them all, 1757 or should we just state that this document covers the IPv4 case 1758 only, and punt the specification of IPv6 and mixed IPv4/IPv6 1759 operation to draft-ietf-behave-turn-ipv6? Does the current 1760 interest in resurecting IPv4-to-IPv6 NATs have any impact on 1761 TURN? 1763 17.2. Closed Issues 1765 1. Channel Allocation: Should TURN use the mechanism proposed by EKR 1766 to allocate channels? RESOLUTION: Yes. Document now reflects 1767 this. 1769 2. Stateful Allocations: Does a TURN server need to distinguish 1770 between the case where the client retransmits the initial 1771 Allocate Request because the Allocate Response was lost and the 1772 case where the client sends an Allocate Request because it thinks 1773 the allocation does not exist? RESOLUTION: Yes. Document now 1774 reflects this. 1776 3. Port Range: From what range of port numbers should a TURN server 1777 allocate ports? RESOLUTION: The server SHOULD allocate from the 1778 Dynamic and/or Private Port range unless it is sure it will not 1779 interfere with other apps on the same machine. Document now 1780 reflects this. 1782 4. Framing Header for STUN-formatted messages: Should TURN use the 1783 framing mechanism for STUN-formatted messages? RESOLUTION: NO. 1784 Document now reflects this. However, see related issues. 1786 5. Length field in ChannelData header: Over UDP, the length of the 1787 application data field in the ChannelData message can be 1788 determined from the length field in the UDP header. So should 1789 the length field in the ChannelData header be set to zero in this 1790 case? RESOLUTION: No, the ChannelData length field should have 1791 the same semantics over both TCP and UDP. Document now reflects 1792 this. 1794 18. Acknowledgements 1796 The authors would like to thank the various participants in the 1797 BEHAVE working group for their many comments on this draft. Marc 1798 Petit-Huguenin, Remi Denis-Courmont, Cullen Jennings, Lars Eggert, 1799 Magnus Westerlund, and Eric Rescorla have been particularly helpful, 1800 with Eric also suggesting the channel allocation mechanism. 1801 Christian Huitema was an early contributor to this document and was a 1802 co-author on the first few drafts. Finally, the authors would like 1803 to thank Dan Wing for his huge help in restarting progress on this 1804 draft after work had stalled. 1806 19. References 1808 19.1. Normative References 1810 [I-D.ietf-behave-rfc3489bis] 1811 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1812 "Session Traversal Utilities for (NAT) (STUN)", 1813 draft-ietf-behave-rfc3489bis-13 (work in progress), 1814 November 2007. 1816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1817 Requirement Levels", BCP 14, RFC 2119, March 1997. 1819 19.2. Informative References 1821 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1822 Jacobson, "RTP: A Transport Protocol for Real-Time 1823 Applications", STD 64, RFC 3550, July 2003. 1825 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 1826 Jacobson, "RTP: A Transport Protocol for Real-Time 1827 Applications", RFC 1889, January 1996. 1829 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1830 E. Lear, "Address Allocation for Private Internets", 1831 BCP 5, RFC 1918, February 1996. 1833 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1834 with Session Description Protocol (SDP)", RFC 3264, 1835 June 2002. 1837 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1838 December 2005. 1840 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1841 RFC 4303, December 2005. 1843 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1844 Self-Address Fixing (UNSAF) Across Network Address 1845 Translation", RFC 3424, November 2002. 1847 [I-D.ietf-mmusic-ice] 1848 Rosenberg, J., "Interactive Connectivity Establishment 1849 (ICE): A Protocol for Network Address Translator (NAT) 1850 Traversal for Offer/Answer Protocols", 1851 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1853 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1854 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1855 RFC 4787, January 2007. 1857 [I-D.ietf-behave-turn-tcp] 1858 Rosenberg, J. and R. Mahy, "Traversal Using Relays around 1859 NAT (TURN) Extensions for TCP Allocations", 1860 draft-ietf-behave-turn-tcp-00 (work in progress), 1861 November 2007. 1863 [Port-Numbers] 1864 "IANA Port Numbers Registry", 1865 . 1867 [Protocol-Numbers] 1868 "IANA Protocol Numbers Registry", 2005, 1869 . 1871 Authors' Addresses 1873 Jonathan Rosenberg 1874 Cisco Systems, Inc. 1875 Edison, NJ 1876 USA 1878 Email: jdrosen@cisco.com 1879 URI: http://www.jdrosen.net 1880 Rohan Mahy 1881 Plantronics, Inc. 1883 Email: rohan@ekabal.com 1885 Philip Matthews 1886 Avaya, Inc. 1887 1135 Innovation Drive 1888 Ottawa, Ontario K2K 3G7 1889 Canada 1891 Phone: +1 613 592-4343 x223 1892 Fax: 1893 Email: philip_matthews@magma.ca 1894 URI: 1896 Full Copyright Statement 1898 Copyright (C) The IETF Trust (2008). 1900 This document is subject to the rights, licenses and restrictions 1901 contained in BCP 78, and except as set forth therein, the authors 1902 retain all their rights. 1904 This document and the information contained herein are provided on an 1905 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1906 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1907 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1908 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1909 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1910 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1912 Intellectual Property 1914 The IETF takes no position regarding the validity or scope of any 1915 Intellectual Property Rights or other rights that might be claimed to 1916 pertain to the implementation or use of the technology described in 1917 this document or the extent to which any license under such rights 1918 might or might not be available; nor does it represent that it has 1919 made any independent effort to identify any such rights. Information 1920 on the procedures with respect to rights in RFC documents can be 1921 found in BCP 78 and BCP 79. 1923 Copies of IPR disclosures made to the IETF Secretariat and any 1924 assurances of licenses to be made available, or the result of an 1925 attempt made to obtain a general license or permission for the use of 1926 such proprietary rights by implementers or users of this 1927 specification can be obtained from the IETF on-line IPR repository at 1928 http://www.ietf.org/ipr. 1930 The IETF invites any interested party to bring to its attention any 1931 copyrights, patents or patent applications, or other proprietary 1932 rights that may cover technology that may be required to implement 1933 this standard. Please address the information to the IETF at 1934 ietf-ipr@ietf.org. 1936 Acknowledgment 1938 Funding for the RFC Editor function is provided by the IETF 1939 Administrative Support Activity (IASA).