idnits 2.17.1 draft-ietf-behave-turn-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 12, 2009) is 5465 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 664, but not defined ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-07) exists of draft-ietf-behave-turn-tcp-02 == Outdated reference: A later version (-11) exists of draft-ietf-behave-turn-ipv6-06 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-03 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE WG J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track R. Mahy 5 Expires: October 14, 2009 (Unaffiliated) 6 P. Matthews 7 Alcatel-Lucent 8 April 12, 2009 10 Traversal Using Relays around NAT (TURN): Relay Extensions to Session 11 Traversal Utilities for NAT (STUN) 12 draft-ietf-behave-turn-14 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on October 14, 2009. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 If a host is located behind a NAT, then in certain situations it can 60 be impossible for that host to communicate directly with other hosts 61 (peers). In these situations, it is necessary for the host to use 62 the services of an intermediate node that acts as a communication 63 relay. This specification defines a protocol, called TURN (Traversal 64 Using Relays around NAT), that allows the host to control the 65 operation of the relay and to exchange packets with its peers using 66 the relay. TURN differs from some other relay control protocols in 67 that it allows a client to communicate with multiple peers using a 68 single relay address. 70 The TURN protocol was designed to be used as part of the ICE 71 (Interactive Connectivity Establishment) approach to NAT traversal, 72 though it can be also used without ICE. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 78 2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8 79 2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 10 80 2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 12 81 2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12 82 2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14 83 2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16 84 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 17 85 2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18 86 2.9. Anycast Discovery of Servers . . . . . . . . . . . . . . 18 87 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 4. General Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 89 5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 6. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 23 91 6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 24 92 6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 25 93 6.3. Receiving an Allocate Success Response . . . . . . . . . 29 94 6.4. Receiving an Allocate Error Response . . . . . . . . . . 30 95 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 32 96 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 32 97 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 32 98 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 33 99 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 33 100 9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 34 101 9.1. Forming a CreatePermission request . . . . . . . . . . . 35 102 9.2. Receiving a CreatePermission request . . . . . . . . . . 35 103 9.3. Receiving a CreatePermission response . . . . . . . . . . 36 104 10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 36 105 10.1. Forming a Send Indication . . . . . . . . . . . . . . . . 36 106 10.2. Receiving a Send Indication . . . . . . . . . . . . . . . 36 107 10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 37 108 10.4. Receiving a Data Indication . . . . . . . . . . . . . . . 38 109 11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 110 11.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 40 111 11.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 40 112 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 41 113 11.4. The ChannelData Message . . . . . . . . . . . . . . . . . 42 114 11.5. Sending a ChannelData Message . . . . . . . . . . . . . . 42 115 11.6. Receiving a ChannelData Message . . . . . . . . . . . . . 43 116 11.7. Relaying Data from the Peer . . . . . . . . . . . . . . . 44 117 12. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . . 44 118 13. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . . 45 119 14. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 46 120 14.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 46 121 14.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 46 122 14.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 47 123 14.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 47 124 14.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . . 47 125 14.6. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . . 47 126 14.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 47 127 14.8. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . . 48 128 14.9. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . . 48 129 15. New STUN Error Response Codes . . . . . . . . . . . . . . . . 48 130 16. Detailed Example . . . . . . . . . . . . . . . . . . . . . . . 49 131 17. Security Considerations . . . . . . . . . . . . . . . . . . . 56 132 17.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 56 133 17.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 56 134 17.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 56 135 17.1.3. Faked Refreshes and Permissions . . . . . . . . . . . 57 136 17.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . . 57 137 17.1.5. Impersonating a Server . . . . . . . . . . . . . . . 58 138 17.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . . 58 139 17.1.7. TURN loop attack . . . . . . . . . . . . . . . . . . 59 140 17.2. Firewall Considerations . . . . . . . . . . . . . . . . . 59 141 17.2.1. Faked Permissions . . . . . . . . . . . . . . . . . . 60 142 17.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 60 143 17.2.3. Running Servers on Well-Known Ports . . . . . . . . . 61 144 17.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 61 145 17.3.1. DoS Against TURN Server . . . . . . . . . . . . . . . 61 146 17.3.2. Anonymous Relaying of Malicious Traffic . . . . . . . 61 147 17.3.3. Manipulating other Allocations . . . . . . . . . . . 62 148 17.4. Other Considerations . . . . . . . . . . . . . . . . . . 62 149 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 150 19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 63 151 20. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 64 152 21. Changes from Previous Versions . . . . . . . . . . . . . . . . 65 153 21.1. Changed from -13 to -14 . . . . . . . . . . . . . . . . . 65 154 21.2. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 65 155 21.3. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 66 156 21.4. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 67 157 21.5. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 68 158 21.6. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 70 159 21.7. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 72 160 21.8. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 72 161 21.9. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 74 162 21.10. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 75 163 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 164 23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 165 23.1. Normative References . . . . . . . . . . . . . . . . . . 76 166 23.2. Informative References . . . . . . . . . . . . . . . . . 77 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79 169 1. Introduction 171 A host behind a NAT may wish to exchange packets with other hosts, 172 some of which may also be behind NATs. To do this, the hosts 173 involved can use 'Hole Punching' techniques (see [RFC5128]) in an 174 attempt discover a direct communication path; that is, a 175 communication path that goes from host to another through intervening 176 NATs and routers, but does not traverse any relays. 178 As described in [RFC5128] and [RFC4787], hole punching techniques 179 will fail if both hosts are behind NATs that are not well-behaved. 180 For example, if both hosts are behind NATs that have a mapping 181 behavior of "address dependent mapping" or "address and port 182 dependent mapping", then hole punching techniques generally fail. 184 When a direct communication path cannot be found, it is necessary to 185 use the services of an intermediate host that acts as a relay for the 186 packets. This relay typically sits in the public Internet and relays 187 packets between two hosts that both sit behind NATs. 189 This specification defines a protocol, called TURN, that allows a 190 host behind a NAT (called the TURN client) to request that another 191 host (called the TURN server) act as a relay. The client can arrange 192 for the server to relay packets to and from certain other hosts 193 (called peers) and can control aspects of how the relaying is done. 194 The client does this by obtaining an IP address and port on the 195 server, called the relayed-transport-address. When a peer sends a 196 packet to the relayed-transport-address, the server relays the packet 197 to the client. When the client sends a data packet to the server, 198 the server relays it to the appropriate peer using the relayed- 199 transport-address as the source. 201 A client using TURN must have some way to communicate the relayed- 202 transport-address to its peers, and to learn each peer's IP address 203 and port (more precisely, each peer's server-reflexive transport 204 address, see Section 2). How this is done is out of the scope of the 205 TURN protocol. One way this might be done is for the client and 206 peers to exchange e-mail messages. Another way is for the client and 207 its peers to use a special-purpose 'introduction' or 'rendezvous' 208 protocol (see [RFC5128] for more details). 210 If TURN is used with ICE [I-D.ietf-mmusic-ice], then the relayed- 211 transport-address and the IP addresses and ports of the peers are 212 included in the ICE candidate information which the rendezvous 213 protocol must carry. For example, if TURN and ICE are used as part 214 of a multimedia solution using SIP [RFC3261], then SIP serves the 215 role of the rendezvous protocol, carrying the ICE candidate 216 information inside the body of SIP messages. If TURN and ICE are 217 used with some other rendezvous protocol, then 218 [I-D.rosenberg-mmusic-ice-nonsip] provides guidance on the services 219 the rendezvous protocol must perform. 221 Though the use of a TURN server to enable communication between two 222 hosts behind NATs is very likely to work, it comes at a high cost to 223 the provider of the TURN server, since the server typically needs a 224 high bandwidth connection to the Internet . As a consequence, it is 225 best to use a TURN server only when a direct communication path 226 cannot be found. When the client and a peer use ICE to determine the 227 communication path, ICE will use hole punching techniques to search 228 for a direct path first and only use a TURN server when a direct path 229 cannot be found. 231 TURN was originally invented to support multimedia sessions signaled 232 using SIP. Since SIP supports forking, TURN supports multiple peers 233 per relayed-transport-address; a feature not supported by other 234 approaches (e.g., SOCKS [RFC1928]). However, care has been taken to 235 make sure that TURN is suitable for other types of applications. 237 TURN was designed as one piece in the larger ICE approach to NAT 238 traversal. Implementors of TURN are urged to investigate ICE and 239 seriously consider using it for their application. However, it is 240 possible to use TURN without ICE. 242 TURN is an extension to the STUN (Session Traversal Utilities for NAT 243 [RFC5389]) protocol. Most, though not all, TURN messages are STUN- 244 formatted messages. A reader of this document should be familiar 245 with STUN. 247 2. Overview of Operation 249 This section gives an overview of the operation of TURN. It is non- 250 normative. 252 In a typical configuration, a TURN client is connected to a private 253 network [RFC1918] and through one or more NATs to the public 254 Internet. On the public Internet is a TURN server. Elsewhere in the 255 Internet are one or more peers that the TURN client wishes to 256 communicate with. These peers may or may not be behind one or more 257 NATs. The client uses the server as a relay to send packets to these 258 peers and to receive packets from these peers. 260 Peer A 261 Server-Reflexive +---------+ 262 Transport Address | | 263 192.0.2.150:32102 | | 264 | /| | 265 TURN | / ^| Peer A | 266 Client's Server | / || | 267 Host Transport Transport | // || | 268 Address Address | // |+---------+ 269 10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A 270 | | ||N| / Host Transport 271 | +-+ | ||A|/ Address 272 | | | | v|T| 192.168.100.2:49582 273 | | | | /+-+ 274 +---------+| | | |+---------+ / +---------+ 275 | || |N| || | // | | 276 | TURN |v | | v| TURN |/ | | 277 | Client |----|A|----------| Server |------------------| Peer B | 278 | | | |^ | |^ ^| | 279 | | |T|| | || || | 280 +---------+ | || +---------+| |+---------+ 281 | || | | 282 | || | | 283 +-+| | | 284 | | | 285 | | | 286 Client's | Peer B 287 Server-Reflexive Relayed Transport 288 Transport Address Transport Address Address 289 192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191 291 Figure 1 293 Figure 1 shows a typical deployment. In this figure, the TURN client 294 and the TURN server are separated by a NAT, with the client on the 295 private side and the server on the public side of the NAT. This NAT 296 is assumed to be a "bad" NAT; for example, it might have a mapping 297 property of address-and-port-dependent mapping (see [RFC4787] for a 298 description of what this means). 300 The client talks to the server from a (IP address, port) combination 301 called the client's HOST TRANSPORT ADDRESS. (The combination of an 302 IP address and port is called a TRANSPORT ADDRESS). 304 The client sends TURN messages from its host transport address to a 305 transport address on the TURN server which is known as the TURN 306 SERVER TRANSPORT ADDRESS. The client learns the server's transport 307 address through some unspecified means (e.g., configuration), and 308 this address is typically used by many clients simultaneously. 310 Since the client is behind a NAT, the server sees packets from the 311 client as coming from a transport address on the NAT itself. This 312 address is known as the client's SERVER-REFLEXIVE transport address; 313 packets sent by the server to the client's server-reflexive transport 314 address will be forwarded by the NAT to the client's host transport 315 address. 317 The client uses TURN commands to create and manipulate an ALLOCATION 318 on the server. An allocation is a data structure on the server, an 319 important component of which is a RELAYED TRANSPORT ADDRESS. The 320 relayed transport address for the allocation is a transport address 321 on the server which is used to send and receive packets to the peers. 323 Once an allocation is created, the client can send application data 324 to the server along with an indication of which peer the data is to 325 be sent to, and the server will relay this data to the appropriate 326 peer. The client sends the application data to the server inside a 327 TURN message; at the server, the data is extracted from the TURN 328 message and sent to the peer in a UDP datagram. In the reverse 329 direction, a peer can send application data in a UDP datagram to the 330 relayed transport address for the allocation; the server will then 331 encapsulate this data inside a TURN message and send it to the client 332 along with an indication of which peer sent the data. Since the TURN 333 message always contains an indication of which peer the client is 334 communicating with, the client can use a single allocation to 335 communicate with multiple peers. 337 When the peer is behind a NAT, then the client must identify the peer 338 using its server-reflexive transport address rather than its host 339 transport address. For example, to send application data to peer A 340 in the example above, the client must specify 192.0.2.150:32102 (peer 341 A's server-reflexive transport address) rather than 192.168.100.2: 342 49582 (peer A's host transport address). 344 Each allocation on the server belongs to a single client and has 345 exactly one relayed transport address which is used only by that 346 allocation. Thus when a packet arrives at a relayed transport 347 address on the server, the server knows which client the data is 348 intended for. However, the client may have multiple allocations on a 349 server at the same time. 351 2.1. Transports 353 TURN as defined in this specification always uses UDP between the 354 server and the peer. However, this specification allows the use of 355 any one of UDP, TCP, or TLS over TCP to carry the TURN messages 356 between the client and the server. 358 +----------------------------+---------------------+ 359 | TURN client to TURN server | TURN server to peer | 360 +----------------------------+---------------------+ 361 | UDP | UDP | 362 | TCP | UDP | 363 | TLS over TCP | UDP | 364 +----------------------------+---------------------+ 366 If TCP or TLS over TCP is used between the client and the server, 367 then the server will convert between these transports and UDP 368 transport when relaying data to/from the peer. 370 Since this version of TURN only supports UDP between the server and 371 the peer, it is expected that most clients will prefer to also use 372 UDP between the client and the server. That being the case, some 373 readers may wonder: Why also support TCP and TLS over TCP? 375 TURN supports TCP transport between the client and the server because 376 some firewalls are configured to block UDP entirely. These firewalls 377 block UDP but not TCP in part because TCP has properties that make 378 the intention of the nodes being protected by the firewall more 379 obvious to the firewall. For example, TCP has a three-way handshake 380 that makes in clearer that the protected node really wishes to have 381 that particular connection established, while for UDP the best the 382 firewall can do is guess which flows are desired by using filtering 383 rules. Also, TCP has explicit connection teardown, while for UDP the 384 firewall has to use timers to guess when the flow is finished. 386 TURN supports TLS over TCP transport between the client and the 387 server because TLS provides additional security properties not 388 provided by TURN's default digest authentication; properties which 389 some clients may wish to take advantage of. In particular, TLS 390 provides a way for the client to ascertain that it is talking to the 391 server that it intended to, and also provides for confidentiality of 392 TURN control messages. TURN does not require TLS because the 393 overhead of using TLS is higher than that of digest authentication; 394 for example, using TLS likely means that most application data will 395 be doubly encrypted (once by TLS and once to ensure it is still 396 encrypted in the UDP datagram). 398 There is a planned extension to TURN to add support for TCP between 399 the server and the peers [I-D.ietf-behave-turn-tcp]. For this 400 reason, allocations that use UDP between the server and the peers are 401 known as UDP allocations, while allocations that use TCP between the 402 server and the peers are known as TCP allocations. This 403 specification describes only UDP allocations. 405 TURN as defined in this specification only supports IPv4. All IP 406 addresses in this specification must be IPv4 addresses. However, 407 there is a planned extension to TURN to add support for IPv6 and for 408 relaying between IPv4 and IPv6 [I-D.ietf-behave-turn-ipv6]. 410 In some applications for TURN, the client may send and receive 411 packets other than TURN packets on the host transport address it uses 412 to communicate with the server. This can happen, for example, when 413 using TURN with ICE. In these cases, the client can distinguish TURN 414 packets from other packets by examining the source address of the 415 arriving packet: those arriving from the TURN server will be TURN 416 packets. 418 2.2. Allocations 420 To create an allocation on the server, the client uses an Allocate 421 transaction. The client sends a Allocate request to the server, and 422 the server replies with an Allocate success response containing the 423 allocated relayed transport address. The client can include 424 attributes in the Allocate request that describe the type of 425 allocation it desires (e.g., the lifetime of the allocation). Since 426 relaying data may require lots of bandwidth, the server typically 427 requires that the client authenticate itself using STUN's long-term 428 credential mechanism, to show that it is authorized to use the 429 server. 431 Once a relayed transport address is allocated, a client must keep the 432 allocation alive. To do this, the client periodically sends a 433 Refresh request to the server. TURN deliberately uses a different 434 method (Refresh rather than Allocate) for refreshes to ensure that 435 the client is informed if the allocation vanishes for some reason. 437 The frequency of the Refresh transaction is determined by the 438 lifetime of the allocation. The default lifetime of an allocation is 439 10 minutes -- this value was chosen to be long enough so that 440 refreshing is not typically a burden on the client, while expiring 441 allocations where the client has unexpectedly quit in a timely 442 manner. However, the client can request a longer lifetime in the 443 Allocate request and may modify its request in a Refresh request, and 444 the server always indicates the actual lifetime in the response. The 445 client must issue a new Refresh transaction within 'lifetime' seconds 446 of the previous Allocate or Refresh transaction. Once a client no 447 longer wishes to use an Allocation, it should delete the allocation 448 using a Refresh request with a requested lifetime of 0. 450 Both the server and client keep track of a value known as the 451 5-TUPLE. At the client, the 5-tuple consists of the client's host 452 transport address, the server transport address, and the transport 453 protocol used by the client to communicate with the server. At the 454 server, the 5-tuple value is the same except that the client's host 455 transport address is replaced by the client's server-reflexive 456 address, since that is the client's address as seen by the server. 458 Both the client and the server remember the 5-tuple used in the 459 Allocate request. Subsequent messages between the client and the 460 server uses the same 5-tuple. In this way, the client and server 461 know which allocation is being referred to. If the client wishes to 462 allocate a second relayed transport address, it must create a second 463 allocation using a different 5-tuple (e.g., by using a different 464 client host address or port). 466 NOTE: While the terminology used in this document refers to 467 5-tuples, the TURN server can store whatever identifier it likes 468 that yields identical results. Specifically, an implementation 469 may use a file-descriptor in place of a 5-tuple to represent a TCP 470 connection 472 TURN TURN Peer Peer 473 client server A B 474 |-- Allocate request --------------->| | | 475 | | | | 476 |<--------------- Allocate failure --| | | 477 | (401 Unauthorized) | | | 478 | | | | 479 |-- Allocate request --------------->| | | 480 | | | | 481 |<---------- Allocate success resp --| | | 482 | (192.0.2.15:50000) | | | 483 // // // // 484 | | | | 485 |-- Refresh request ---------------->| | | 486 | | | | 487 |<----------- Refresh success resp --| | | 488 | | | | 490 Figure 2 492 In Figure 2, the client sends an Allocate request to the server 493 without credentials. Since the server requires that all requests be 494 authenticated using STUN's long-term credential mechanism, the server 495 rejects the request with a 401 (Unauthorized) error code. The client 496 then tries again, this time including credentials (not shown). This 497 time, the server accepts the Allocate request and returns an Allocate 498 success response containing (amongst other things) the relayed 499 transport address assigned to the allocation. Sometime later the 500 client decides to refresh the allocation and thus sends a Refresh 501 request to the server. The refresh is accepted and the server 502 replies with a Refresh success response. 504 2.3. Permissions 506 To ease concerns amongst enterprise IT administrators that TURN could 507 be used to bypass corporate firewall security, TURN includes the 508 notion of permissions. TURN permissions mimic the address-restricted 509 filtering mechanism of NATs that comply with [RFC4787]. 511 An allocation can have zero or more permissions. Each permission 512 consists of an IP address and a lifetime. When the server receives a 513 UDP datagram on the allocation's relayed transport address, it first 514 checks the list of permissions. If the source IP address of the 515 datagram matches a permission, the application data is relayed to the 516 client, otherwise the UDP datagram is silently discarded. 518 A permission expires after 5 minutes if it is not refreshed, and 519 there is no way to explicitly delete a permission. This behavior was 520 selected to match the behavior of a NAT that complies with [RFC4787]. 522 The client can install or refresh a permission using either a 523 CreatePermission request or a ChannelBind request. Using the 524 CreatePermission request, multiple permissions can be installed or 525 refreshed with a single request -- this is important for applications 526 that use ICE. For security reasons, permissions can only be 527 installed or refreshed by transactions that can be authenticated; 528 thus Send indications and ChannelData messages (which are used to 529 send data to peers) do not install or refresh any permissions. 531 Note that permissions are within the context of an allocation, so 532 adding or expiring a permission in one allocation does not affect 533 other allocations. 535 2.4. Send Mechanism 537 There are two mechanisms for the client and peers to exchange 538 application data using the TURN server. The first mechanism uses the 539 Send and Data methods, the second way uses channels. Common to both 540 ways is the ability of the client to communicate with multiple peers 541 using a single allocated relayed transport address; thus both ways 542 include a means for the client to indicate to the server which peer 543 to forward the data to, and for the server to indicate which peer 544 sent the data. 546 The Send mechanism uses Send and Data indications. Send indications 547 are used to send application data from the client to the server, 548 while Data indications are used to send application data from the 549 server to the client. 551 When using the Send mechanism, the client sends a Send indication to 552 the TURN server containing (a) an XOR-PEER-ADDRESS attribute 553 specifying the (server-reflexive) transport address of the peer and 554 (b) a DATA attribute holding the application data. When the TURN 555 server receives the Send indication, it extracts the application data 556 from the DATA attribute and sends it in a UDP datagram to the peer, 557 using the allocated relay address as the source address. Note that 558 there is no need to specify the relayed transport address, since it 559 is implied by the 5-tuple used for the Send indication. 561 In the reverse direction, UDP datagrams arriving at the relayed 562 transport address on the TURN server are converted into Data 563 indications and sent to the client, with the server-reflexive 564 transport address of the peer included in an XOR-PEER-ADDRESS 565 attribute and the data itself in a DATA attribute. Since the relayed 566 transport address uniquely identified the allocation, the server 567 knows which client to relay the data to. 569 Send and Data indications cannot be authenticated, since the Long- 570 Term Credential Mechanism of STUN does not support authenticating 571 indications. This is not as big an issue as it might first appear, 572 since the client-to-server leg is only half of the total path to the 573 peer; applications that want proper security need to use encryption 574 or similar to protect their data in the UDP datagrams between the 575 server and the peer. However, to prevent attackers from injecting 576 rogue Send indications to arbitrary destinations, TURN requires that 577 a client install a permission to a peer before sending data to it 578 using a Send indication. 580 TURN TURN Peer Peer 581 client server A B 582 | | | | 583 |-- CreatePermission req (Peer A) -->| | | 584 |<-- CreatePermission success resp --| | | 585 | | | | 586 |--- Send ind (Peer A)-------------->| | | 587 | |=== data ===>| | 588 | | | | 589 | |<== data ====| | 590 |<-------------- Data ind (Peer A) --| | | 591 | | | | 592 | | | | 593 |--- Send ind (Peer B)-------------->| | | 594 | | dropped | | 595 | | | | 596 | |<== data ==================| 597 | dropped | | | 598 | | | | 600 Figure 3 602 In Figure 3, the client has already created an allocation and now 603 wishes to send data to its peers. The client first creates a 604 permission by sending the server a CreatePermission request 605 specifying peer A's (server reflexive) IP address in the XOR-PEER- 606 ADDRESS attribute; if this was not done, the server would not relay 607 data between the client and the server. The client then sends data 608 to Peer A using a Send indication; at the server, the application 609 data is extracted and forwarded in a UDP datagram to Peer A, using 610 the relayed transport address as the source transport address. When 611 a UDP datagram from Peer A is received at the relayed transport 612 address, the contents are placed into a Data indication and forwarded 613 to the client. Later, the client attempts to exchange data with Peer 614 B, however no permission has been installed for Peer B, so the Send 615 indication from the client and the UDP datagram from the peer are 616 both dropped by the server. 618 2.5. Channels 620 For some applications (e.g. Voice over IP), the 36 bytes of overhead 621 that a Send indication or Data indication adds to the application 622 data can substantially increase the bandwidth required between the 623 client and the server. To remedy this, TURN offers a second way for 624 the client and server to associate data with a specific peer. 626 This second way uses an alternate packet format known as the 627 ChannelData message. The ChannelData message does not use the STUN 628 header used by other TURN messages, but instead has a 4-byte header 629 that includes a number known as a channel number. Each channel 630 number in use is bound to a specific peer and thus serves as a 631 shorthand for the peer's host transport address. 633 To bind a channel to a peer, the client sends a ChannelBind request 634 to the server, and includes an unbound channel number and the 635 transport address of the peer. Once the channel is bound, the client 636 can use a ChannelData message to send the server data destined for 637 the peer. Similarly, the server can relay data from that peer 638 towards the client using a ChannelData message. 640 Channel bindings last for 10 minutes unless refreshed -- this 641 lifetime was chosen to be longer than the permission lifetime. 642 Channel bindings are refreshed by sending another ChannelBind request 643 rebinding the channel to the peer. Like permissions (but unlike 644 allocations), there is no way to explicitly delete a channel binding; 645 the client must simply wait for it to time out. 646 TURN TURN Peer Peer 647 client server A B 648 | | | | 649 |-- ChannelBind req ---------------->| | | 650 | (Peer A to 0x4001) | | | 651 | | | | 652 |<---------- ChannelBind succ resp --| | | 653 | | | | 654 |-- [0x4001] data ------------------>| | | 655 | |=== data ===>| | 656 | | | | 657 | |<== data ====| | 658 |<------------------ [0x4001] data --| | | 659 | | | | 660 |--- Send ind (Peer A)-------------->| | | 661 | |=== data ===>| | 662 | | | | 663 | |<== data ====| | 664 |<------------------ [0x4001] data --| | | 665 | | | | 667 Figure 4 669 Figure 4 shows the channel mechanism in use. The client has already 670 created an allocation and now wishes to bind a channel to peer A. To 671 do this, the client sends a ChannelBind request to the server, 672 specifying the transport address of Peer A and a channel number 673 (0x4001). After that, the client can send application data 674 encapsulated inside ChannelData messages to Peer A: this is shown as 675 "[0x4001] data" where 0x4001 is the channel number. When the 676 ChannelData message arrives at the server, the server transfers the 677 data to a UDP datagram and sends it to the peer A, as indicated by 678 the channel number. When peer A sends a UDP datagram to the relayed 679 transport address, the data is placed inside a ChannelData message 680 and sent to the client. 682 Once a channel has been bound, the client is free to intermix 683 ChannelData messages and Send indications. In the figure, the client 684 later decides to use a Send indication rather than a ChannelData 685 message to send additional data to peer A. The client might decide to 686 do this, for example, so it can use the DONT-FRAGMENT attribute (see 687 the next section). However, once a channel is bound, the server will 688 always use a ChannelData message, as shown in the call flow. 690 Note that ChannelData messages can only be used for peers to which 691 the client has bound a channel. In the example above, Peer A has 692 been bound to a channel, but Peer B has not, so application data to 693 and from Peer B would use the Send mechanism. 695 2.6. Unprivileged TURN Servers 697 This version of TURN is designed so that the server can be 698 implemented as an application that runs in user space under commonly 699 available operating systems without requiring special privileges. 700 This design decision was taken to make it easy to deploy a TURN 701 server: for example, to allow a TURN server to be integrated into a 702 peer-to-peer application so that one peer can offer NAT traversal 703 services to another peer. 705 This design decision has the following implications for data relayed 706 by a TURN server: 708 o The value of the Diff-Serv field may not be preserved across the 709 server; 711 o The TTL field may be reset, rather than decremented, across the 712 server; 714 o The ECN field may be reset by the server; 716 o ICMP messages are not relayed by the server; 718 o There is no end-to-end fragmentation, since the packet is re- 719 assembled at the server. 721 Future work may specify alternate TURN semantics that address these 722 limitations. 724 2.7. Avoiding IP Fragmentation 726 For reasons described in [Frag-Harmful], applications, especially 727 those sending large volumes of data, should try hard to avoid having 728 their packets fragmented. Applications using TCP can more-or-less 729 ignore this issue because fragmentation avoidance is now a standard 730 part of TCP, but applications using UDP (and thus any application 731 using this version of TURN) must handle fragmentation avoidance 732 themselves. 734 The application running on the client and the peer can take one of 735 two approaches to avoid IP fragmentation. 737 The first approach is to avoid sending large amounts of application 738 data in the TURN messages/UDP datagrams exchanged between the client 739 and the peer. This is the approach taken by most VoIP 740 (Voice-over-IP) applications. In this approach, the application 741 exploits the fact that the IP specification [RFC0791] specifies that 742 IP packets up to 576 bytes should never need to be fragmented. 744 The exact amount of application data that can be included while 745 avoiding fragmentation depends the details of the TURN session 746 between the client and the server: whether UDP, TCP, or TLS transport 747 is used, whether ChannelData messages or Send/Data indications are 748 used, and whether any additional attributes (such as the DONT- 749 FRAGMENT attribute) are included. Another factor, which is hard to 750 determine, is whether the MTU is somewhere along the path is reduced 751 for other reasons, such as the use of IP-in-IP tunneling. 753 As a guideline, sending a maximum of 500 bytes of application data in 754 a single TURN message (by the client on the client-to-server leg) or 755 a UDP datagram (by the peer on the peer-to-server leg) will generally 756 avoid IP fragmentation. To further reduce the chance of 757 fragmentation, it is recommended that the client use ChannelData 758 messages when transferring significant volumes of data, since the 759 overhead of the ChannelData message is less than Send and Data 760 indications. 762 The second approach the client and peer can take to avoid 763 fragmentation is to use a path MTU discovery algorithm to determine 764 the maximum amount of application data than can be sent without 765 fragmentation. 767 Unfortunately, because servers implementing this version of TURN do 768 not relay ICMP messages, the classic Path MTU Discovery algorithm 769 defined in [RFC1191] is not able to discover the MTU of the 770 transmission path between the client and the peer. (Even if they did 771 relay ICMP messages, the algorithm would not always work since ICMP 772 messages are often filtered out by combined NAT/firewall devices). 774 So the client and server need to use a path MTU discovery algorithm 775 that does not require ICMP messages. The Packetized Path MTU 776 Discovery algorithm defined in [RFC4821] is one such algorithm. 778 The details of how to use the algorithm of [RFC4821] with TURN are 779 still under investigation. However, as a step towards this goal, 780 this version of TURN supports a DONT-FRAGMENT attribute. When the 781 client includes this attribute in a Send indication, this tells the 782 server to set the DF bit in the resulting UDP datagram that it sends 783 to the peer. Since some servers may be unable to set the DF bit, the 784 client should also include this attribute in the Allocate request -- 785 any server that does not support the DONT-FRAGMENT attribute will 786 indicate this by rejecting the Allocate request. 788 2.8. RTP Support 790 One of the envisioned uses of TURN is as a relay for clients and 791 peers wishing to exchange real-time data (e.g. voice or video) using 792 RTP. To facilitate the use of TURN for this purpose, TURN includes 793 some special support for older versions of RTP. 795 Old versions of RTP [RFC3550] required that the RTP stream be on an 796 even port number and the associated RTCP stream, if present, be on 797 the next highest port. To allow clients to work with peers that 798 still require this, TURN allows the client to request that the server 799 allocate a relayed-transport-address with an even port number, and to 800 optionally request the server reserve the next-highest port number 801 for a subsequent allocation. 803 2.9. Anycast Discovery of Servers 805 This version of TURN has been designed to permit the future 806 specification of a method of doing anycast discovery of a TURN server 807 over UDP. 809 Specifically, a TURN server can reject an Allocate request with the 810 suggestion that the server try an alternate server. To avoid certain 811 types of attacks, the client must use the same credentials with the 812 alternate server as it would have with the initial server. 814 3. Terminology 816 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 817 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 818 document are to be interpreted as described in RFC 2119 [RFC2119]. 820 Readers are expected to be familiar with [RFC5389] and the terms 821 defined there. 823 The following terms are used in this document: 825 TURN: The protocol spoken between a TURN client and a TURN server. 826 It is an extension to the STUN protocol [RFC5389]. The protocol 827 allows a client to allocate and use a relayed transport address. 829 TURN client: A STUN client that implements this specification. 831 TURN server: A STUN server that implements this specification. It 832 relays data between a TURN client and its peer(s). 834 Peer: A host with which the TURN client wishes to communicate. The 835 TURN server relays traffic between the TURN client and its 836 peer(s). The peer does not interact with the TURN server using 837 the protocol defined in this document; rather, the peer receives 838 data sent by the TURN server and the peer sends data towards the 839 TURN server. 841 Transport Address: The combination of an IP address and a port. 843 Host Transport Address: A transport address on a client or a peer. 845 Server-Reflexive Transport Address: A transport address on the 846 "public side" of a NAT. This address is allocated by the NAT to 847 correspond to a specific host transport address. 849 Relayed Transport Address: A transport address on the TURN server 850 that is used for relaying packets between the client and a peer. 851 A peer sends to this address on the TURN server, and the packet is 852 then relayed to the client. 854 TURN Server Transport Address: A transport address on the TURN 855 server that is used for sending TURN messages to the server. This 856 is the transport address that the client uses to communicate with 857 the server. 859 Peer Transport Address: The transport address of the peer as seen by 860 the server. When the peer is behind a NAT, this is the peer's 861 server-reflexive transport address. 863 Allocation: The relayed transport address granted to a client 864 through an Allocate request, along with related state, such as 865 permissions and expiration timers. 867 5-tuple: The combination (client IP address and port, server IP 868 address and port, and transport protocol (currently one of UDP, 869 TCP, or TLS)) used to communicate between the client and the 870 server. The 5-tuple uniquely identifies this communication 871 stream. The 5-tuple also uniquely identifies the Allocation on 872 the server. 874 Channel: A channel number and associated peer transport address. 875 Once a channel number is bound to a peer's transport address, the 876 client and server can use the more bandwidth-efficient ChannelData 877 message to exchange data. 879 Permission: The IP address and transport protocol (but not the port) 880 of a peer that is permitted to send traffic to the TURN server and 881 have that traffic relayed to the TURN client. The TURN server 882 will only forward traffic to its client from peers that match an 883 existing permission. 885 Realm A string used to describe the server or a context within the 886 server. The realm tells the client which username and password 887 combination to use to authenticate requests. 889 Nonce A string chosen at random by the server and included in the 890 message-digest. To prevent reply attacks, the server should 891 change the nonce regularly. 893 4. General Behavior 895 This section contains general TURN processing rules that apply to all 896 TURN messages. 898 TURN is an extension to STUN. All TURN messages, with the exception 899 of the ChannelData message, are STUN-formatted messages. All the 900 base processing rules described in [RFC5389] apply to STUN-formatted 901 messages. This means that all the message-forming and -processing 902 descriptions in this document are implicitly prefixed with the rules 903 of [RFC5389]. 905 In addition, the server SHOULD demand that all requests from the 906 client be authenticated, using the Long-Term Credential mechanism 907 described in [RFC5389], and the client MUST be prepared to 908 authenticate requests if required. Note that this authentication 909 mechanism applies only to requests and cannot be used to authenticate 910 indications, thus indications in TURN are never authenticated. If 911 the server requires requests to be authenticated, then the server's 912 administrator MUST choose a realm value that will uniquely identify 913 the username and password combination that the client must use, even 914 if the client uses multiple servers under different administrations. 915 The server's administrator MAY choose to allocate a unique username 916 to each client, or MAY choose to allocate the same username to more 917 than one client (for example, to all clients from the same department 918 or company). For each allocation, the server SHOULD generate a new 919 random nonce when the allocation is first attempted following the 920 randomness recommendations in [RFC4086] and SHOULD expire the nonce 921 at least once every hour during the lifetime of the allocation. 923 All requests after the initial Allocate must use the same username as 924 that used to create the allocation, to prevent attackers from 925 hijacking the client's allocation. Specifically, if the server 926 requires the use of the Long-Term Credential mechanism, and if a non- 927 Allocate request passes authentication under this mechanism, and if 928 the 5-tuple identifies an existing allocation, but the request does 929 not use the same username as used to create the allocation, then the 930 request MUST be rejected with a 441 (Wrong Credentials) error. 932 When a TURN message arrives at the server from the client, the server 933 uses the 5-tuple in the message to identify the associated 934 allocation. For all TURN messages (including ChannelData) EXCEPT an 935 Allocate request, if the 5-tuple does not identify an existing 936 allocation, then the message MUST either be rejected with a 437 937 Allocation Mismatch error (if it is a request), or silently ignored 938 (if it is an indication or a ChannelData message). A client 939 receiving a 437 error response to a request other than Allocate MUST 940 assume the allocation no longer exists. 942 The client SHOULD include the SOFTWARE attribute in all Allocate and 943 Refresh requests and MAY include it in any other requests or 944 indications. The server SHOULD include the SOFTWARE attribute in all 945 Allocate and Refresh responses (either success or failure) and MAY 946 include it in other responses or indications. The client and the 947 server MAY include the FINGERPRINT attribute in any STUN-formatted 948 messages defined in this document. 950 TURN does not use the backwards-compatibility mechanism described in 951 [RFC5389]. 953 By default, TURN runs on the same ports as STUN: 3478 for TURN over 954 UDP and TCP, and 5349 for TURN over TLS. However, TURN has its own 955 set of SRV service names: "turn" for UDP and TCP, and "turns" for 956 TLS. Either the SRV procedures or the ALTERNATE-SERVER procedures, 957 both described in Section 6, can be used to run TURN on a different 958 port. 960 TURN as defined in this specification only supports IPv4. The 961 client's IP address, the server's IP address and all IP addresses 962 appearing in a relayed-transport-address MUST be IPv4 addresses. 964 When UDP transport is used between the client and the server, the 965 client will retransmit a request if it does not receive a response 966 within a certain timeout period. Because of this, the server may 967 receive two (or more) requests with the same 5-tuple and same 968 transaction id. STUN requires that the server recognize this case 969 and treat the request as idempotent (see [RFC5389]). Some 970 implementations may choose to meet this requirement by remembering 971 all received requests and the corresponding responses for 40 seconds. 972 Other implementations may choose to reprocess the request and arrange 973 that such reprocessing returns essentially the same response. To aid 974 implementors who choose the latter approach (the so-called "stateless 975 stack approach"), this specification includes some implementation 976 notes on how this might be done. Implementations are free to choose 977 either approach or choose some other approach that gives the same 978 results. 980 When TCP transport is used between the client and the server, it is 981 possible that a bit error will cause a length field in a TURN packet 982 to become corrupted, causing the receiver to lose synchronization 983 with the incoming stream of TURN messages. A client or server which 984 detects a long sequence of invalid TURN messages over TCP transport 985 SHOULD close the corresponding TCP connection to help the other end 986 detect this situation more rapidly. 988 To mitigate either intentional or unintentional denial-of-service 989 attacks against the server by clients with valid usernames and 990 passwords, it is RECOMMENDED that the server impose limits on both 991 the number of allocations active at one time for a given username and 992 on the amount of bandwidth those allocations can use. The server 993 should reject new allocations that would exceed the limit on the 994 allowed number of allocations active at one time with a 486 995 (Allocation Quota Exceeded) (see Section 6.2), and should discard 996 application data traffic that exceeds the bandwidth quota. 998 5. Allocations 1000 All TURN operations revolve around allocations, and all TURN messages 1001 are associated with an allocation. An allocation conceptually 1002 consists of the following state data: 1004 o the relayed transport address 1006 o The 5-tuple: (client's IP address, client's port, server IP 1007 address, server port, transport protocol) 1009 o the authentication information 1011 o the time-to-expiry 1013 o A list of permissions 1015 o A list of channel to peer bindings 1017 The relayed transport address is the transport address allocated by 1018 the server for communicating with peers, while the 5-tuple describes 1019 the communication path between the client and the server. On the 1020 client, the 5-tuple uses the client's host transport address, while 1021 on the server the 5-tuple uses the client's server-reflexive 1022 transport address. 1024 Both the relayed-transport-address and the 5-tuple MUST be unique 1025 across all allocations, so either one can be used to uniquely 1026 identify the allocation. 1028 The authentication information (e.g., username, password, realm, and 1029 nonce) are used to both verify subsequent requests and to compute the 1030 message integrity of responses. The username, realm, and nonce 1031 values are initially those used in the authenticated Allocate request 1032 that creates the allocation, though the server can change the nonce 1033 value during the lifetime of the allocation using a 438 (Stale Nonce) 1034 reply. Note that rather than storing the password explicitly, it may 1035 be desirable for security reasons for the server to store the key 1036 value which is an MD5 hash over the username, realm and password (see 1037 [RFC5389]). 1039 The time-to-expiry is the time in seconds left until the allocation 1040 expires. Each Allocate or Refresh transaction sets this timer, which 1041 then ticks down towards 0. By default, each Allocate or Refresh 1042 transaction resets this timer to the default lifetime value of 600 1043 seconds (10 minutes), but the client can request a different value in 1044 the Allocate and Refresh request. Allocations can only be refreshed 1045 using the Refresh request; sending data to a peer does not refresh an 1046 allocation. When an allocation expires, the state data associated 1047 with the allocation can be freed. 1049 The list of permissions is described in Section 8 and the list of 1050 channels is described in Section 11. 1052 6. Creating an Allocation 1054 An allocation on the server is created using an Allocate transaction. 1056 6.1. Sending an Allocate Request 1058 The client forms an Allocate request as follows. 1060 The client first picks a host transport address. It is RECOMMENDED 1061 that the client pick a currently-unused transport address, typically 1062 by allowing the underlying OS to pick a currently-unused port for a 1063 new socket. 1065 The client then picks a transport protocol to use between the client 1066 and the server. The transport protocol MUST be one of UDP, TCP, or 1067 TLS over TCP. Since this specification only allows UDP between the 1068 server and the peers, it is RECOMMENDED that the client pick UDP 1069 unless it has a reason to use a different transport. One reason to 1070 pick a different transport would be that the client believes, either 1071 through configuration or by experiment, that it is unable to contact 1072 any TURN server using UDP. See Section 2.1 for more discussion. 1074 The client also picks a server transport address, which SHOULD be 1075 done as follows. The client receives (perhaps through configuration) 1076 a domain name for a TURN server. The client then uses the DNS 1077 procedures described in [RFC5389], but using an SRV service name of 1078 "turn" (or "turns" for TURN over TLS) instead of "stun" (or "stuns"). 1079 For example, to find servers in the example.com domain, the client 1080 performs a lookup for '_turn._udp.example.com', 1081 '_turn._tcp.example.com', and '_turns._tcp.example.com' if the client 1082 wants to communicate with the server using UDP, TCP, or TLS over TCP, 1083 respectively. 1085 The client MUST include a REQUESTED-TRANSPORT attribute in the 1086 request. This attribute specifies the transport protocol between the 1087 server and the peers (note that this is NOT the transport protocol 1088 that appears in the 5-tuple). In this specification, the REQUESTED- 1089 TRANSPORT type is always UDP. This attribute is included to allow 1090 future extensions specify other protocols. 1092 If the client wishes the server to initialize the time-to-expiry 1093 field of the allocation to some value other the default lifetime, 1094 then it MAY include a LIFETIME attribute specifying its desired 1095 value. This is just a request, and the server may elect to use a 1096 different value. Note that the server will ignore requests to 1097 initialize the field to less than the default value. 1099 If the client wishes to later use the DONT-FRAGMENT attribute in one 1100 or more Send indications on this allocation, then the client SHOULD 1101 include the DONT-FRAGMENT attribute in the Allocate request. This 1102 allows the client to test whether this attribute is supported by the 1103 server. 1105 If the client requires the port number of the relayed-transport 1106 address be even, the client includes the EVEN-PORT attribute. If 1107 this attribute is not included, then the port can be even or odd. By 1108 setting the R bit in the EVEN-PORT attribute to 1, the client can 1109 request that the server reserve the next highest port number (on the 1110 same IP address) for a subsequent allocation. If the R bit is 0, no 1111 such request is made. 1113 The client MAY also include a RESERVATION-TOKEN attribute in the 1114 request to ask the server to use a previously reserved port for the 1115 allocation. If the RESERVATION-TOKEN attribute is included, then the 1116 client MUST omit the EVEN-PORT attribute. 1118 Once constructed, the client sends the Allocate request on the 1119 5-tuple. 1121 6.2. Receiving an Allocate Request 1123 When the server receives an Allocate request, it performs the 1124 following checks: 1126 1. The server SHOULD require that the request be authenticated using 1127 the Long-Term Credential mechanism of [RFC5389]. 1129 2. The server checks if the 5-tuple is currently in use by an 1130 existing allocation. If yes, the server rejects the request with 1131 a 437 (Allocation Mismatch) error. 1133 3. The server checks if the request contain a REQUESTED-TRANSPORT 1134 attribute. If the REQUESTED-TRANSPORT attribute is not included 1135 or is malformed, the server rejects the request with a 400 (Bad 1136 Request) error. Otherwise, if the attribute is included but 1137 specifies a protocol other that UDP, the server rejects the 1138 request with a 442 (Unsupported Transport Protocol) error. 1140 4. The request may contain a DONT-FRAGMENT attribute. If it does, 1141 but the server does not support sending UDP datagrams with the DF 1142 bit set to 1 (see Section 12), then the server treats the DONT- 1143 FRAGMENT attribute in the Allocate request as an unknown 1144 comprehension-required attribute. 1146 5. The server checks if the request contains a RESERVATION-TOKEN 1147 attribute. If yes, and the request also contains a EVEN-PORT 1148 attribute, then the server rejects the request with a 400 (Bad 1149 Request) error. Otherwise it checks to see if the token is valid 1150 (i.e., the token is in range and has not expired, and the 1151 corresponding relayed transport address is still available). If 1152 the token is not valid for some reason, the server rejects the 1153 request with a 508 (Insufficient Port Capacity) error. 1155 6. The server checks if the request contains an EVEN-PORT attribute. 1156 If yes, then the server checks that it can satisfy the request 1157 (i.e., can allocate a relayed-transport-address as described 1158 below). If the server cannot satisfy the request, then the 1159 server rejects the request with a 508 (Insufficient Port 1160 Capacity) error. 1162 7. At any point, the server MAY choose to reject the request with a 1163 486 (Allocation Quota Reached) error if it feels the client is 1164 trying to exceed some locally-defined allocation quota. The 1165 server is free to define this allocation quota any way it wishes, 1166 but SHOULD define it based on the username used to authenticate 1167 the request, and not on the client's transport address. 1169 8. Also at any point, the server MAY choose to reject the request 1170 with a 300 (Try Alternate) error if it wishes to redirect the 1171 client to a different server. The use of this error code and 1172 attribute follow the specification in [RFC5389], with the 1173 modification that a TURN server MAY return this error code and 1174 attribute in unauthenticated error responses as well as in 1175 authenticated error responses. 1177 If all the checks pass, the server creates the allocation. The 1178 5-tuple is set to the 5-tuple from the Allocate request, while the 1179 list of permissions and the list of channels are initially empty. 1181 The server chooses a relayed-transport-address for the allocation as 1182 follows: 1184 o If the request contains a RESERVATION-TOKEN, the server uses the 1185 previously-reserved transport address corresponding to the 1186 included token (if it is still available). Note that the 1187 reservation is a server-wide reservation and is not specific to a 1188 particular allocation, since the Allocate request containing the 1189 RESERVATION-TOKEN uses a different 5-tuple than the Allocate 1190 request that made the reservation. The 5-tuple for the Allocate 1191 request containing the RESERVATION-TOKEN attribute can be any 1192 allowed 5-tuple; it can use a different client IP address and 1193 port, a different transport protocol, and even different server IP 1194 address and port (provided, of course, that the server IP address 1195 and port is one that the server is listening for TURN requests 1196 on). 1198 o If the request contains an EVEN-PORT attribute with the R bit set 1199 to 0, then the server allocates a relayed-transport-address with 1200 an even port number. 1202 o If the request contains an EVEN-PORT attribute with the R bit set 1203 to 1, then the server looks for a pair of port numbers N and N+1 1204 on the same IP address, where N is even. Port N is used in the 1205 current allocation, while the relayed transport address with port 1206 N+1 is assigned a token and reserved for a future allocation. The 1207 server MUST hold this reservation for at least 30 seconds, and MAY 1208 choose to hold longer (e.g. until the allocation with port N 1209 expires). The server then includes the token in a RESERVATION- 1210 TOKEN attribute in the success response. 1212 o Otherwise, the server allocates any available relayed-transport- 1213 address. 1215 In all cases, the server SHOULD only allocate ports from the range 1216 49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]), 1217 unless the TURN server application knows, through some means not 1218 specified here, that other applications running on the same host as 1219 the TURN server application will not be impacted by allocating ports 1220 outside this range. This condition can often be satisfied by running 1221 the TURN server application on a dedicated machine and/or by 1222 arranging that any other applications on the machine allocate ports 1223 before the TURN server application starts. In any case, the TURN 1224 server SHOULD NOT allocate ports in the range 0 - 1023 (the Well- 1225 Known Port range) to discourage clients from using TURN to run 1226 standard services. 1228 NOTE: The IETF is currently investigating the topic of randomized 1229 port assignments to avoid certain types of attacks (see 1230 [I-D.ietf-tsvwg-port-randomization]). It is strongly recommended 1231 that a TURN implementor keep abreast of this topic and, if 1232 appropriate, implement a randomized port assignment algorithm. 1233 This is especially applicable to servers that choose to pre- 1234 allocate a number of ports from the underlying OS and then later 1235 assign them to allocations; for example, a server may choose this 1236 technique to implement the EVEN-PORT attribute. 1238 The server determines the initial value of the time-to-expiry field 1239 as follows. If the request contains a LIFETIME attribute, then the 1240 server computes MIN(client's proposed lifetime, server's maximum 1241 allowed lifetime). If this computed lifetime is greater than the 1242 default lifetime, then the server uses that value. Otherwise, the 1243 server uses the default lifetime. It is RECOMMENDED that the server 1244 use a maximum allowed lifetime value of no more than 3600 seconds (1 1245 hour). Servers that implement allocation quotas or charge users for 1246 allocations in some way may wish to use a smaller maximum allowed 1247 lifetime (perhaps as small as the default lifetime) to more quickly 1248 remove orphaned allocations (that is, allocations where the 1249 corresponding client has crashed or terminated or the client 1250 connection has been lost for some reason). Also note that the time- 1251 to-expiry is recomputed with each successful Refresh request, and 1252 thus the value computed here applies only until the first refresh. 1254 Once the allocation is created, the server replies with a success 1255 response. The success response contains: 1257 o A XOR-RELAYED-ADDRESS attribute containing the relayed transport 1258 address; 1260 o A LIFETIME attribute containing the current value of the time-to- 1261 expiry timer; 1263 o A RESERVATION-TOKEN attribute (if a second relayed transport 1264 address was reserved). 1266 o An XOR-MAPPED-ADDRESS attribute containing the client's IP address 1267 and port (from the 5-tuple). 1269 NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response 1270 as a convenience to the client. TURN itself does not make use of 1271 this value, but clients running ICE can often need this value and 1272 can thus avoid having to do an extra Binding transaction with some 1273 STUN server to learn it. 1275 The response (either success or error) is sent back to the client on 1276 the 5-tuple. 1278 NOTE: Implementations may implement the idempotency of the 1279 Allocate request over UDP using the so-called "stateless stack 1280 approach" as follows. To detect retransmissions when the original 1281 request was successful in creating an allocation, the server can 1282 store the transaction id that created the request with the 1283 allocation data and compare it with incoming Allocate requests on 1284 the same 5-tuple. Once such a request is detected, the server can 1285 stop parsing the request and immediately generate a success 1286 response. When building this response, the value of the LIFETIME 1287 attribute can be taken from the time-to-expiry field in the 1288 allocate state data, even though this value may differ slightly 1289 from the LIFETIME value originally returned. In addition, the 1290 server may need to store an indication of any reservation token 1291 returned in the original response, so that this may be returned in 1292 any retransmitted responses. 1294 For the case where the original request was unsuccessful in 1295 creating an allocation, the server may choose to do nothing 1296 special. Note, however, that there is a rare case where the 1297 server rejects the original request but accepts the retransmitted 1298 request (because conditions have changed in the brief intervening 1299 time period). If the client receives the first failure response, 1300 it will ignore the second (success) response and believe that an 1301 allocation was not created. An allocation created in this matter 1302 will eventually timeout, since the client will not refresh it. 1303 Furthermore, if the client later retries with the same 5-tuple but 1304 different transaction id, it will receive a 437 (Allocation 1305 Mismatch), which will cause it to retry with a different 5-tuple. 1306 The server may use a smaller maximum lifetime value to minimize 1307 the lifetime of allocations "orphaned" in this manner. 1309 6.3. Receiving an Allocate Success Response 1311 If the client receives an Allocate success response, then it MUST 1312 check that the mapped address and the relayed transport address are 1313 in an address family that the client understands and is prepared to 1314 deal with. This specification only covers the case where these two 1315 addresses are IPv4 addresses. If these two addresses are not in an 1316 address family that the client is prepared to deal with, then the 1317 client MUST delete the allocation (Section 7) and MUST NOT attempt to 1318 create another allocation on that server until it believes the 1319 mismatch has been fixed. 1321 The IETF is currently considering mechanisms for transitioning 1322 between IPv4 and IPv6 that could result in a client originating an 1323 Allocate request over IPv6, but the request would arrive at the 1324 server over IPv4, or vica-versa. Hence the importance of this 1325 check. 1327 Otherwise, the client creates its own copy of the allocation data 1328 structure to track what is happening on the server. In particular, 1329 the client needs to remember the actual lifetime received back from 1330 the server, rather than the value sent to the server in the request. 1331 The client must also remember the 5-tuple used for the request and 1332 the username and password it used to authenticate the request to 1333 ensure that it reuses them for subsequent messages. The client also 1334 needs to track the channels and permissions it establishes on the 1335 server. 1337 The client will probably wish to send the relayed transport address 1338 to peers (using some method not specified here) so the peers can 1339 communicate with it. The client may also wish to use the server- 1340 reflexive address it receives in the XOR-MAPPED-ADDRESS attribute in 1341 its ICE processing. 1343 6.4. Receiving an Allocate Error Response 1345 If the client receives an Allocate error response, then the 1346 processing depends on the actual error code returned: 1348 o (Request timed out): There is either a problem with the server, or 1349 a problem reaching the server with the chosen transport. The 1350 client considers the current transaction as having failed but MAY 1351 choose to retry the Allocate request using a different transport 1352 (e.g., TCP instead of UDP). 1354 o 300 (Try Alternate): The server would like the client to use the 1355 server specified in the ALTERNATE-SERVER attribute instead. The 1356 client considers the current transaction as having failed, but 1357 SHOULD try the Allocate request with the alternate server before 1358 trying any other servers (e.g., other servers discovered using the 1359 SRV procedures). When trying the Allocate request with the 1360 alternate server, the client follows the ALTERNATE-SERVER 1361 procedures specified in [RFC5389] with the following changes: the 1362 client SHOULD accept unauthenticated error responses containing 1363 the 300 (Try Alternate) error code, the client MUST ensure that 1364 the realm value received from the alternate server is as expected, 1365 the client MUST use the same transport protocol to the alternate 1366 server as it used to the original server, and the client MUST use 1367 the same username and password as it would have with the original 1368 server. The latter checks protect against an attacker sending the 1369 client an unauthenticated Allocate error response that redirects 1370 the client to some totally different and unexpected server. 1372 o 400 (Bad Request): The server believes the client's request is 1373 malformed for some reason. The client considers the current 1374 transaction as having failed. The client MAY notify the user or 1375 operator and SHOULD NOT retry the request with this server until 1376 it believes the problem has been fixed. 1378 o 401 (Unauthorized): If the client has followed the procedures of 1379 the Long-Term Credential mechanism and still gets this error, then 1380 the server is not accepting the client's credentials. In this 1381 case, the client considers the current transaction as having 1382 failed and SHOULD notify the user or operator. The client SHOULD 1383 NOT send any further requests to this server until it believes the 1384 problem has been fixed. 1386 o 403 (Forbidden): The request is valid, but the server is refusing 1387 to perform it, likely due to administrative restrictions. The 1388 client considers the current transaction as having failed. The 1389 client MAY notify the user or operator and SHOULD NOT retry the 1390 same request with this server until it believes the problem has 1391 been fixed. 1393 o 420 (Unknown Attribute): If the client included a DONT-FRAGMENT 1394 attribute in the request and the server rejected the request with 1395 a 420 error code and listed the DONT-FRAGMENT attribute in the 1396 UNKNOWN-ATTRIBUTES attribute in the error response, then the 1397 client now knows that the server does not support the DONT- 1398 FRAGMENT attribute. The client considers the current transaction 1399 as having failed but MAY choose to retry the Allocate request 1400 without the DONT-FRAGMENT attribute. 1402 o 437 (Allocation Mismatch): This indicates that the client has 1403 picked a 5-tuple which the server sees as already in use. One way 1404 this could happen is if an intervening NAT assigned a mapped 1405 transport address that was used by another client which recently 1406 crashed. The client considers the current transaction as having 1407 failed. The client SHOULD pick another client transport address 1408 and retry the Allocate request (using a different transaction id). 1409 The client SHOULD try three different client transport addresses 1410 before giving up on this server. Once the client gives up on the 1411 server, it SHOULD NOT try to create another allocation on the 1412 server for 2 minutes. 1414 o 438 (Stale Nonce): See the procedures for the Long-Term Credential 1415 mechanism [RFC5389]. 1417 o 441 (Wrong Credentials): The client should not receive this error 1418 in response to a Allocate request. The client MAY notify the user 1419 or operator and SHOULD NOT retry the same request with this server 1420 until it believes the problem has been fixed. 1422 o 442 (Unsupported Transport Address): The client should not receive 1423 this error in response to a request for a UDP allocation. The 1424 client MAY notify the user or operator and SHOULD NOT reattempt 1425 the request with this server until it believes the problem has 1426 been fixed. 1428 o 486 (Allocation Quota Reached): The server is currently unable to 1429 create any more allocations with this username. The client 1430 considers the current transaction as having failed. The client 1431 SHOULD wait at least 1 minute before trying to create any more 1432 allocations on the server. 1434 o 508 (Insufficient Port Capacity): The server has no more relayed 1435 transport addresses available, or has none with the requested 1436 properties, or the one that was reserved is no longer available. 1437 The client considers the current operation as having failed. If 1438 the client is using either the EVEN-PORT or the RESERVATION-TOKEN 1439 attribute, then the client MAY choose to remove or modify this 1440 attribute and try again immediately. Otherwise, the client SHOULD 1441 wait at least 1 minute before trying to create any more 1442 allocations on this server. 1444 7. Refreshing an Allocation 1446 A Refresh transaction can be used to either (a) refresh an existing 1447 allocation and update its time-to-expiry, or (b) delete an existing 1448 allocation. 1450 If a client wishes to continue using an allocation, then the client 1451 MUST refresh it before it expires. It is suggested that the client 1452 refresh the allocation roughly 1 minute before it expires. If a 1453 client no longer wishes to use an allocation, then it SHOULD 1454 explicitly delete the allocation. A client MAY also refresh an 1455 allocation at any time for other reasons. 1457 7.1. Sending a Refresh Request 1459 If the client wishes to immediately delete an existing allocation, it 1460 includes a LIFETIME attribute with a value of 0. All other forms of 1461 the request refresh the allocation. 1463 The Refresh transaction updates the time-to-expiry timer of an 1464 allocation. If the client wishes the server to set the time-to- 1465 expiry timer to something other than the default lifetime, it 1466 includes a LIFETIME attribute with the requested value. The server 1467 then computes a new time-to-expiry value in the same way as it does 1468 for an Allocate transaction, with the exception that a requested 1469 lifetime of 0 causes the server to immediately delete the allocation. 1471 7.2. Receiving a Refresh Request 1473 When the server receives a Refresh request, it processes as per 1474 Section 4 plus the specific rules mentioned here. 1476 The server computes a value called the "desired lifetime" as follows: 1477 If the request contains a LIFETIME attribute and the attribute value 1478 is 0, then the "desired lifetime" is 0. Otherwise, if the request 1479 contains a LIFETIME attribute, then the server computes MIN(client's 1480 requested lifetime, server's maximum allowed lifetime). If this 1481 computed value is greater than the default lifetime, then the 1482 "desired lifetime" is the computed value. Otherwise the "desired 1483 lifetime" is the default lifetime. 1485 Subsequent processing depends on the desired lifetime value: 1487 o If desired lifetime is 0, then the request succeeds and the 1488 allocation is deleted. 1490 o If the desired lifetime is non-zero, then the request succeeds and 1491 the allocation's time-to-expiry is set to the desired lifetime 1493 If the request succeeds, then server sends a success response 1494 containing: 1496 o A LIFETIME attribute containing the current value of the time-to- 1497 expiry timer. 1499 NOTE: A server need not do anything special to implement 1500 idempotency of Refresh requests over UDP using the "stateless 1501 stack approach". Retransmitted Refresh requests with a non-zero 1502 desired lifetime will simply refresh the allocation. A 1503 retransmitted Refresh request with a zero desired lifetime will 1504 cause a 437 (Allocation Mismatch) response if the allocation has 1505 already been deleted, but the client will treat this as equivalent 1506 to a success response (see below). 1508 7.3. Receiving a Refresh Response 1510 If the client receives a success response to its Refresh request with 1511 a non-zero lifetime, it updates its copy of the allocation data 1512 structure with the time-to-expiry value contained in the response. 1514 If the client receives a 437 (Allocation Mismatch) error response to 1515 a request to delete the allocation, then the allocation no longer 1516 exists and it should consider its request as having effectively 1517 succeeded. 1519 8. Permissions 1521 For each allocation, the server keeps a list of zero or more 1522 permissions. Each permission consists of an IP address which 1523 uniquely identifies the permission, and an associated time-to-expiry. 1524 The IP address describes a set of peers that are allowed to send data 1525 to the client, and the time-to-expiry is the number of seconds until 1526 the permission expires. 1528 By sending either CreatePermission requests or ChannelBind requests, 1529 the client can cause the server to install or refresh a permission 1530 for a given IP address. This causes one of two things to happen: 1532 o If no permission for that IP address exists, then a permission is 1533 created with the given IP address and a time-to-expiry equal to 1534 Permission Lifetime. 1536 o If a permission for that IP address already exists, then the time- 1537 to-expiry for that permission is reset to Permission Lifetime. 1539 The Permission Lifetime MUST be 300 seconds (= 5 minutes). 1541 Each permission's time-to-expiry decreases down once per second until 1542 it reaches 0, at which point the permission expires and is deleted. 1544 CreatePermission and ChannelBind requests may be freely intermixed on 1545 a permission. A given permission may be installed or refreshed at 1546 one point in time with a CreatePermission request, and then refreshed 1547 with a ChannelBind request at a different point in time, or vice- 1548 versa. 1550 When a UDP datagram arrives at the relayed transport address for the 1551 allocation, the server checks the list of permissions for that 1552 allocation. If there is a permission with an IP address that is 1553 equal to the source IP address of the UDP datagram, then the UDP 1554 datagram can be relayed to the client. Otherwise, the UDP datagram 1555 is silently discarded. Note that only IP addresses are compared; 1556 port numbers are irrelevant. 1558 The permissions for one allocation are totally unrelated to the 1559 permissions for a different allocation. If an allocation expires, 1560 all its permissions expire with it. 1562 NOTE: Though TURN permissions expire after 5 minutes, many NATs 1563 deployed at the time of publication expire their UDP bindings 1564 considerably faster. Thus an application using TURN will probably 1565 wish to send some sort of keep-alive traffic at a much faster 1566 rate. Applications using ICE should follow the keep-alive 1567 guidelines of ICE [I-D.ietf-mmusic-ice], and applications not 1568 using ICE are advised to do something similar. 1570 9. CreatePermission 1572 TURN supports two ways for the client to install or refresh 1573 permissions on the server. This section describes one way: the 1574 CreatePermission request. 1576 A CreatePermission request may be used in conjunction with either the 1577 Send mechanism in Section 10 or the Channel mechanism in Section 11. 1579 9.1. Forming a CreatePermission request 1581 The client who wishes to install or refresh one or more permissions 1582 can send a CreatePermission request to the server. 1584 When forming a CreatePermission request, the client MUST include at 1585 least one XOR-PEER-ADDRESS attribute, and MAY include more than one 1586 such attribute. The IP address portion of each XOR-PEER-ADDRESS 1587 attribute contains the IP address for which a permission should be 1588 installed or refreshed. The port portion of each XOR-PEER-ADDRESS 1589 attribute will be ignored and can be any arbitrary value. The 1590 various XOR-PEER-ADDRESS attributes can appear in any order. 1592 9.2. Receiving a CreatePermission request 1594 When the server receives the CreatePermission request, it processes 1595 as per Section 4 plus the specific rules mentioned here. 1597 The message is checked for validity. The CreatePermission request 1598 MUST contain at least XOR-PEER-ADDRESS attribute and MAY contain 1599 multiple such attributes. If no such attribute exists, or if any of 1600 these attributes are invalid, then a 400 (Bad Request) error is 1601 returned. If the request is valid, but the server is unable to 1602 satisfy the request due to some capacity limit or similar, then a 508 1603 (Insufficient Capacity) error is returned. 1605 The server MAY impose restrictions on the IP address and port values 1606 allowed in the XOR-PEER-ADDRESS attribute -- if a value is not 1607 allowed, the server rejects the request with a 403 (Forbidden) error. 1609 If the message is valid and the server is capable of carrying out the 1610 request, then the server installs or refreshes a permission for the 1611 IP address contained in each XOR-PEER-ADDRESS attribute as described 1612 in Section 8. The port portion of each attribute is ignored and may 1613 be any arbitrary value. 1615 The server then responds with a CreatePermission success response. 1616 There are no mandatory attributes in the success response. 1618 NOTE: A server need not do anything special to implement 1619 idempotency of CreatePermission requests over UDP using the 1620 "stateless stack approach". Retransmitted CreatePermission 1621 requests will simply refresh the permissions. 1623 9.3. Receiving a CreatePermission response 1625 If the client receives a valid CreatePermission success response, 1626 then the client updates its data structures to indicate that the 1627 permissions have been installed or refreshed. 1629 10. Send and Data Methods 1631 TURN supports two mechanisms for sending and receiving data from 1632 peers. This section describes the use of the Send and Data 1633 mechanism, while Section 11 describes the use of the Channel 1634 mechanism. 1636 10.1. Forming a Send Indication 1638 The client can use a Send indication to pass data to the server for 1639 relaying to a peer. A client may use a Send indication even if a 1640 channel is bound to that peer. However the client MUST ensure that 1641 there is a permission installed for the IP address of the peer to 1642 which the Send indication is being sent; this prevents a third party 1643 from using a TURN server to send data to arbitrary destinations. 1645 When forming a Send indication, the client MUST include a XOR-PEER- 1646 ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS 1647 attribute contains the transport address of the peer to which the 1648 data is to be sent, and the DATA attribute contains the actual 1649 application data to be sent to the peer. 1651 The client MAY include a DONT-FRAGMENT attribute in the Send 1652 indication if it wishes the server to set the DF bit on the UDP 1653 datagram sent to the peer. 1655 10.2. Receiving a Send Indication 1657 When the server receives a Send indication, it processes as per 1658 Section 4 plus the specific rules mentioned here. 1660 The message is first checked for validity. The Send indication MUST 1661 contain both a XOR-PEER-ADDRESS attribute and a DATA attribute. If 1662 one of these attributes is missing or invalid, then the message is 1663 discarded. Note that the DATA attribute is allowed to contain zero 1664 bytes of data. 1666 The Send indication may also contain the DONT-FRAGMENT attribute. If 1667 the server is unable to set the DF bit on outgoing UDP datagrams when 1668 this attribute is present, then the server acts as if the DONT- 1669 FRAGMENT attribute is an unknown comprehension-required attribute 1670 (and thus the Send indication is discarded). 1672 The server also checks that there is a permission installed for the 1673 IP address contained in the XOR-PEER-ADDRESS attribute. If no such 1674 permission exists, the message is discarded. Note that a Send 1675 indication never causes the server to refresh the permission. 1677 The server MAY impose restrictions on the IP address and port values 1678 allowed in the XOR-PEER-ADDRESS attribute -- if a value is not 1679 allowed, the server silently discards the Send indication. 1681 If everything is OK, then the server forms a UDP datagram as follows: 1683 o the source transport address is the relayed transport address of 1684 the allocation, where the allocation is determined by the 5-tuple 1685 on which the Send indication arrived; 1687 o the destination transport address is taken from the XOR-PEER- 1688 ADDRESS attribute; 1690 o the data following the UDP header is the contents of the value 1691 field of the DATA attribute. 1693 The handling of the DONT-FRAGMENT attribute (if present), is 1694 described in Section 12. 1696 The resulting UDP datagram is then sent to the peer. 1698 10.3. Receiving a UDP Datagram 1700 When the server receives a UDP datagram at a currently allocated 1701 relayed transport address, the server looks up the allocation 1702 associated with the relayed transport address. It then checks to see 1703 if relaying is permitted, as described in Section 8. 1705 If relaying is permitted, then the server checks if there is a 1706 channel bound to the peer that sent the UDP datagram (see 1707 Section 11). If a channel is bound, then processing proceeds as 1708 described in Section 11.7. 1710 If relaying is permitted but no channel is bound to the peer, then 1711 the server forms and sends a Data indication. The Data indication 1712 MUST contain both a XOR-PEER-ADDRESS and a DATA attribute. The DATA 1713 attribute is set to the value of the 'data octets' field from the 1714 datagram, and the XOR-PEER-ADDRESS attribute is set to the source 1715 transport address of the received UDP datagram. The Data indication 1716 is then sent on the 5-tuple associated with the allocation. 1718 10.4. Receiving a Data Indication 1720 When the client receives a Data indication, it checks that the Data 1721 indication contains both a XOR-PEER-ADDRESS and a DATA attribute, and 1722 discards the indication if it does not. The client SHOULD also check 1723 that the XOR-PEER-ADDRESS attribute value contains an IP address with 1724 which the client believes there is an active permission, and discard 1725 the Data indication otherwise. Note that the DATA attribute is 1726 allowed to contain zero bytes of data. 1728 NOTE: The latter check protects the client against an attacker who 1729 somehow manages to trick the server into installing permissions 1730 not desired by the client. 1732 If the Data indication passes the above checks, the client delivers 1733 the data octets inside the DATA attribute to the application, along 1734 with an indication that they were received from the peer whose 1735 transport address is given by the XOR-PEER-ADDRESS attribute. 1737 11. Channels 1739 Channels provide a way for the client and server to send application 1740 data using ChannelData messages, which have less overhead than Send 1741 and Data indications. 1743 The ChannelData message (see Section 11.4) starts with a two-byte 1744 field that carries the channel number. The values of this field are 1745 allocated as follows: 1747 0x0000 through 0x3FFF: These values can never be used for channel 1748 numbers. 1750 0x4000 through 0x7FFF: These values are the allowed channel 1751 numbers (16,383 possible values) 1753 0x8000 through 0xFFFF: These values are reserved for future use. 1755 Because of this division, ChannelData messages can be distinguished 1756 from STUN-formatted messages (e.g., Allocate request, Send 1757 indication, etc) by examining the first two bits of the message: 1759 0b00: STUN-formatted message (since the first two bits of a STUN- 1760 formatted message are always zero) 1762 0b01: ChannelData message (since the channel number is the first 1763 field in the ChannelData message and channel numbers fall in the 1764 range 0x4000 - 0x7FFF) 1765 0b10: Reserved 1767 0b11: Reserved 1769 The reserved values may be used in the future to extend the range of 1770 channel numbers. Thus an implementation MUST NOT assume that a TURN 1771 message always starts with a 0 bit. 1773 Channel bindings are always initiated by the client. The client can 1774 bind a channel to a peer at any time during the lifetime of the 1775 allocation. The client may bind a channel to a peer before 1776 exchanging data with it, or after exchanging data with it (using Send 1777 and Data indications) for some time, or may choose never to bind a 1778 channel to it. The client can also bind channels to some peers while 1779 not binding channels to other peers. 1781 Channel bindings are specific to an allocation, so that the use of a 1782 channel number or peer transport address in a channel binding in one 1783 allocation has no impact on their use in a different allocation. If 1784 an allocation expires, all its channel bindings expire with it. 1786 A channel binding consists of: 1788 o A channel number; 1790 o A transport address (of the peer); 1792 o A time-to-expiry timer. 1794 Within the context of an allocation, a channel binding is uniquely 1795 identified either by the channel number or by the peer's transport 1796 address. Thus the same channel cannot be bound to two different 1797 transport addresses, nor can the same transport address be bound to 1798 two different channels. 1800 A channel binding lasts for 10 minutes unless refreshed. Refreshing 1801 the binding (by the server receiving a ChannelBind request rebinding 1802 the channel to the same peer) resets the time-to-expiry timer back to 1803 10 minutes. 1805 When the channel binding expires, the channel becomes unbound. Once 1806 unbound, the channel number can be bound to a different transport 1807 address, and the transport address can be bound to a different 1808 channel number. To prevent race conditions, the client MUST wait 5 1809 minutes after the channel binding expires before attempting to bind 1810 the channel number to a different transport address or the transport 1811 address to a different channel number. 1813 When binding a channel to a peer, the client SHOULD be prepared to 1814 receive ChannelData messages on the channel from the server as soon 1815 as it has sent the ChannelBind request. Over UDP, it is possible for 1816 the client to receive ChannelData messages from the server before it 1817 receives a ChannelBind success response. 1819 In the other direction, the client MAY elect to send ChannelData 1820 messages before receiving the ChannelBind success response. Doing 1821 so, however, runs the risk of having the ChannelData messages dropped 1822 by the server if the ChannelBind request does not succeed for some 1823 reason (e.g., packet lost if the request is sent over UDP, or the 1824 server being unable to fulfill the request). A client that wishes to 1825 be safe should either queue the data, or use Send indications until 1826 the channel binding is confirmed. 1828 11.1. Sending a ChannelBind Request 1830 A channel binding is created or refreshed using a ChannelBind 1831 transaction. A ChannelBind transaction also creates or refreshes a 1832 permission towards the peer (see Section 8). 1834 To initiate the ChannelBind transaction, the client forms a 1835 ChannelBind request. The channel to be bound is specified in a 1836 CHANNEL-NUMBER attribute, and the peer's transport address is 1837 specified in a XOR-PEER-ADDRESS attribute. Section 11.2 describes 1838 the restrictions on these attributes. 1840 Rebinding a channel to the same transport address that it is already 1841 bound to provides a way to refresh a channel binding and the 1842 corresponding permission without sending data to the peer. Note 1843 however, that permissions need to be refreshed more frequently than 1844 channels. 1846 11.2. Receiving a ChannelBind Request 1848 When the server receives a ChannelBind request, it processes as per 1849 Section 4 plus the specific rules mentioned here. 1851 The server checks the following: 1853 o The request contains both a CHANNEL-NUMBER and a XOR-PEER-ADDRESS 1854 attribute; 1856 o The channel number is in the range 0x4000 through 0x7FFE 1857 (inclusive); 1859 o The channel number is not currently bound to a different transport 1860 address (same transport address is OK); 1862 o The transport address is not currently bound to a different 1863 channel number. 1865 If any of these tests fail, the server replies with a 400 (Bad 1866 Request) error. 1868 The server MAY impose restrictions on the IP address and port values 1869 allowed in the XOR-PEER-ADDRESS attribute -- if a value is not 1870 allowed, the server rejects the request with a 403 (Forbidden) error. 1872 If the request is valid, but the server is unable to fulfill the 1873 request due to some capacity limit or similar, the server replies 1874 with a 508 (Insufficient Capacity) error. 1876 Otherwise, the server replies with a ChannelBind success response. 1877 There are no required attributes in a successful ChannelBind 1878 response. 1880 If the server can satisfy the request, then the server creates or 1881 refreshes the channel binding using the channel number in the 1882 CHANNEL-NUMBER attribute and the transport address in the XOR-PEER- 1883 ADDRESS attribute. The server also installs or refreshes a 1884 permission for the IP address in the XOR-PEER-ADDRESS attribute as 1885 described in Section 8. 1887 NOTE: A server need not do anything special to implement 1888 idempotency of ChannelBind requests over UDP using the "stateless 1889 stack approach". Retransmitted ChannelBind requests will simply 1890 refresh the channel binding and the corresponding permission. 1891 Furthermore, the client must wait 5 minutes before binding a 1892 previously bound channel number or peer address to a different 1893 channel, eliminating the possibility that the transaction would 1894 initially fail but succeed on a retransmission. 1896 11.3. Receiving a ChannelBind Response 1898 When the client receives a ChannelBind success response, it updates 1899 its data structures to record that the channel binding is now active. 1900 It also updates its data structures to record that the corresponding 1901 permission has been installed or refreshed. 1903 If the client receives a ChannelBind failure response that indicates 1904 that the channel information is out-of-sync between the client and 1905 the server (e.g., an unexpected 400 "Bad Request" response), then it 1906 is RECOMMENDED that the client immediately delete the allocation and 1907 start afresh with a new allocation. 1909 11.4. The ChannelData Message 1911 The ChannelData message is used to carry application data between the 1912 client and the server. It has the following format: 1914 0 1 2 3 1915 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 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | Channel Number | Length | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | | 1920 / Application Data / 1921 / / 1922 | | 1923 | +-------------------------------+ 1924 | | 1925 +-------------------------------+ 1927 The Channel Number field specifies the number of the channel on which 1928 the data is traveling, and thus the address of the peer that is 1929 sending or is to receive the data. 1931 The Length field specifies the length in bytes of the application 1932 data field (i.e., it does not include the size of the ChannelData 1933 header). Note that 0 is a valid length. 1935 The Application Data field carries the data the client is trying to 1936 send to the peer, or that the peer is sending to the client. 1938 11.5. Sending a ChannelData Message 1940 Once a client has bound a channel to a peer, then when the client has 1941 data to send to that peer it may use either a ChannelData message or 1942 a Send indication; that is, the client is not obligated to use the 1943 channel when it exists and may freely intermix the two message types 1944 when sending data to the peer. The server, on the other hand, MUST 1945 use the ChannelData message if a channel has been bound to the peer. 1947 The fields of the ChannelData message are filled in as described in 1948 Section 11.4. 1950 Over stream transports, the ChannelData message MUST be padded to a 1951 multiple of four bytes in order to ensure the alignment of subsequent 1952 messages. The padding is not reflected in the length field of the 1953 ChannelData message, so the actual size of a ChannelData message 1954 (including padding) is (4 + Length) rounded up to the nearest 1955 multiple of 4. Over UDP, the padding is not required but MAY be 1956 included. 1958 The ChannelData message is then sent on the 5-tuple associated with 1959 the allocation. 1961 11.6. Receiving a ChannelData Message 1963 The receiver of the ChannelData message uses the first two bits to 1964 distinguish it from STUN-formatted messages, as described above. If 1965 the message uses a value in the reserved range (0x8000 through 1966 0xFFFF), then the message is silently discarded. 1968 If the ChannelData message is received in a UDP datagram, and if the 1969 UDP datagram is too short to contain the claimed length of the 1970 ChannelData message (i.e., the UDP header length field value is less 1971 than the ChannelData header length field value + 4 + 8), then the 1972 message is silently discarded. 1974 If the ChannelData message is received over TCP or over TLS over TCP, 1975 then the actual length of the ChannelData message is as described in 1976 Section 11.5. 1978 If the ChannelData message is received on a channel which is not 1979 bound to any peer, then the message is silently discarded. 1981 On the client, it is RECOMMENDED that the client discard the 1982 ChannelData message if the client believes there is no active 1983 permission towards the peer. On the server, the receipt of a 1984 ChannelData message MUST NOT refresh either the channel binding or 1985 the permission towards the peer. 1987 On the server, if no errors are detected, the server relays the 1988 application data to the peer by forming a UDP datagram as follows: 1990 o the source transport address is the relayed transport address of 1991 the allocation, where the allocation is determined by the 5-tuple 1992 on which the ChannelData message arrived; 1994 o the destination transport address is the transport address to 1995 which the channel is bound; 1997 o the data following the UDP header is the contents of the data 1998 field of the ChannelData message. 2000 The resulting UDP datagram is then sent to the peer. Note that if 2001 the Length field in the ChannelData message is 0, then there will be 2002 no data in the UDP datagram, but the UDP datagram is still formed and 2003 sent. 2005 11.7. Relaying Data from the Peer 2007 When the server receives a UDP datagram on the relayed transport 2008 address associated with an allocation, the server processes it as 2009 described in Section 10.3. If that section indicates that a 2010 ChannelData message should be sent (because there is a channel bound 2011 to the peer that sent to UDP datagram), then the server forms and 2012 sends a ChannelData message as described in Section 11.5. 2014 12. IP Header Fields 2016 This section describes how the server sets various fields in the IP 2017 header when relaying between the client and the peer or vica-versa. 2018 The descriptions in this section apply: (a) when the server sends a 2019 UDP datagram to the peer, or (b) when the server sends a Data 2020 indication or ChannelData message to the client over UDP transport. 2021 The descriptions in this section do not apply to TURN messages sent 2022 over TCP or TLS transport from the server to the client. 2024 The descriptions below have two parts: a preferred behavior and an 2025 alternate behavior. The server SHOULD implement the preferred 2026 behavior, but if that is not possible for a particular field, then it 2027 SHOULD implement the alternative behavior. 2029 Time to Live (TTL) field 2031 Preferred Behavior: If the incoming value is 0, then the drop the 2032 incoming packet. Otherwise set the outgoing Time to Live/Hop 2033 Count to one less than the incoming value. 2035 Alternate Behavior: Set the outgoing value to the default for 2036 outgoing packets. 2038 Diff-Serv Code Point (DSCP) field [RFC2474] 2040 Preferred Behavior: Set the outgoing value to the incoming value, 2041 unless the server includes a differentiated services classifier 2042 and marker [RFC2474]. 2044 Alternate Behavior: Set the outgoing value to a fixed value, which 2045 by default is Best Effort unless configured otherwise. 2047 In both cases, if the server is immediately adjacent to a 2048 differentiated services classifier and marker, then DSCP MAY be 2049 set to any arbitrary value in the direction towards the 2050 classifier. 2052 Explicit Congestion Notification (ECN) field [RFC3168] 2054 Preferred Behavior: Set the outgoing value to the incoming value, 2055 UNLESS the server is doing Active Queue Management, the incoming 2056 ECN field is ECT(1) (=0b01) or ECT(0) (=0b10), and the server 2057 wishes to indicate that congestion has been experienced, in which 2058 case set the outgoing value to CE (=0b11). 2060 Alternate Behavior: Set the outgoing value to Not-ECT (=0b00). 2062 IPv4 Fragmentation fields 2064 Preferred Behavior: 2066 When the server sends a packet to a peer in response to a Send 2067 indication containing the DONT-FRAGMENT attribute, then set the 2068 DF bit in the outgoing IP header to 1. In all other cases when 2069 sending an outgoing packet containing application data (e.g., 2070 Data indication, ChannelData message, or DONT-FRAGMENT 2071 attribute not included in the Send indication), copy the DF bit 2072 from the DF bit of the incoming packet that contained the 2073 application data. 2075 Set the other fragmentation fields (Identification, MF, 2076 Fragment Offset) as appropriate for a packet originating from 2077 the server. 2079 Alternate Behavior: As described in the Preferred Behavior, except 2080 always assume the incoming DF bit is 0. 2082 In both the Preferred and Alternate Behaviors, the resulting 2083 packet may be too large for the outgoing link. If this is the 2084 case, then the normal fragmentation rules apply [RFC1122]. 2086 IPv4 Options 2088 Preferred Behavior: The outgoing packet is sent without any IPv4 2089 options. 2091 Alternate Behavior: Same as preferred. 2093 13. New STUN Methods 2095 This section lists the codepoints for the new STUN methods defined in 2096 this specification. See elsewhere in this document for the semantics 2097 of these new methods. 2099 0x003 : Allocate (only request/response semantics defined) 2100 0x004 : Refresh (only request/response semantics defined) 2101 0x006 : Send (only indication semantics defined) 2102 0x007 : Data (only indication semantics defined) 2103 0x008 : CreatePermission (only request/response semantics defined 2104 0x009 : ChannelBind (only request/response semantics defined) 2106 14. New STUN Attributes 2108 This STUN extension defines the following new attributes: 2110 0x000C: CHANNEL-NUMBER 2111 0x000D: LIFETIME 2112 0x0010: Reserved (was BANDWIDTH) 2113 0x0012: XOR-PEER-ADDRESS 2114 0x0013: DATA 2115 0x0016: XOR-RELAYED-ADDRESS 2116 0x0018: EVEN-PORT 2117 0x0019: REQUESTED-TRANSPORT 2118 0x001A: DONT-FRAGMENT 2119 0x0021: Reserved (was TIMER-VAL) 2120 0x0022: RESERVATION-TOKEN 2122 14.1. CHANNEL-NUMBER 2124 The CHANNEL-NUMBER attribute contains the number of the channel. It 2125 is a 16-bit unsigned integer, followed by a two-octet RFFU (Reserved 2126 For Future Use) field which MUST be set to 0 on transmission and MUST 2127 be ignored on reception. 2129 0 1 2 3 2130 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 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | Channel Number | RFFU = 0 | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 14.2. LIFETIME 2137 The LIFETIME attribute represents the duration for which the server 2138 will maintain an allocation in the absence of a refresh. It is a 32- 2139 bit unsigned integral value representing the number of seconds 2140 remaining until expiration. 2142 14.3. XOR-PEER-ADDRESS 2144 The XOR-PEER-ADDRESS specifies the address and port of the peer as 2145 seen from the TURN server. (In other words, the peer's server- 2146 reflexive transport address if the peer is behind a NAT). It is 2147 encoded in the same way as XOR-MAPPED-ADDRESS [RFC5389]. 2149 14.4. DATA 2151 The DATA attribute is present in all Send and Data indications. The 2152 contents of DATA attribute is the application data (that is, the data 2153 that would immediately follow the UDP header if the data was been 2154 sent directly between the client and the peer). 2156 14.5. XOR-RELAYED-ADDRESS 2158 The XOR-RELAYED-ADDRESS is present in Allocate responses. It 2159 specifies the address and port that the server allocated to the 2160 client. It is encoded in the same way as XOR-MAPPED-ADDRESS 2161 [RFC5389]. 2163 14.6. EVEN-PORT 2165 This attribute allows the client to request that the port in the 2166 relayed-transport-address be even, and (optionally) that the server 2167 reserve the next-higher port number. The attribute is 8 bits long. 2168 Its format is: 2170 0 2171 0 1 2 3 4 5 6 7 2172 +-+-+-+-+-+-+-+-+ 2173 |R| RFFU | 2174 +-+-+-+-+-+-+-+-+ 2176 The attribute contains a single 1-bit flag: 2178 R: If 1, the server is requested to reserve the next higher port 2179 number (on the same IP address) for a subsequent allocation. If 2180 0, no such reservation is requested. 2182 The other 7 bits of the attribute must be set to zero on transmission 2183 and ignored on reception. 2185 14.7. REQUESTED-TRANSPORT 2187 This attribute is used by the client to request a specific transport 2188 protocol for the allocated transport address. It has the following 2189 format: 2191 0 1 2 3 2192 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 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | Protocol | RFFU | 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 The Protocol field specifies the desired protocol. The codepoints 2198 used in this field are taken from those allowed in the Protocol field 2199 in the IPv4 header and the NextHeader field in the IPv6 header 2200 [Protocol-Numbers]. This specification only allows the use of 2201 codepoint 17 (User Datagram Protocol). 2203 The RFFU field MUST be set to zero on transmission and MUST be 2204 ignored on reception. It is reserved for future uses. 2206 14.8. DONT-FRAGMENT 2208 This attribute is used by the client to request that the server set 2209 the DF (Don't Fragment) bit in the IP header when relaying the 2210 application data onward to the peer. This attribute has no value 2211 part and thus the attribute length field is 0. 2213 14.9. RESERVATION-TOKEN 2215 The RESERVATION-TOKEN attribute contains a token that uniquely 2216 identifies a relayed transport address being held in reserve by the 2217 server. The server includes this attribute in a success response to 2218 tell the client about the token, and the client includes this 2219 attribute in a subsequent Allocate request to request the server use 2220 that relayed transport address for the allocation. 2222 The attribute value is a 64-bit-long field containing the token 2223 value. 2225 15. New STUN Error Response Codes 2227 This document defines the following new error response codes: 2229 403 (Forbidden): The request was valid, but cannot be performed due 2230 to administrative or similar restrictions. 2232 437 (Allocation Mismatch): A request was received by the server that 2233 requires an allocation to be in place, but there is none, or a 2234 request was received which requires no allocation, but there is 2235 one. 2237 441 (Wrong Credentials): The credentials in the (non-Allocate) 2238 request, though otherwise acceptable to the server, do not match 2239 those used to create the allocation. 2241 442 (Unsupported Transport Protocol): The Allocate request asked the 2242 server to use a transport protocol between the server and the peer 2243 that the server does not support. NOTE: This does NOT refer to 2244 the transport protocol used in the 5-tuple. 2246 486 (Allocation Quota Reached): No more allocations using this 2247 username can be created at the present time. 2249 508 (Insufficient Capacity): The server is unable to carry out the 2250 request due to some capacity limit being reached. In an Allocate 2251 response, this could be due to the server having no more relayed 2252 transport addresses available right now, or having none with the 2253 requested properties, or the one that corresponds to the specified 2254 reservation token is not available. 2256 16. Detailed Example 2258 This section gives a example of the use of TURN, showing in detail 2259 the contents of the messages exchanged. The example uses the network 2260 diagram shown in the Overview (Figure 1). 2262 For each message, the attributes included in the message and their 2263 values are shown. For convenience, values are shown in a human- 2264 readable format rather than showing the actual octets; for example 2265 "XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED- 2266 ADDRESS attribute is included with an address of 192.0.2.15 and a 2267 port of 9000, here the address and port are shown before the xor-ing 2268 is done. For attributes with string-like values (e.g. 2269 SOFTWARE="Example client, version 1.03" and 2270 NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"), the value of the attribute 2271 is shown in quotes for readability, but these quotes do not appear in 2272 the actual value. 2274 TURN TURN Peer Peer 2275 client server A B 2276 | | | | 2277 |--- Allocate request -------------->| | | 2278 | Transaction-Id=0xA56250D3F17ABE679422DE85 | | 2279 | SOFTWARE="Example client, version 1.03" | | 2280 | LIFETIME=3600 (1 hour) | | | 2281 | REQUESTED-TRANSPORT=17 (UDP) | | | 2282 | DONT-FRAGMENT | | | 2283 | | | | 2284 |<-- Allocate error response --------| | | 2285 | Transaction-Id=0xA56250D3F17ABE679422DE85 | | 2286 | SOFTWARE="Example server, version 1.17" | | 2287 | ERROR-CODE=401 (Unauthorized) | | | 2288 | REALM="example.com" | | | 2289 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2290 | | | | 2291 |--- Allocate request -------------->| | | 2292 | Transaction-Id=0xC271E932AD7446A32C234492 | | 2293 | SOFTWARE="Example client 1.03" | | | 2294 | LIFETIME=3600 (1 hour) | | | 2295 | REQUESTED-TRANSPORT=17 (UDP) | | | 2296 | DONT-FRAGMENT | | | 2297 | USERNAME="George" | | | 2298 | REALM="example.com" | | | 2299 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2300 | MESSAGE-INTEGRITY=... | | | 2301 | | | | 2302 |<-- Allocate success response ------| | | 2303 | Transaction-Id=0xC271E932AD7446A32C234492 | | 2304 | SOFTWARE="Example server, version 1.17" | | 2305 | LIFETIME=1200 (20 minutes) | | | 2306 | XOR-RELAYED-ADDRESS=192.0.2.15:50000 | | 2307 | XOR-MAPPED-ADDRESS=192.0.2.1:7000 | | 2308 | MESSAGE-INTEGRITY=... | | | 2310 The client begins by selecting a host transport address to use for 2311 the TURN session; in this example the client has selected 10.1.1.2: 2312 49721 as shown in Figure 1. The client then sends an Allocate 2313 request to the server at the server transport address. The client 2314 randomly selects a 96-bit transaction id of 2315 0xA56250D3F17ABE679422DE85 for this transaction; this is encoded in 2316 the transaction id field in the fixed header. The client includes a 2317 SOFTWARE attribute that gives information about the client's 2318 software; here the value is "Example client, version 1.03" to 2319 indicate that this is version 1.03 of something called the Example 2320 client. The client includes the LIFETIME attribute because it wishes 2321 the allocation to have a longer lifetime than the default of 10 2322 minutes; the value of this attribute is 3600 seconds, which 2323 corresponds to 1 hour. The client must always include a REQUESTED- 2324 TRANSPORT attribute in an Allocate request and the only value allowed 2325 by this specification is 17, which indicates UDP transport between 2326 the server and the peers. The client also includes the DONT-FRAGMENT 2327 attribute because it wishes to use the DONT-FRAGMENT attribute later 2328 in Send indications; this attribute consists of only an attribute 2329 header, there is no value part. We assume the client has not 2330 recently interacted with the server, thus the client does not include 2331 USERNAME, REALM, NONCE, or MESSAGE-INTEGRITY attribute. Finally, 2332 note that the order of attributes in a message is arbitrary (except 2333 for the MESSAGE-INTEGRITY and FINGERPRINT attributes) and the client 2334 could have used a different order. 2336 The server follows the recommended practice in this specification of 2337 requiring all requests to be authenticated. Thus when the server 2338 receives the initial Allocate request, it rejects the request because 2339 the request does not contain the authentication attributes. 2340 Following the procedures of the Long-Term Credential Mechanism of 2341 STUN [RFC5389], the server includes an ERROR-CODE attribute with a 2342 value of 401 (Unauthorized), a REALM attribute that specifies the 2343 authentication realm used by the server (in this case, the server's 2344 domain "example.com"), and a nonce value in a NONCE attribute. The 2345 server also includes a SOFTWARE attribute that gives information 2346 about the server's software. 2348 The client, upon receipt of the 401 error, re-attempts the Allocate 2349 request, this time including the authentication attributes. The 2350 client selects a new transaction id, and then populates the new 2351 Allocate request with the same attributes as before. The client 2352 includes a USERNAME attribute and uses the realm value received from 2353 the server to help it determine which value to use; here the client 2354 is configured to use the username "George" for the realm 2355 "example.com". The client also includes the REALM and NONCE 2356 attributes, which are just copied from the 401 error response. 2357 Finally, the client includes a MESSAGE-INTEGRITY attribute as the 2358 last attribute in the message, whose value is an HMAC-SHA1 hash over 2359 the contents of the message (shown as just "..." above); this HMAC- 2360 SHA1 computation also covers a password value, thus an attacker 2361 cannot compute the message integrity value without somehow knowing 2362 the secret password. 2364 The server, upon receipt of the authenticated Allocate request, 2365 checks that everything is OK, then creates an allocation. The server 2366 replies with an Allocate success response. The server includes a 2367 LIFETIME attribute giving the lifetime of the allocation; here, the 2368 server as reduced the client's requested 1 hour lifetime to just 20 2369 minutes, because this particular server doesn't allow lifetimes 2370 longer than 20 minutes. The server includes an XOR-RELAYED-ADDRESS 2371 attribute whose value is the relayed transport address of the 2372 allocation. The server includes an XOR-MAPPED-ADDRESS attribute 2373 whose value is the server-reflexive address of the client; this value 2374 is not used otherwise in TURN but is returned as a convenience to the 2375 client. The server includes a MESSAGE-INTEGRITY attribute to 2376 authenticate the response and to insure its integrity; note that the 2377 response does not contain the USERNAME, REALM, and NONCE attributes. 2378 The server also includes a SOFTWARE attribute. 2380 TURN TURN Peer Peer 2381 client server A B 2382 |--- CreatePermission request ------>| | | 2383 | Transaction-Id=0xE5913A8F460956CA277D3319 | | 2384 | XOR-PEER-ADDRESS=192.0.2.150:0 | | | 2385 | USERNAME="George" | | | 2386 | REALM="example.com" | | | 2387 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2388 | MESSAGE-INTEGRITY=... | | | 2389 | | | | 2390 |<-- CreatePermission success resp.--| | | 2391 | Transaction-Id=0xE5913A8F460956CA277D3319 | | 2392 | MESSAGE-INTEGRITY=... | | | 2394 The client then creates a permission towards peer A in preparation 2395 for sending it some application data. This is done through a 2396 CreatePermission request. The XOR-PEER-ADDRESS attribute contains 2397 the IP address for which a permission is established (the IP address 2398 of peer A); note that the port number in the attribute is ignored 2399 when used in a CreatePermission request, and here it has been set to 2400 0; also note how the client uses Peer A's server-reflexive IP address 2401 and not its (private) host address. The client uses the same 2402 username, realm, and nonce values as in the previous request on the 2403 allocation. Though it is allowed to do so, the client has chosen not 2404 to include a SOFTWARE attribute in this request. 2406 The server receives the CreatePermission request, creates the 2407 corresponding permission, and then replies with a CreatePermission 2408 success response. Like the client, the server chooses not to include 2409 the SOFTWARE attribute in its reply. Again, note how success 2410 responses contain a MESSAGE-INTEGRITY attribute (assuming the server 2411 uses the Long-Term Credential Mechanism), but no USERNAME, REALM, and 2412 NONCE attributes. 2414 TURN TURN Peer Peer 2415 client server A B 2416 |--- Send indication --------------->| | | 2417 | Transaction-Id=0x1278E9ACA2711637EF7D3328 | | 2418 | XOR-PEER-ADDRSSS=192.0.2.150:32102 | | 2419 | DONT-FRAGMENT | | | 2420 | DATA=... | | | 2421 | |-- UDP dgm ->| | 2422 | | data=... | | 2423 | | | | 2424 | |<- UDP dgm --| | 2425 | | data=... | | 2426 |<-- Data indication ----------------| | | 2427 | Transaction-Id=0x8231AE8F9242DA9FF287FEFF | | 2428 | XOR-PEER-ADDRSSS=192.0.2.150:32102 | | 2429 | DATA=... | | | 2431 The client now sends application data to Peer A using a Send 2432 indication. Peer A's server-reflexive transport address is specified 2433 in the XOR-PEER-ADDRESS attribute, and the application data (shown 2434 here as just "...") is specified in the DATA attribute. The client 2435 is doing a form of path MTU discovery at the application layer and 2436 thus specifies (by including the DONT-FRAGMENT attribute) that the 2437 server should set the DF bit in the UDP datagram send to the peer. 2438 Indications cannot be authenticated using the Long-Term Credential 2439 Mechanism of STUN, so no MESSAGE-INTEGRITY attribute is included in 2440 the message. An application wishing to ensure that its data is not 2441 altered or forged must integrity-protect its data at the application 2442 level. 2444 Upon receipt of the Send indication, the server extracts the 2445 application data and sends it in a UDP datagram to Peer A, with the 2446 relayed-transport-address as the source transport address of the 2447 datagram, and with the DF bit set as requested. Note that, had the 2448 client not previously established a permission for Peer A's server- 2449 reflexive IP address, then the server would have silently discarded 2450 the Send indication instead. 2452 Peer A then replies with its own UDP datagram containing application 2453 data. The datagram is sent to the relayed-transport-address on the 2454 server. When this arrives, the server creates a Data indication 2455 containing the source of the UDP datagram in the XOR-PEER-ADDRESS 2456 attribute, and the data from the UDP datagram in the DATA attribute. 2457 The resulting Data indication is then sent to the client. 2459 TURN TURN Peer Peer 2460 client server A B 2461 |--- ChannelBind request ----------->| | | 2462 | Transaction-Id=0x6490D3BC175AFF3D84513212 | | 2463 | CHANNEL-NUMBER=0x4000 | | | 2464 | XOR-PEER-ADDRESS=192.0.2.210:49191 | | 2465 | USERNAME="George" | | | 2466 | REALM="example.com" | | | 2467 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2468 | MESSAGE-INTEGRITY=... | | | 2469 | | | | 2470 |<-- ChannelBind success response ---| | | 2471 | Transaction-Id=0x6490D3BC175AFF3D84513212 | | 2472 | MESSAGE-INTEGRITY=... | | | 2474 The client now binds a channel to Peer B, specifying a free channel 2475 number (0x4000) in the CHANNEL-NUMBER attribute, and Peer B's 2476 transport address in the XOR-PEER-ADDRESS attribute. As before, the 2477 client re-uses the username, realm, and nonce from its last request 2478 in the message. 2480 Upon receipt of the request, the server binds the channel number to 2481 the peer, installs a permission for Peer B's IP address, and then 2482 replies with ChannelBind success response. 2484 TURN TURN Peer Peer 2485 client server A B 2486 |--- ChannelData ------------------->| | | 2487 | Channel-number=0x4000 |--- UDP datagram --------->| 2488 | Data=... | Data=... | 2489 | | | | 2490 | |<-- UDP datagram ----------| 2491 | | Data=... | | 2492 |<-- ChannelData --------------------| | | 2493 | Channel-number=0x4000 | | | 2494 | Data=... | | | 2496 The client now sends a ChannelData message to the server with data 2497 destined for Peer B. The ChannelData message is not a STUN message, 2498 and thus has no transaction id. Instead, its fixed header has only 2499 two fields: channel number and data; here the channel number field is 2500 0x4000 (the channel the client just bound to Peer B). When the 2501 server receives the ChannelData message, it checks that the channel 2502 is currently bound (which it is) and then sends the data onward to 2503 Peer B in a UDP datagram, using the relayed-transport-address as the 2504 source transport address and 192.0.2.210:49191 (the value of the XOR- 2505 PEER-ADDRESS attribute in the ChannelBind request) as the destination 2506 transport address. 2508 Later, Peer B sends a UDP datagram back to the relayed-transport- 2509 address. This causes the server to send a ChannelData message to the 2510 client containing the data from the UDP datagram. The server knows 2511 which client to send the ChannelData message to because of the 2512 relayed-transport-address the UDP datagram arrived at, and knows to 2513 use channel 0x4000 because this is the channel bound to 192.0.2.210: 2514 49191. Note that if there had not been any channel number bound to 2515 that address, the server would have used a Data indication instead. 2517 TURN TURN Peer Peer 2518 client server A B 2519 |--- Refresh request --------------->| | | 2520 | Transaction-Id=0x0864B3C27ADE9354B4312414 | | 2521 | SOFTWARE="Example client 1.03" | | | 2522 | USERNAME="George" | | | 2523 | REALM="example.com" | | | 2524 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2525 | MESSAGE-INTEGRITY=... | | | 2526 | | | | 2527 |<-- Refresh error response ---------| | | 2528 | Transaction-Id=0x0864B3C27ADE9354B4312414 | | 2529 | SOFTWARE="Example server, version 1.17" | | 2530 | ERROR-CODE=438 (Stale Nonce) | | | 2531 | REALM="example.com" | | | 2532 | NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | | 2533 | | | | 2534 |--- Refresh request --------------->| | | 2535 | Transaction-Id=0x427BD3E625A85FC731DC4191 | | 2536 | SOFTWARE="Example client 1.03" | | | 2537 | USERNAME="George" | | | 2538 | REALM="example.com" | | | 2539 | NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | | 2540 | MESSAGE-INTEGRITY=... | | | 2541 | | | | 2542 |<-- Refresh success response -------| | | 2543 | Transaction-Id=0x427BD3E625A85FC731DC4191 | | 2544 | SOFTWARE="Example server, version 1.17" | | 2545 | LIFETIME=600 (10 minutes) | | | 2547 Sometime before the 20 minute lifetime is up, the client refreshes 2548 the allocation. This is done using a Refresh request. As before, 2549 the client includes the latest username, realm, and nonce values in 2550 the request. The client also includes the SOFTWARE attribute, 2551 following the recommended practice of always including this attribute 2552 in Allocate and Refresh messages. When the server receives the 2553 Refresh request, it notices that the nonce value has expired, and so 2554 replies with 438 (Stale Nonce) error given a new nonce value. The 2555 client then reattempts the request, this time with the new nonce 2556 value. This second attempt is accepted, and the server replies with 2557 a success response. Note that the client did not include a LIFETIME 2558 attribute in the request, so the server refreshes the allocation for 2559 the default lifetime of 10 minutes (as can be seen by the LIFETIME 2560 attribute in the success response). 2562 17. Security Considerations 2564 This section considers attacks that are possible in a TURN 2565 deployment, and discusses how they are mitigated by mechanisms in the 2566 protocol or recommended practices in the implementation. 2568 17.1. Outsider Attacks 2570 Outsider attacks are ones where the attacker has no credentials in 2571 the system, and is attempting to disrupt the service seen by the 2572 client or the server. 2574 17.1.1. Obtaining Unauthorized Allocations 2576 An attacker might wish to obtain allocations on a TURN server for any 2577 number of nefarious purposes. A TURN server provides a mechanism for 2578 sending and receiving packets while cloaking the actual IP address of 2579 the client. This makes TURN servers an attractive target for 2580 attackers who wish to use it to mask their true identity. 2582 An attacker might also wish to simply utilize the services of a TURN 2583 server without paying for them. Since TURN services require 2584 resources from the provider, it is anticipated that their usage will 2585 come with a cost. 2587 These attacks are prevented using the digest authentication mechanism 2588 which allows the TURN server to determine the identity of the 2589 requestor and whether the requestor is allowed to obtain the 2590 allocation. 2592 17.1.2. Offline Dictionary Attacks 2594 The digest authentication mechanism used by TURN is subject to 2595 offline dictionary attacks. An attacker that is capable of 2596 eavesdropping on a message exchange between a client and server can 2597 determine the password by trying a number of candidate passwords and 2598 seeing if one of them is correct. This attack works when the 2599 passwords are low entropy, such as a word from the dictionary. This 2600 attack can be mitigated by using strong passwords with large entropy. 2601 In situations where even stronger mitigation is required, TLS 2602 transport between the client and the server can be used. 2604 17.1.3. Faked Refreshes and Permissions 2606 An attacker might wish to attack an active allocation by sending it a 2607 Refresh request with an immediate expiration, in order to delete it 2608 and disrupt service to the client. This is prevented by 2609 authentication of refreshes. Similarly, an attacker wishing to send 2610 CreatePermission requests to create permissions to undesirable 2611 destinations is prevented from doing so through authentication. The 2612 motivations for such an attack are described in Section 17.2. 2614 17.1.4. Fake Data 2616 An attacker might wish to send data to the client or the peer, as if 2617 they came from the peer or client respectively. To do that, the 2618 attacker can send the client a faked Data Indication or ChannelData 2619 message, or send the TURN server a faked Send Indication or 2620 ChannelData message. 2622 Indeed, since indications and ChannelData messages are not 2623 authenticated, this attack is not prevented by TURN. However, this 2624 attack is generally present in IP-based communications and is not 2625 substantially worsened by TURN. Consider an normal, non-TURN IP 2626 session between hosts A and B. An attacker can send packets to B as 2627 if they came from A by sending packets towards A with a spoofed IP 2628 address of B. This attack requires the attacker to know the IP 2629 addresses of A and B. With TURN, an attacker wishing to send packets 2630 towards a client using a Data indication needs to know its IP address 2631 (and port), the IP address and port of the TURN server, and the IP 2632 address and port of the peer (for inclusion in the XOR-PEER-ADDRESS 2633 attribute). To send a fake ChannelData message to a client, an 2634 attacker needs to know the IP address and port of the client, the IP 2635 address and port of the TURN server, and the channel number. This 2636 particular combination is mildly more guessable than in the non-TURN 2637 case. 2639 These attacks are more properly mitigated by application layer 2640 authentication techniques. In the case of real time traffic, usage 2641 of SRTP [RFC3711] prevents these attacks. 2643 In some situations, the TURN server may be situated in the network 2644 such that it is able to send to hosts that the client cannot directly 2645 send to. This can happen, for example, if the server is located 2646 behind a firewall that allows packets from outside the firewall to be 2647 delivered to the server, but not to other hosts behind the firewall. 2648 In these situations, an attacker could send the server a Send 2649 indication with an XOR-PEER-ADDRESS attribute containing the 2650 transport address of one of the other hosts behind the firewall. If 2651 the server was to allow relaying of traffic to arbitrary peers, then 2652 this would provide a way for the attacker to attack arbitrary hosts 2653 behind the firewall. 2655 To mitigate this attack, TURN requires that the client establish a 2656 permission to a host before sending it data. Thus an attacker can 2657 only attack hosts that the client is already communicating with, 2658 unless the attacker is able to create authenticated requests. 2659 Furthermore, the server administrator may configure the server to 2660 restrict the range of IP addresses and ports that it will relay data 2661 to. To provide even greater security, the server administrator can 2662 require that the client use TLS for all communication between the 2663 client and the server. 2665 17.1.5. Impersonating a Server 2667 When a client learns a relayed address from a TURN server, it uses 2668 that relayed address in application protocols to receive traffic. 2669 Therefore, an attacker wishing to intercept or redirect that traffic 2670 might try to impersonate a TURN server and provide the client with a 2671 faked relayed address. 2673 This attack is prevented through the digest authentication mechanism, 2674 which provides message integrity for responses in addition to 2675 verifying that they came from the server. Furthermore, an attacker 2676 cannot replay old server responses as the transaction ID in the STUN 2677 header prevents this. Replay attacks are further thwarted through 2678 frequent changes to the nonce value. 2680 17.1.6. Eavesdropping Traffic 2682 TURN concerns itself primarily with authentication and message 2683 integrity. Confidentiality is only a secondary concern, as TURN 2684 control messages do not include information that is particularly 2685 sensitive. The primary protocol content of the messages is the IP 2686 address of the peer. If it is important to prevent an eavesdropper 2687 on a TURN connection from learning this, TURN can be run over TLS. 2689 Confidentiality for the application data relayed by TURN is best 2690 provided by the application protocol itself, since running TURN over 2691 TLS does not protect application data between the server and the 2692 peer. If confidentiality of application data is important, then the 2693 application should encrypt or otherwise protect its data. For 2694 example, for real time media, confidentiality can be provided by 2695 using SRTP. 2697 17.1.7. TURN loop attack 2699 An attacker might attempt to cause data packets to loop indefinitely 2700 between two TURN servers. The attack goes as follows. First, the 2701 attacker sends an Allocate request to server A, using the source 2702 address of server B. Server A will send its response to server B, and 2703 for the attack to succeed, the attacker must have the ability to 2704 either view or guess the contents of this response, so that the 2705 attacker can learn the allocated relayed-transport-address. The 2706 attacker then sends an Allocate request to server B, using the source 2707 address of server A. Again, the attacker must be able to view or 2708 guess the contents of the response, so it can send learn the 2709 allocated relayed-transport-address. Using the same spoofed source 2710 address technique, the attacker then binds a channel number on server 2711 A to the relayed-transport-address on server B, and similarly binds 2712 the same channel number on server B to the relayed-transport-address 2713 on server A. Finally, the attacker sends a ChannelData message to 2714 server A. 2716 The result is a data packet that loops from the relayed-transport- 2717 address on server A to the relayed-transport-address on server B, 2718 then from server B's transport address to server A's transport 2719 address, and then around the loop again. 2721 This attack is mitigated as follows. By requiring all requests to be 2722 authenticated and/or by randomizing the port number allocated for the 2723 relayed-transport-address, the server forces the attacker to either 2724 intercept or view responses sent to a third party (in this case, the 2725 other server) so that the attacker can authenticate the requests and 2726 learn the relayed-transport-address. Without one of these two 2727 measures, an attacker can guess the contents of the responses without 2728 needing to see them, which makes the attack much easier to perform. 2729 Furthermore, by requiring authenticated requests, the server forces 2730 the attacker to have credentials acceptable to the server, which 2731 turns this from an outsider attack into an insider attack and allows 2732 the attack to be traced back to the client initiating it. 2734 The attack can be further mitigated by imposing a per-username limit 2735 on the bandwidth used to relay data by allocations owned by that 2736 username, to limit the impact of this attack on other allocations. 2737 More mitigation can be achieved by decrementing the TTL when relaying 2738 data packets (if the underlying OS allows this). 2740 17.2. Firewall Considerations 2742 A key aspect of TURN's security considerations is that it should not 2743 weaken the protections afforded by firewalls deployed between a 2744 client and a TURN server. It is anticipated that TURN servers will 2745 often be present on the public Internet, and clients may often be 2746 inside enterprise networks with corporate firewalls. If TURN servers 2747 provide a 'backdoor' for reaching into the enterprise, TURN will be 2748 blocked by these firewalls. 2750 TURN servers therefore emulate the behavior of NAT devices which 2751 implement address-dependent filtering [RFC4787], a property common in 2752 many firewalls as well. When a NAT or firewall implements this 2753 behavior, packets from an outside IP address are only allowed to be 2754 sent to an internal IP address and port if the internal IP address 2755 and port had recently sent a packet to that outside IP address. TURN 2756 servers introduce the concept of permissions, which provide exactly 2757 this same behavior on the TURN server. An attacker cannot send a 2758 packet to a TURN server and expect it to be relayed towards the 2759 client, unless the client has tried to contact the attacker first. 2761 It is important to note that some firewalls have policies which are 2762 even more restrictive than address-dependent filtering. Firewalls 2763 can also be configured with address and port dependent filtering, or 2764 can be configured to disallow inbound traffic entirely. In these 2765 cases, if a client is allowed to connect the TURN server, 2766 communications to the client will be less restrictive than what the 2767 firewall would normally allow. 2769 17.2.1. Faked Permissions 2771 In firewalls and NAT devices, permissions are granted implicitly 2772 through the traversal of a packet from the inside of the network 2773 towards the outside peer. Thus, a permission cannot, by definition, 2774 be created by any entity except one inside the firewall or NAT. With 2775 TURN, this restriction no longer holds. Since the TURN server sits 2776 outside the firewall, at attacker outside the firewall can now send a 2777 message to the TURN server and try to create a permission for itself. 2779 This attack is prevented because all messages which create 2780 permissions (i.e., ChannelBind and CreatePermission) are 2781 authenticated. 2783 17.2.2. Blacklisted IP Addresses 2785 Many firewalls can be configured with blacklists which prevent a 2786 client behind the firewall from sending packets to, or receiving 2787 packets from, ranges of blacklisted IP addresses. This is 2788 accomplished by inspecting the source and destination addresses of 2789 packets entering and exiting the firewall, respectively. 2791 If a client connects to a TURN server, it will be able to bypass such 2792 blacklisting policies and communicate with IP addresses which the 2793 firewall would otherwise restrict. This is a problem for other 2794 protocols that provide tunneling functions, such as VPNs. It is 2795 possible to build TURN-aware firewalls which inspect TURN messages, 2796 and check the IP address of the correspondent. TURN messages to 2797 offending destinations can then be rejected. TURN is designed so 2798 that this inspection can be done statelessly. 2800 17.2.3. Running Servers on Well-Known Ports 2802 A malicious client behind a firewall might try to connect to a TURN 2803 server and obtain an allocation which it then uses to run a server. 2804 For example, a client might try to run a DNS server or FTP server. 2806 This is not possible in TURN. A TURN server will never accept 2807 traffic from a peer for which the client has not installed a 2808 permission. Thus, peers cannot just connect to the allocated port in 2809 order to obtain the service. 2811 17.3. Insider Attacks 2813 In insider attacks, a client has legitimate credentials but defies 2814 the trust relationship that goes with those credentials. These 2815 attacks cannot be prevented by cryptographic means but need to be 2816 considered in the design of the protocol. 2818 17.3.1. DoS Against TURN Server 2820 A client wishing to disrupt service to other clients might obtain an 2821 allocation and then flood it with traffic, in an attempt to swamp the 2822 server and prevent it from servicing other legitimate clients. This 2823 is mitigated by the recommendation that the server limit the amount 2824 of bandwidth it will relay for a given username. This won't prevent 2825 a client from sending a large amount of traffic, but it allows the 2826 server to immediately discard traffic in excess. 2828 Since each allocation uses a port number on the IP address of the 2829 TURN server, the number of allocations on a server is finite. An 2830 attacker might attempt to consume all of them by requesting a large 2831 number of allocations. This is prevented by the recommendation that 2832 the server impose a limit of the number of allocations active at a 2833 time for a given username. 2835 17.3.2. Anonymous Relaying of Malicious Traffic 2837 TURN servers provide a degree of anonymization. A client can send 2838 data to correspondent peers without revealing their own IP addresses. 2839 TURN servers may therefore become attractive vehicles for attackers 2840 to launch attacks against targets without fear of detection. Indeed, 2841 it is possible for a client to chain together multiple TURN servers, 2842 such that any number of relays can be used before a target receives a 2843 packet. 2845 Administrators who are worried about this attack can maintain logs 2846 which capture the actual source IP and port of the client, and 2847 perhaps even every permission that client installs. This will allow 2848 for forensic tracing to determine the original source, should it be 2849 discovered that an attack is being relayed through a TURN server. 2851 17.3.3. Manipulating other Allocations 2853 An attacker might attempt to disrupt service to other users of the 2854 TURN server by sending Refresh requests or CreatePermission requests 2855 which (through source address spoofing) appear to be coming from 2856 another user of the TURN server. TURN prevents this by requiring 2857 that the credentials used in CreatePermission, Refresh, and 2858 ChannelBind messages match those used to create the initial 2859 allocation. Thus, the fake requests from the attacker will be 2860 rejected. 2862 17.4. Other Considerations 2864 Any relay addresses learned through an Allocate request will not 2865 operate properly with IPSec Authentication Header (AH) [RFC4302] in 2866 transport or tunnel mode. However, tunnel-mode IPSec ESP [RFC4303] 2867 should still operate. 2869 18. IANA Considerations 2871 Since TURN is an extension to STUN [RFC5389], the methods, attributes 2872 and error codes defined in this specification are new methods, 2873 attributes, and error codes for STUN. This section requests IANA to 2874 add these new protocol elements to the IANA registry of STUN protocol 2875 elements. 2877 The codepoints for the new STUN methods defined in this specification 2878 are listed in Section 13. 2880 The codepoints for the new STUN attributes defined in this 2881 specification are listed in Section 14. 2883 The codepoints for the new STUN error codes defined in this 2884 specification are listed in Section 15. 2886 IANA is requested to allocate the SRV service name of "turn" for TURN 2887 over UDP or TCP, and the service name of "turns" for TURN over TLS. 2889 IANA is requested to create a registry for TURN channel numbers, 2890 initially populated as follows: 2892 0x0000 through 0x3FFF: Not available for use, since they conflict 2893 with the STUN header. 2895 0x4000 through 0x7FFF: A TURN implementation is free to use 2896 channel numbers in this range. 2898 0x8000 through 0xFFFF: Reserved. 2900 Any change to this registry must be made through an IETF Standards 2901 Action. 2903 19. IAB Considerations 2905 The IAB has studied the problem of "Unilateral Self Address Fixing", 2906 which is the general process by which a client attempts to determine 2907 its address in another realm on the other side of a NAT through a 2908 collaborative protocol reflection mechanism [RFC3424]. The TURN 2909 extension is an example of a protocol that performs this type of 2910 function. The IAB has mandated that any protocols developed for this 2911 purpose document a specific set of considerations. These 2912 considerations and the responses for TURN are documented in this 2913 section. 2915 Consideration 1: Precise definition of a specific, limited-scope 2916 problem that is to be solved with the UNSAF proposal. A short term 2917 fix should not be generalized to solve other problems. Such 2918 generalizations lead to the prolonged dependence on and usage of the 2919 supposed short term fix -- meaning that it is no longer accurate to 2920 call it "short term". 2922 Response: TURN is a protocol for communication between a relay (= 2923 TURN server) and its client. The protocol allows a client that is 2924 behind a NAT to obtain and use a public IP address on the relay. As 2925 a convenience to the client, TURN also allows the client to determine 2926 its server-reflexive transport address. 2928 Consideration 2: Description of an exit strategy/transition plan. 2929 The better short term fixes are the ones that will naturally see less 2930 and less use as the appropriate technology is deployed. 2932 Response: TURN will no longer be needed once there are no longer any 2933 NATs. Unfortunately, as of the date of publication of this document, 2934 it no longer seems very likely that NATs will go away any time soon. 2935 However, the need for TURN will also decrease as the number of NATs 2936 with the mapping property of Endpoint-Independent Mapping [RFC4787] 2937 increases. 2939 Consideration 3: Discussion of specific issues that may render 2940 systems more "brittle". For example, approaches that involve using 2941 data at multiple network layers create more dependencies, increase 2942 debugging challenges, and make it harder to transition. 2944 Response: TURN is "brittle" in that it requires the NAT bindings 2945 between the client and the server to be maintained unchanged for the 2946 lifetime of the allocation. This is typically done using keep- 2947 alives. If this is not done, then the client will lose its 2948 allocation and can no longer exchange data with its peers. 2950 Consideration 4: Identify requirements for longer term, sound 2951 technical solutions; contribute to the process of finding the right 2952 longer term solution. 2954 Response: The need for TURN will be reduced once NATs implement the 2955 recommendations for NAT UDP behavior documented in [RFC4787]. 2956 Applications are also strongly urged to use ICE [I-D.ietf-mmusic-ice] 2957 to communicate with peers; though ICE uses TURN, it does so only as a 2958 last resort, and uses it in a controlled manner. 2960 Consideration 5: Discussion of the impact of the noted practical 2961 issues with existing deployed NATs and experience reports. 2963 Response: Some NATs deployed today exhibit a mapping behavior other 2964 than Endpoint-Independent mapping. These NATs are difficult to work 2965 with, as they make it difficult or impossible for protocols like ICE 2966 to use server-reflexive transport addresses on those NATs. A client 2967 behind such a NAT is often forced to use a relay protocol like TURN 2968 because "UDP hole punching" techniques [RFC5128] do not work. 2970 20. Open Issues 2972 Note to RFC Editor: Please remove this section prior to publication 2973 of this document as an RFC. 2975 This section lists the known issues in this version of the 2976 specification. 2978 (No known issues at this time). 2980 21. Changes from Previous Versions 2982 Note to RFC Editor: Please remove this section prior to publication 2983 of this document as an RFC. 2985 This section lists the technical and major editorial changes between 2986 the various versions of this specification. Minor editorial changes 2987 are not described. 2989 21.1. Changed from -13 to -14 2991 o Reworded the text in Section 6.2 and Section 7.2 to more clearly 2992 describe how the allocation lifetime is computed in the case where 2993 a client requests a lifetime that is greater than both the default 2994 lifetime and the server's maximum allowed lifetime. 2996 o In Section 8, changed the term "default permission lifetime" to 2997 "Permission Lifetime" to make it clearer that the lifetime of a 2998 permission is not configurable. 3000 o In Section 6.2, swapped the steps that check the RESERVATION-TOKEN 3001 and EVEN-PORT attributes to correctly handle the case where an 3002 Allocate request contains both attributes. The new text correctly 3003 returns 400 Bad Request in this case. 3005 o Added text in the Overview section to describe why various timer 3006 values were chosen. 3008 o Added a sentence to the IAB consideration section saying that the 3009 disappearance of NATs in the near-term seems unlikely. 3011 o The former "Other Features" section of the Overview has been 3012 replaced with a series of sections describing various secondary 3013 features of TURN, and the text describing and motivating these 3014 secondary features has been expanded. As a part of this rewrite, 3015 there is now a section that describes how to avoid IP 3016 fragmentation when using TURN. 3018 o Added some additional text in the Overview to explain how a client 3019 would select between UDP, TCP, and TLS transport. 3021 o Fixed various minor typos. 3023 21.2. Changes from -12 to -13 3025 o Added a new error code: 403 (Forbidden). 3027 o When processing a CreatePermission or ChannelBind request 3028 containing a XOR-PEER-ADDRESS attribute, the server is allow to 3029 reject certain IP address and port combinations for administrative 3030 or other reasons by returning a 403 (Forbidden) error. 3032 o Added a request to IANA to establish a registery for channel 3033 numbers. 3035 o Clarified the usage of the nonce value: a new random nonce SHOULD 3036 be selected for each Allocate attempt, and the nonce SHOULD be 3037 expired at least once an hour. Referenced [RFC4086] for 3038 guidelines on selecting the nonce value. 3040 o Made a number of minor editoral changes. 3042 21.3. Changes from -11 to -12 3044 o Changed the port numbers used in the examples for the client, the 3045 peers, and the relayed-transport-address to put them in the 3046 Dynamic port range. They were previously in the Registered port 3047 range, which was arguably unrealistic. 3049 o Noted that the XOR-MAPPED-ADDRESS attribute is defined in RFC 3050 5389. 3052 o Used the codepoint names (Not-ECT, ECT(0), ECT(1), and CE) when 3053 talking about the ECN field. 3055 o Updated the Introduction to note that the client must not only 3056 communicate its relayed-transport-address to the peers, but also 3057 learn the peers' server-reflexive transport addresses. As a 3058 result, removed the suggestion that the client could use a webpage 3059 to communicate with its peers. 3061 o Added a description of the "TURN Loop attack" and its mitigation 3062 to the Security Considerations section. 3064 o Fixed some errors in the examples in the Overview section. They 3065 had not been updated to be consistent with the change introduced 3066 in version -11 that a permission must be created before a client 3067 can send data to a peer. 3069 o In the Additional Features subsection of the Overview, reworded 3070 the discussion of what end-to-end features are preserved by TURN. 3071 The previous text said that a number of features did not work, but 3072 as of version -11, these features _may_ work. At the same time, 3073 added a sentence noting that any Path MTU Discovery mechanism 3074 using the DONT-FRAGMENT attribute will not receive ICMP messages 3075 and will thus have to use techniques like those described in 3076 [RFC4821]. 3078 o Added the recommendation that, when TCP transport is used between 3079 the client and the server, both ends should close the connection 3080 if they notice a long sequence of invalid TURN messages. A likely 3081 cause of this is an undetected bit error corrupting a length field 3082 somewhere. 3084 o Reworded the paragraph explaining that channel bindings are per- 3085 allocation to further stress this point. 3087 o In the discussion on setting the fragmentation fields, added a 3088 sentence saying that the client or server should follow the normal 3089 rules for fragmentation as described in [RFC1122]. 3091 21.4. Changes from -10 to -11 3093 o Clarified that, when the client is redirected to an alternate 3094 server, the client uses the same transport protocol to the 3095 alternate server as it did to the original server. 3097 o Clarified the information that the server needs to store to 3098 authenticate requests and to compute the message-integrity on 3099 responses. Noted that the server need not store the password 3100 explicitly, but can instead store the key value, which may be 3101 desirable for security reasons. 3103 o Clarified that TURN runs on the same ports as TURN by default, but 3104 noted that a server can use a different port because TURN has its 3105 own SRV service names. Strengthened the language for using the 3106 SRV procedures from "typically" to "SHOULD". Also added a 3107 sentence in the IANA considerations section requesting that IANA 3108 reserve the service names for TURN; previously they were described 3109 in the text but not mentioned in the IANA considerations section. 3111 o Added a detailed example, complete with attributes and their 3112 values, of the use of TURN. 3114 o Reduced the range of channel numbers. Channel numbers now range 3115 from 0x4000 through 0x7FFF. Values in the range 0x8000 through 3116 0xFFFF are now reserved. 3118 o Rewrote the IAB Considerations section to directly address the 3119 considerations listed in [RFC3424]. 3121 o Generalized the 508 error code so it can be used for any sort of 3122 capacity-related problem. This error code was previously allowed 3123 only in Allocate responses, but is now also allowed in 3124 CreatePermission and ChannelBind responses to indicate that the 3125 server is unable to carry out the request due to some capacity 3126 problem. 3128 o Changed the syntax of the CreatePermission request to allow 3129 multiple XOR-PEER-ADDRESS attributes to appear in the message, so 3130 that multiple permissions can be created or refreshed at the same 3131 time. 3133 o Added the restriction that the server must already have a 3134 permission installed for the IP address in the XOR-PEER-ADDRESS 3135 attribute of a Send indication, otherwise the Send indication is 3136 ignored by the server. 3138 o Put back the preferred behaviors into Section 12, reversing the 3139 change made in version -10. 3141 o Explicitly allow the server to restrict the range of IP addresses 3142 and ports it is willing to relay data too. 3144 21.5. Changes from -09 to -10 3146 o Changed the recommendation for using the SOFTWARE attribute. 3147 Previously its use was recommended in all requests and responses; 3148 now it is only recommended in Allocate and Refresh requests and 3149 responses, though it may appear elsewhere. Also, version -09 3150 incorrectly referred to this attribute as "SOFTWARE-TYPE". 3152 o Changed the name of the PEER-ADDRESS and RELAYED-ADDRESS 3153 attributes to XOR-PEER-ADDRESS and XOR-RELAYED-ADDRESS 3154 respectively for consistency with other specifications. 3156 o Removed the concept of a "preserving" allocation. All allocations 3157 are now non-preserving. This simplifies the base specification 3158 and allows it to advance more rapidly; see the discussion in the 3159 BEHAVE meeting of 29 July 2008. The concept of a preserving 3160 allocation will be advanced as an extension to TURN. As part of 3161 this change, the P bit in the REQUESTED-PROPS attribute, the ICMP 3162 attribute, and ICMP message relaying was removed. Further, in 3163 Section 12, the preferred behaviors were removed, leaving the 3164 alternate behaviors as the specified behaviors. 3166 o Replaced the REQUESTED-PROPS attribute with the EVEN-PORT 3167 attribute. The new attribute lacks the feature of the old 3168 attribute of being an alternate way to specify new allocation 3169 properties. As a consequence, the only way to specify a new 3170 allocation property is to define a new attribute. 3172 o Added text recommending that the client check that the IP address 3173 in XOR-PEER-ADDRESS attribute in a received Data indication is one 3174 with which the client believes there is an active permission. 3175 Similarly, it is recommended that the client check that a 3176 permission exist when receiving a ChannelData message. 3178 o Added text recommending that the client delete the allocation if 3179 it receives a ChannelBind failure response on an unbound channel. 3181 o Added the CreatePermission request/response transaction which adds 3182 or updates permissions, and removed the ability for Send 3183 indications and ChannelBind messages to install or update 3184 permissions. The net effect is that only authenticate-able 3185 messages (i.e., CreatePermission requests and ChannelBind 3186 requests) can install or refresh permissions; unauthenticate-able 3187 Send indications and ChannelData messages do not. 3189 o Removed all support for IPv6. All IPv6 support, including ways of 3190 relaying between IPv4 and IPv6, will now be covered in 3191 [I-D.ietf-behave-turn-ipv6]. 3193 o Reserved attribute code point 0x0021. This was previously used 3194 for the TIMER-VAL attribute, which was removed when the 3195 SetActiveDestination feature was removed. 3197 o Added the DONT-FRAGMENT attribute which allows the client to 3198 request that the server set the DF bit when sending the UDP 3199 datagram to the peer. This attribute may appear in both Allocate 3200 requests and Send indications. 3202 o Changed how the ALTERNATE-SERVER attribute is used. The attribute 3203 can no longer be used with any error code, but must be used with 3204 300 (Try Alternative). It can now appear in unauthenticated 3205 responses, however there are restrictions around how the 3206 subsequent Allocate request is authenticated. 3208 o Reworked the details of how idempotency of requests is handled, 3209 making it clear that the stack can either remember all 3210 transactions for 40 seconds, or can handle this using the so- 3211 called "stateless stack approach". Made some changes to the 3212 semantics of the Allocate, Refresh, and ChannelBind requests as a 3213 consequence. 3215 o Added the requirement that a client cannot re-use previously bound 3216 channel number or transport address until 5 minutes after the 3217 channel binding expires. This avoids various race conditions. 3219 o Removed the requirement that an allocation cannot be re-used 3220 within 2 minutes of having been deleted. This requirement was put 3221 in place to prevent mis-delivered packets but is no longer seen as 3222 having any real value. 3224 o Added a recommendation that the server impose quotas on both the 3225 number of allocations and the amount of bandwidth a given username 3226 can use at one time. These quotas help protect against denial-of- 3227 service attacks. 3229 o Completely rewrote the security considerations section. 3231 o Made quite a few changes to the descriptive text in both the 3232 Overview and the normative text to try to further clarify 3233 concepts. 3235 21.6. Changes from -08 to -09 3237 o Added text to properly define the ICMP attribute. This attribute 3238 was introduced in TURN-08, but not fully defined due to an 3239 oversight. Clarified that the attribute can appear in a Data 3240 indication, but not a Send indication. Added text to the section 3241 on receiving a Data indication that points out that this attribute 3242 may be present. 3244 o Changed the wording around the handling of the DSCP field to allow 3245 the server to set the DSCP to an arbitrary value if the next hop 3246 is a Diff-Serv classifier and marker. 3248 o When the server generates a 508 response due to an unsupported 3249 flag in the REQUESTED-PROPS attribute, the server now includes the 3250 REQUESTED-PROPS attribute in the response with all the flags it 3251 supports set to 1. This allows the client to see if the server 3252 does not understand one of its flags. Similarly, the client is 3253 now allowed to immediately retry the request if it modifies the 3254 included REQUESTED-PROPS attribute. 3256 o Clarified that the REQUESTED-PROPS attribute can be used in 3257 conjunction with the RESERVATION-TOKEN attribute as long as both 3258 the E and R bits are 0. The spec previously contradicted itself 3259 on this point. 3261 o Clarified that when the server receives a ChannelData message with 3262 a length field of 0, it sends a UDP Datagram to the peer that 3263 contains no application data. 3265 o Rewrote some text around relaying incoming UDP Datagrams to avoid 3266 duplication of text in the Data indication and Channel sections. 3268 o Added a note that points out that the on-going work on randomizing 3269 port allocations [I-D.ietf-tsvwg-port-randomization] may be 3270 applicable to TURN. 3272 o Clarified that the Allocate request containing a RESERVATION-TOKEN 3273 attribute can use any 5-tuple, and that 5-tuple need not have any 3274 specific relationship to the 5-tuple of the Allocate request that 3275 created the reservation. 3277 o Added a note that discusses retransmitted Allocate requests over 3278 UDP where the first request receives a failure response, but the 3279 second receives a success response. The server may elect to 3280 remember transmitted failure responses to avoid this situation. 3282 o Added text about the usage of the SOFTWARE-TYPE attribute 3283 (formerly known as the SERVER attribute) in TURN messages. 3285 o Rewrote the text in the Overview that motivates why TURN supports 3286 TCP and TLS between the client and the server. The previous text 3287 had been identified by various readers as inadequate and 3288 misleading. 3290 o Rewrote the section how a server handles a Refresh request to 3291 clarify processing in various error conditions. The new text 3292 makes it clear that it is OK to delete a non-existent allocation. 3293 It also clarifies how to handle retransmissions of Refresh 3294 requests over UDP. 3296 o Renamed the "RELAY-ADDRESS" attribute to "RELAYED-ADDRESS", since 3297 the text consistently uses the term "relayed transport address" 3298 for the concept and ICE uses the term "relayed candidate". 3300 o Changed the codepoint assigned to the error code "Wrong 3301 Credentials" from 438 to 441 to avoid a conflict with the "Stale 3302 Nonce" error code of STUN. 3304 o Changed the text to consistently use non-capitalized "request", 3305 "response" and "indication", except in headings, error code names, 3306 etc. 3308 o Added a note mentioning that TURN packets can be demuxed from 3309 other packets arriving on the same socket by looking at the 3310 5-tuple of the arriving packet. 3312 o Clarified that there are no required attributes is a ChannelBind 3313 success response. 3315 21.7. Changes from -07 to -08 3317 o Removed the BANDWIDTH attribute and all associated text (including 3318 error code 507 "Insufficient Bandwidth Capacity"), as the 3319 requirements for this feature were not clear and it was felt the 3320 feature could be easily added later. 3322 o Changed the format of the REQUESTED-PROPS attribute from a one- 3323 byte field to a set of bit flags. Changed the semantics of the 3324 unused portion of the value from RFFU to "MUST be 0" to give a 3325 more desirable behavior when new flags are defined. 3327 o Introduced the concept of Preserving vs. Non-Preserving 3328 allocations. As a result, completely revamped the rules for how 3329 to set the fields in the IP header, and added rules for relaying 3330 ICMP messages when the allocation is Preserving. 3332 21.8. Changes from -06 to -07 3334 o Rewrote the General Behavior section, making various changes in 3335 the process. 3337 o Changed the usage of authentication from MUST to SHOULD. 3339 o Changed the requirement that subsequent requests use the same 3340 username and password from MUST to SHOULD to allow for the 3341 possibility of changing the credentials using some unspecified 3342 mechanism. 3344 o Introduced a 438 (Wrong Credentials) error which is used when a 3345 non-Allocate request authenticates but does not use the same 3346 username and password as the Allocate request. Having a separate 3347 error code for this case avoids the client being confused over 3348 what the error actually is. 3350 o The server must now prevent the relayed transport address and the 3351 5-tuple from being reused in different allocations for 2 minutes 3352 after the allocation expires. 3354 o Changed the usage of FINGERPRINT from MUST NOT to MAY, to allow 3355 for the possible multiplexing of TURN with some other protocol. 3357 o Rewrote much of the section on Allocations, splitting it into 3358 three new sections (one on allocations in general, one on creating 3359 an allocation, and one on refreshing an allocation). 3361 o Replaced the mechanism for requesting relayed transport addresses 3362 with specific properties. The new mechanism is less powerful: a 3363 client can request an even port, or a pair of ports, but cannot 3364 request a single odd port or a specific port as was possible under 3365 the old mechanism. Nor can the client request a specific IP 3366 address. 3368 o Changed the rules for handling ALTERNATE-SERVER, removing the 3369 requirement that the referring server have "positive knowledge" 3370 about the state of the alternate server. The new rules instead 3371 rely on text in STUN to prevent referral loops. 3373 o Changed the rules for allocation lifetimes. Allocations lifetimes 3374 are now a minimum of 10 minutes; the client can ask for longer 3375 values, but requests for shorter values are ignored. The text now 3376 recommends that the client refresh an allocation one minute before 3377 it expires. 3379 o Put in temporary procedures for handling the BANDWIDTH attribute, 3380 modelled on the LIFETIME attribute. These procedures are mostly 3381 placeholders and likely to change in the next revision. 3383 o Added a detailed description of how a client reacts to the various 3384 errors it can receive in reply to an Allocate request. This 3385 replaces the various descriptions that were previously scattered 3386 throughout the document, which were inconsistent and sometimes 3387 contradictory. 3389 o Added a new section that gives the normative rules for 3390 permissions. 3392 o Changed the rules around permission lifetimes. The text used to 3393 recommend a value of one minute; it MUST now be 5 minutes. 3395 o Removed the errors "Channel Missing or Invalid", "Peer Address 3396 Missing or Invalid" and "Lifetime Malformed or Invalid" and used 3397 400 "Bad Request" instead. 3399 o Rewrote portions of the section on Send and Data indications and 3400 the section on Channels to try to make the client vs. server 3401 behavior clearer. 3403 o Channel bindings now expire after 10 minutes, and must be 3404 refreshed to keep them alive. 3406 o Binding a channel now installs or refreshes a permission for the 3407 IP address of corresponding peer. 3409 o Changed the wording describing the situation when the client sends 3410 a ChannelData message before receiving the ChannelBind success 3411 response. -06 said that client SHOULD NOT do this; -07 now says 3412 that a client MAY, but describes the consequences of doing it. 3414 o Added a section discussing the setting of fields in the IP header. 3416 o Replaced the REQUESTED-PORT-PROPS attribute with the REQUESTED- 3417 PROPS attribute that has a different format and semantics, but 3418 reuses the same code point. 3420 o Replaced the REQUESTED-IP attribute with the RESERVATION-TOKEN 3421 attribute, which has a different format and semantics, but reuses 3422 the same code point. 3424 o Removed error codes 443 and 444, and replaced them with 508 3425 (Insufficient Port Capacity). Also changed the error text for 3426 code 507 from "Insufficient Capacity" to "Insufficient Bandwidth 3427 Capacity". 3429 21.9. Changes from -05 to -06 3431 o Changed the mechanism for allocating channels to the one proposed 3432 by Eric Rescorla at the Dec 2007 IETF meeting. 3434 o Removed the framing mechanism (which was used to frame all 3435 messages) and replaced it with the ChannelData message. As part 3436 of this change, noted that the demux of ChannelData messages from 3437 TURN messages can be done using the first two bits of the message. 3439 o Rewrote the sections on transmitted and receiving data as a result 3440 of the above to changes, splitting it into a section on Send and 3441 Data indications and a separate section on channels. 3443 o Clarified the handling of Allocate request messages. In 3444 particular, subsequent Allocate request messages over UDP with the 3445 same transaction id are not an error but a retransmission. 3447 o Restricted the range of ports available for allocation to the 3448 Dynamic and/or Private Port range, and noted when ports outside 3449 this range can be used. 3451 o Changed the format of the REQUESTED-TRANSPORT attribute. The 3452 previous version used 00 for UDP and 01 for TCP; the new version 3453 uses protocol numbers from the IANA protocol number registry. The 3454 format of the attribute also changed. 3456 o Made a large number of changes to the non-normative portion of the 3457 document to reflect technical changes and improve the 3458 presentation. 3460 o Added the Issues section. 3462 21.10. Changes from -04 to -05 3464 o Removed the ability to allocate addresses for TCP relaying. This 3465 is now covered in a separate document. However, communication 3466 between the client and the server can still run over TCP or TLS/ 3467 TCP. This resulted in the removal of the Connect method and the 3468 TIMER-VAL and CONNECT-STAT attributes. 3470 o Added the concept of channels. All communication between the 3471 client and the server flows on a channel. Channels are numbered 3472 0..65535. Channel 0 is used for TURN messages, while the 3473 remaining channels are used for sending unencapsulated data to/ 3474 from a remote peer. This concept adds a new Channel Confirmation 3475 method and a new CHANNEL-NUMBER attribute. The new attribute is 3476 also used in the Send and Data methods. 3478 o The framing mechanism formally used just for stream-oriented 3479 transports is now also used for UDP, and the former Type and 3480 Reserved fields in the header have been replaced by a Channel 3481 Number field. The length field is zero when running over UDP. 3483 o TURN now runs on its own port, rather than using the STUN port. 3484 The use of channels requires this. 3486 o Removed the SetActiveDestination concept. This has been replaced 3487 by the concept of channels. 3489 o Changed the allocation refresh mechanism. The new mechanism uses 3490 a new Refresh method, rather than repeating the Allocation 3491 transaction. 3493 o Changed the syntax of SRV requests for secure transport. The new 3494 syntax is "_turns._tcp" rather than the old "_turn._tls". This 3495 change mirrors the corresponding change in STUN SRV syntax. 3497 o Renamed the old REMOTE-ADDRESS attribute to PEER-ADDRESS, and 3498 changed it to use the XOR-MAPPED-ADDRESS format. 3500 o Changed the RELAY-ADDRESS attribute to use the XOR-MAPPED-ADDRESS 3501 format (instead of the MAPPED-ADDRESS format)). 3503 o Renamed the 437 error code from "No Binding" to "Allocation 3504 Mismatch". 3506 o Added a discussion of what happens if a client's public binding on 3507 its outermost NAT changes. 3509 o The document now consistently uses the term "peer" as the name of 3510 a remote endpoint with which the client wishes to communicate. 3512 o Rewrote much of the document to describe the new concepts. At the 3513 same time, tried to make the presentation clearer and less 3514 repetitive. 3516 22. Acknowledgements 3518 The authors would like to thank the various participants in the 3519 BEHAVE working group for their many comments on this draft. Marc 3520 Petit-Huguenin, Remi Denis-Courmont, Jason Fischl, Derek MacDonald, 3521 Scott Godin, Cullen Jennings, Lars Eggert, Magnus Westerlund, Benny 3522 Prijono, and Eric Rescorla have been particularly helpful, with Eric 3523 also suggesting the channel allocation mechanism, and Cullen 3524 suggesting the REQUESTED-PORT-PROPS mechanism. Christian Huitema was 3525 an early contributor to this document and was a co-author on the 3526 first few drafts. Finally, the authors would like to thank Dan Wing 3527 for both his contributions to the text and his huge help in 3528 restarting progress on this draft after work had stalled. 3530 23. References 3532 23.1. Normative References 3534 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3535 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3536 October 2008. 3538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3539 Requirement Levels", BCP 14, RFC 2119, March 1997. 3541 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3542 "Definition of the Differentiated Services Field (DS 3543 Field) in the IPv4 and IPv6 Headers", RFC 2474, 3544 December 1998. 3546 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3547 of Explicit Congestion Notification (ECN) to IP", 3548 RFC 3168, September 2001. 3550 [RFC1122] Braden, R., "Requirements for Internet Hosts - 3551 Communication Layers", STD 3, RFC 1122, October 1989. 3553 23.2. Informative References 3555 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3556 November 1990. 3558 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3559 September 1981. 3561 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3562 E. Lear, "Address Allocation for Private Internets", 3563 BCP 5, RFC 1918, February 1996. 3565 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 3566 Self-Address Fixing (UNSAF) Across Network Address 3567 Translation", RFC 3424, November 2002. 3569 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3570 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3571 RFC 4787, January 2007. 3573 [I-D.ietf-mmusic-ice] 3574 Rosenberg, J., "Interactive Connectivity Establishment 3575 (ICE): A Protocol for Network Address Translator (NAT) 3576 Traversal for Offer/Answer Protocols", 3577 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 3579 [I-D.ietf-behave-turn-tcp] 3580 Perreault, S. and J. Rosenberg, "Traversal Using Relays 3581 around NAT (TURN) Extensions for TCP Allocations", 3582 draft-ietf-behave-turn-tcp-02 (work in progress), 3583 March 2009. 3585 [I-D.ietf-behave-turn-ipv6] 3586 Camarillo, G. and O. Novo, "Traversal Using Relays around 3587 NAT (TURN) Extension for IPv6", 3588 draft-ietf-behave-turn-ipv6-06 (work in progress), 3589 March 2009. 3591 [I-D.ietf-tsvwg-port-randomization] 3592 Larsen, M. and F. Gont, "Port Randomization", 3593 draft-ietf-tsvwg-port-randomization-03 (work in progress), 3594 March 2009. 3596 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 3597 Peer (P2P) Communication across Network Address 3598 Translators (NATs)", RFC 5128, March 2008. 3600 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 3601 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 3602 March 1996. 3604 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3605 Jacobson, "RTP: A Transport Protocol for Real-Time 3606 Applications", STD 64, RFC 3550, July 2003. 3608 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3609 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 3610 RFC 3711, March 2004. 3612 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 3613 December 2005. 3615 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 3616 RFC 4303, December 2005. 3618 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3619 Discovery", RFC 4821, March 2007. 3621 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3622 A., Peterson, J., Sparks, R., Handley, M., and E. 3623 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3624 June 2002. 3626 [I-D.rosenberg-mmusic-ice-nonsip] 3627 Rosenberg, J., "Guidelines for Usage of Interactive 3628 Connectivity Establishment (ICE) by non Session 3629 Initiation Protocol (SIP) Protocols", 3630 draft-rosenberg-mmusic-ice-nonsip-01 (work in progress), 3631 July 2008. 3633 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3634 Requirements for Security", BCP 106, RFC 4086, June 2005. 3636 [Frag-Harmful] 3637 Kent and Mogul, "Fragmentation Considered Harmful". 3639 Proc. SIGCOMM '87, vol. 17, No. 5, October 1987 3641 [Port-Numbers] 3642 "IANA Port Numbers Registry", 3643 . 3645 [Protocol-Numbers] 3646 "IANA Protocol Numbers Registry", 2005, 3647 . 3649 Authors' Addresses 3651 Jonathan Rosenberg 3652 Cisco Systems, Inc. 3653 Edison, NJ 3654 USA 3656 Email: jdrosen@cisco.com 3657 URI: http://www.jdrosen.net 3659 Rohan Mahy 3660 (Unaffiliated) 3662 Email: rohan@ekabal.com 3664 Philip Matthews 3665 Alcatel-Lucent 3666 600 March Road 3667 Ottawa, Ontario 3668 Canada 3670 Phone: 3671 Fax: 3672 Email: philip_matthews@magma.ca 3673 URI: