idnits 2.17.1 draft-ietf-behave-turn-15.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 (June 10, 2009) is 5435 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 665, 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-03 == 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: December 12, 2009 (Unaffiliated) 6 P. Matthews 7 Alcatel-Lucent 8 June 10, 2009 10 Traversal Using Relays around NAT (TURN): Relay Extensions to Session 11 Traversal Utilities for NAT (STUN) 12 draft-ietf-behave-turn-15 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 December 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 6. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . 33 98 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 33 99 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 34 100 9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . . . . . . 46 119 14. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 46 120 14.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 46 121 14.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 47 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 . . . . . . . . . . . . . . . . . . . 48 127 14.8. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . . 48 128 14.9. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . . 49 129 15. New STUN Error Response Codes . . . . . . . . . . . . . . . . 49 130 16. Detailed Example . . . . . . . . . . . . . . . . . . . . . . . 49 131 17. Security Considerations . . . . . . . . . . . . . . . . . . . 57 132 17.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 57 133 17.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 57 134 17.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 58 135 17.1.3. Faked Refreshes and Permissions . . . . . . . . . . . 58 136 17.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . . 58 137 17.1.5. Impersonating a Server . . . . . . . . . . . . . . . 59 138 17.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . . 59 139 17.1.7. TURN loop attack . . . . . . . . . . . . . . . . . . 60 140 17.2. Firewall Considerations . . . . . . . . . . . . . . . . . 61 141 17.2.1. Faked Permissions . . . . . . . . . . . . . . . . . . 61 142 17.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 62 143 17.2.3. Running Servers on Well-Known Ports . . . . . . . . . 62 144 17.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 62 145 17.3.1. DoS Against TURN Server . . . . . . . . . . . . . . . 62 146 17.3.2. Anonymous Relaying of Malicious Traffic . . . . . . . 63 147 17.3.3. Manipulating other Allocations . . . . . . . . . . . 63 148 17.4. Other Considerations . . . . . . . . . . . . . . . . . . 63 149 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 150 19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 64 151 20. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 66 152 21. Changes from Previous Versions . . . . . . . . . . . . . . . . 66 153 21.1. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 66 154 21.2. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 66 155 21.3. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 67 156 21.4. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 68 157 21.5. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 69 158 21.6. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 70 159 21.7. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 72 160 21.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 73 161 21.9. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 74 162 21.10. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 76 163 21.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 76 164 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 77 165 23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 166 23.1. Normative References . . . . . . . . . . . . . . . . . . 78 167 23.2. Informative References . . . . . . . . . . . . . . . . . 78 168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80 170 1. Introduction 172 A host behind a NAT may wish to exchange packets with other hosts, 173 some of which may also be behind NATs. To do this, the hosts 174 involved can use 'Hole Punching' techniques (see [RFC5128]) in an 175 attempt discover a direct communication path; that is, a 176 communication path that goes from host to another through intervening 177 NATs and routers, but does not traverse any relays. 179 As described in [RFC5128] and [RFC4787], hole punching techniques 180 will fail if both hosts are behind NATs that are not well-behaved. 181 For example, if both hosts are behind NATs that have a mapping 182 behavior of "address dependent mapping" or "address and port 183 dependent mapping", then hole punching techniques generally fail. 185 When a direct communication path cannot be found, it is necessary to 186 use the services of an intermediate host that acts as a relay for the 187 packets. This relay typically sits in the public Internet and relays 188 packets between two hosts that both sit behind NATs. 190 This specification defines a protocol, called TURN, that allows a 191 host behind a NAT (called the TURN client) to request that another 192 host (called the TURN server) act as a relay. The client can arrange 193 for the server to relay packets to and from certain other hosts 194 (called peers) and can control aspects of how the relaying is done. 195 The client does this by obtaining an IP address and port on the 196 server, called the relayed-transport-address. When a peer sends a 197 packet to the relayed-transport-address, the server relays the packet 198 to the client. When the client sends a data packet to the server, 199 the server relays it to the appropriate peer using the relayed- 200 transport-address as the source. 202 A client using TURN must have some way to communicate the relayed- 203 transport-address to its peers, and to learn each peer's IP address 204 and port (more precisely, each peer's server-reflexive transport 205 address, see Section 2). How this is done is out of the scope of the 206 TURN protocol. One way this might be done is for the client and 207 peers to exchange e-mail messages. Another way is for the client and 208 its peers to use a special-purpose 'introduction' or 'rendezvous' 209 protocol (see [RFC5128] for more details). 211 If TURN is used with ICE [I-D.ietf-mmusic-ice], then the relayed- 212 transport-address and the IP addresses and ports of the peers are 213 included in the ICE candidate information which the rendezvous 214 protocol must carry. For example, if TURN and ICE are used as part 215 of a multimedia solution using SIP [RFC3261], then SIP serves the 216 role of the rendezvous protocol, carrying the ICE candidate 217 information inside the body of SIP messages. If TURN and ICE are 218 used with some other rendezvous protocol, then 219 [I-D.rosenberg-mmusic-ice-nonsip] provides guidance on the services 220 the rendezvous protocol must perform. 222 Though the use of a TURN server to enable communication between two 223 hosts behind NATs is very likely to work, it comes at a high cost to 224 the provider of the TURN server, since the server typically needs a 225 high bandwidth connection to the Internet . As a consequence, it is 226 best to use a TURN server only when a direct communication path 227 cannot be found. When the client and a peer use ICE to determine the 228 communication path, ICE will use hole punching techniques to search 229 for a direct path first and only use a TURN server when a direct path 230 cannot be found. 232 TURN was originally invented to support multimedia sessions signaled 233 using SIP. Since SIP supports forking, TURN supports multiple peers 234 per relayed-transport-address; a feature not supported by other 235 approaches (e.g., SOCKS [RFC1928]). However, care has been taken to 236 make sure that TURN is suitable for other types of applications. 238 TURN was designed as one piece in the larger ICE approach to NAT 239 traversal. Implementors of TURN are urged to investigate ICE and 240 seriously consider using it for their application. However, it is 241 possible to use TURN without ICE. 243 TURN is an extension to the STUN (Session Traversal Utilities for NAT 244 [RFC5389]) protocol. Most, though not all, TURN messages are STUN- 245 formatted messages. A reader of this document should be familiar 246 with STUN. 248 2. Overview of Operation 250 This section gives an overview of the operation of TURN. It is non- 251 normative. 253 In a typical configuration, a TURN client is connected to a private 254 network [RFC1918] and through one or more NATs to the public 255 Internet. On the public Internet is a TURN server. Elsewhere in the 256 Internet are one or more peers that the TURN client wishes to 257 communicate with. These peers may or may not be behind one or more 258 NATs. The client uses the server as a relay to send packets to these 259 peers and to receive packets from these peers. 261 Peer A 262 Server-Reflexive +---------+ 263 Transport Address | | 264 192.0.2.150:32102 | | 265 | /| | 266 TURN | / ^| Peer A | 267 Client's Server | / || | 268 Host Transport Transport | // || | 269 Address Address | // |+---------+ 270 10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A 271 | | ||N| / Host Transport 272 | +-+ | ||A|/ Address 273 | | | | v|T| 192.168.100.2:49582 274 | | | | /+-+ 275 +---------+| | | |+---------+ / +---------+ 276 | || |N| || | // | | 277 | TURN |v | | v| TURN |/ | | 278 | Client |----|A|----------| Server |------------------| Peer B | 279 | | | |^ | |^ ^| | 280 | | |T|| | || || | 281 +---------+ | || +---------+| |+---------+ 282 | || | | 283 | || | | 284 +-+| | | 285 | | | 286 | | | 287 Client's | Peer B 288 Server-Reflexive Relayed Transport 289 Transport Address Transport Address Address 290 192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191 292 Figure 1 294 Figure 1 shows a typical deployment. In this figure, the TURN client 295 and the TURN server are separated by a NAT, with the client on the 296 private side and the server on the public side of the NAT. This NAT 297 is assumed to be a "bad" NAT; for example, it might have a mapping 298 property of address-and-port-dependent mapping (see [RFC4787] for a 299 description of what this means). 301 The client talks to the server from a (IP address, port) combination 302 called the client's HOST TRANSPORT ADDRESS. (The combination of an 303 IP address and port is called a TRANSPORT ADDRESS). 305 The client sends TURN messages from its host transport address to a 306 transport address on the TURN server which is known as the TURN 307 SERVER TRANSPORT ADDRESS. The client learns the server's transport 308 address through some unspecified means (e.g., configuration), and 309 this address is typically used by many clients simultaneously. 311 Since the client is behind a NAT, the server sees packets from the 312 client as coming from a transport address on the NAT itself. This 313 address is known as the client's SERVER-REFLEXIVE transport address; 314 packets sent by the server to the client's server-reflexive transport 315 address will be forwarded by the NAT to the client's host transport 316 address. 318 The client uses TURN commands to create and manipulate an ALLOCATION 319 on the server. An allocation is a data structure on the server, an 320 important component of which is a RELAYED TRANSPORT ADDRESS. The 321 relayed transport address for the allocation is a transport address 322 on the server which is used to send and receive packets to the peers. 324 Once an allocation is created, the client can send application data 325 to the server along with an indication of which peer the data is to 326 be sent to, and the server will relay this data to the appropriate 327 peer. The client sends the application data to the server inside a 328 TURN message; at the server, the data is extracted from the TURN 329 message and sent to the peer in a UDP datagram. In the reverse 330 direction, a peer can send application data in a UDP datagram to the 331 relayed transport address for the allocation; the server will then 332 encapsulate this data inside a TURN message and send it to the client 333 along with an indication of which peer sent the data. Since the TURN 334 message always contains an indication of which peer the client is 335 communicating with, the client can use a single allocation to 336 communicate with multiple peers. 338 When the peer is behind a NAT, then the client must identify the peer 339 using its server-reflexive transport address rather than its host 340 transport address. For example, to send application data to peer A 341 in the example above, the client must specify 192.0.2.150:32102 (peer 342 A's server-reflexive transport address) rather than 192.168.100.2: 343 49582 (peer A's host transport address). 345 Each allocation on the server belongs to a single client and has 346 exactly one relayed transport address which is used only by that 347 allocation. Thus when a packet arrives at a relayed transport 348 address on the server, the server knows which client the data is 349 intended for. However, the client may have multiple allocations on a 350 server at the same time. 352 2.1. Transports 354 TURN as defined in this specification always uses UDP between the 355 server and the peer. However, this specification allows the use of 356 any one of UDP, TCP, or TLS over TCP to carry the TURN messages 357 between the client and the server. 359 +----------------------------+---------------------+ 360 | TURN client to TURN server | TURN server to peer | 361 +----------------------------+---------------------+ 362 | UDP | UDP | 363 | TCP | UDP | 364 | TLS over TCP | UDP | 365 +----------------------------+---------------------+ 367 If TCP or TLS over TCP is used between the client and the server, 368 then the server will convert between these transports and UDP 369 transport when relaying data to/from the peer. 371 Since this version of TURN only supports UDP between the server and 372 the peer, it is expected that most clients will prefer to also use 373 UDP between the client and the server. That being the case, some 374 readers may wonder: Why also support TCP and TLS over TCP? 376 TURN supports TCP transport between the client and the server because 377 some firewalls are configured to block UDP entirely. These firewalls 378 block UDP but not TCP in part because TCP has properties that make 379 the intention of the nodes being protected by the firewall more 380 obvious to the firewall. For example, TCP has a three-way handshake 381 that makes in clearer that the protected node really wishes to have 382 that particular connection established, while for UDP the best the 383 firewall can do is guess which flows are desired by using filtering 384 rules. Also, TCP has explicit connection teardown, while for UDP the 385 firewall has to use timers to guess when the flow is finished. 387 TURN supports TLS over TCP transport between the client and the 388 server because TLS provides additional security properties not 389 provided by TURN's default digest authentication; properties which 390 some clients may wish to take advantage of. In particular, TLS 391 provides a way for the client to ascertain that it is talking to the 392 server that it intended to, and also provides for confidentiality of 393 TURN control messages. TURN does not require TLS because the 394 overhead of using TLS is higher than that of digest authentication; 395 for example, using TLS likely means that most application data will 396 be doubly encrypted (once by TLS and once to ensure it is still 397 encrypted in the UDP datagram). 399 There is a planned extension to TURN to add support for TCP between 400 the server and the peers [I-D.ietf-behave-turn-tcp]. For this 401 reason, allocations that use UDP between the server and the peers are 402 known as UDP allocations, while allocations that use TCP between the 403 server and the peers are known as TCP allocations. This 404 specification describes only UDP allocations. 406 TURN as defined in this specification only supports IPv4. All IP 407 addresses in this specification must be IPv4 addresses. However, 408 there is a planned extension to TURN to add support for IPv6 and for 409 relaying between IPv4 and IPv6 [I-D.ietf-behave-turn-ipv6]. 411 In some applications for TURN, the client may send and receive 412 packets other than TURN packets on the host transport address it uses 413 to communicate with the server. This can happen, for example, when 414 using TURN with ICE. In these cases, the client can distinguish TURN 415 packets from other packets by examining the source address of the 416 arriving packet: those arriving from the TURN server will be TURN 417 packets. 419 2.2. Allocations 421 To create an allocation on the server, the client uses an Allocate 422 transaction. The client sends a Allocate request to the server, and 423 the server replies with an Allocate success response containing the 424 allocated relayed transport address. The client can include 425 attributes in the Allocate request that describe the type of 426 allocation it desires (e.g., the lifetime of the allocation). Since 427 relaying data may require lots of bandwidth, the server typically 428 requires that the client authenticate itself using STUN's long-term 429 credential mechanism, to show that it is authorized to use the 430 server. 432 Once a relayed transport address is allocated, a client must keep the 433 allocation alive. To do this, the client periodically sends a 434 Refresh request to the server. TURN deliberately uses a different 435 method (Refresh rather than Allocate) for refreshes to ensure that 436 the client is informed if the allocation vanishes for some reason. 438 The frequency of the Refresh transaction is determined by the 439 lifetime of the allocation. The default lifetime of an allocation is 440 10 minutes -- this value was chosen to be long enough so that 441 refreshing is not typically a burden on the client, while expiring 442 allocations where the client has unexpectedly quit in a timely 443 manner. However, the client can request a longer lifetime in the 444 Allocate request and may modify its request in a Refresh request, and 445 the server always indicates the actual lifetime in the response. The 446 client must issue a new Refresh transaction within 'lifetime' seconds 447 of the previous Allocate or Refresh transaction. Once a client no 448 longer wishes to use an Allocation, it should delete the allocation 449 using a Refresh request with a requested lifetime of 0. 451 Both the server and client keep track of a value known as the 452 5-TUPLE. At the client, the 5-tuple consists of the client's host 453 transport address, the server transport address, and the transport 454 protocol used by the client to communicate with the server. At the 455 server, the 5-tuple value is the same except that the client's host 456 transport address is replaced by the client's server-reflexive 457 address, since that is the client's address as seen by the server. 459 Both the client and the server remember the 5-tuple used in the 460 Allocate request. Subsequent messages between the client and the 461 server uses the same 5-tuple. In this way, the client and server 462 know which allocation is being referred to. If the client wishes to 463 allocate a second relayed transport address, it must create a second 464 allocation using a different 5-tuple (e.g., by using a different 465 client host address or port). 467 NOTE: While the terminology used in this document refers to 468 5-tuples, the TURN server can store whatever identifier it likes 469 that yields identical results. Specifically, an implementation 470 may use a file-descriptor in place of a 5-tuple to represent a TCP 471 connection 473 TURN TURN Peer Peer 474 client server A B 475 |-- Allocate request --------------->| | | 476 | | | | 477 |<--------------- Allocate failure --| | | 478 | (401 Unauthorized) | | | 479 | | | | 480 |-- Allocate request --------------->| | | 481 | | | | 482 |<---------- Allocate success resp --| | | 483 | (192.0.2.15:50000) | | | 484 // // // // 485 | | | | 486 |-- Refresh request ---------------->| | | 487 | | | | 488 |<----------- Refresh success resp --| | | 489 | | | | 491 Figure 2 493 In Figure 2, the client sends an Allocate request to the server 494 without credentials. Since the server requires that all requests be 495 authenticated using STUN's long-term credential mechanism, the server 496 rejects the request with a 401 (Unauthorized) error code. The client 497 then tries again, this time including credentials (not shown). This 498 time, the server accepts the Allocate request and returns an Allocate 499 success response containing (amongst other things) the relayed 500 transport address assigned to the allocation. Sometime later the 501 client decides to refresh the allocation and thus sends a Refresh 502 request to the server. The refresh is accepted and the server 503 replies with a Refresh success response. 505 2.3. Permissions 507 To ease concerns amongst enterprise IT administrators that TURN could 508 be used to bypass corporate firewall security, TURN includes the 509 notion of permissions. TURN permissions mimic the address-restricted 510 filtering mechanism of NATs that comply with [RFC4787]. 512 An allocation can have zero or more permissions. Each permission 513 consists of an IP address and a lifetime. When the server receives a 514 UDP datagram on the allocation's relayed transport address, it first 515 checks the list of permissions. If the source IP address of the 516 datagram matches a permission, the application data is relayed to the 517 client, otherwise the UDP datagram is silently discarded. 519 A permission expires after 5 minutes if it is not refreshed, and 520 there is no way to explicitly delete a permission. This behavior was 521 selected to match the behavior of a NAT that complies with [RFC4787]. 523 The client can install or refresh a permission using either a 524 CreatePermission request or a ChannelBind request. Using the 525 CreatePermission request, multiple permissions can be installed or 526 refreshed with a single request -- this is important for applications 527 that use ICE. For security reasons, permissions can only be 528 installed or refreshed by transactions that can be authenticated; 529 thus Send indications and ChannelData messages (which are used to 530 send data to peers) do not install or refresh any permissions. 532 Note that permissions are within the context of an allocation, so 533 adding or expiring a permission in one allocation does not affect 534 other allocations. 536 2.4. Send Mechanism 538 There are two mechanisms for the client and peers to exchange 539 application data using the TURN server. The first mechanism uses the 540 Send and Data methods, the second way uses channels. Common to both 541 ways is the ability of the client to communicate with multiple peers 542 using a single allocated relayed transport address; thus both ways 543 include a means for the client to indicate to the server which peer 544 to forward the data to, and for the server to indicate which peer 545 sent the data. 547 The Send mechanism uses Send and Data indications. Send indications 548 are used to send application data from the client to the server, 549 while Data indications are used to send application data from the 550 server to the client. 552 When using the Send mechanism, the client sends a Send indication to 553 the TURN server containing (a) an XOR-PEER-ADDRESS attribute 554 specifying the (server-reflexive) transport address of the peer and 555 (b) a DATA attribute holding the application data. When the TURN 556 server receives the Send indication, it extracts the application data 557 from the DATA attribute and sends it in a UDP datagram to the peer, 558 using the allocated relay address as the source address. Note that 559 there is no need to specify the relayed transport address, since it 560 is implied by the 5-tuple used for the Send indication. 562 In the reverse direction, UDP datagrams arriving at the relayed 563 transport address on the TURN server are converted into Data 564 indications and sent to the client, with the server-reflexive 565 transport address of the peer included in an XOR-PEER-ADDRESS 566 attribute and the data itself in a DATA attribute. Since the relayed 567 transport address uniquely identified the allocation, the server 568 knows which client to relay the data to. 570 Send and Data indications cannot be authenticated, since the Long- 571 Term Credential Mechanism of STUN does not support authenticating 572 indications. This is not as big an issue as it might first appear, 573 since the client-to-server leg is only half of the total path to the 574 peer; applications that want proper security need to use encryption 575 or similar to protect their data in the UDP datagrams between the 576 server and the peer. However, to prevent attackers from injecting 577 rogue Send indications to arbitrary destinations, TURN requires that 578 a client install a permission to a peer before sending data to it 579 using a Send indication. 581 TURN TURN Peer Peer 582 client server A B 583 | | | | 584 |-- CreatePermission req (Peer A) -->| | | 585 |<-- CreatePermission success resp --| | | 586 | | | | 587 |--- Send ind (Peer A)-------------->| | | 588 | |=== data ===>| | 589 | | | | 590 | |<== data ====| | 591 |<-------------- Data ind (Peer A) --| | | 592 | | | | 593 | | | | 594 |--- Send ind (Peer B)-------------->| | | 595 | | dropped | | 596 | | | | 597 | |<== data ==================| 598 | dropped | | | 599 | | | | 601 Figure 3 603 In Figure 3, the client has already created an allocation and now 604 wishes to send data to its peers. The client first creates a 605 permission by sending the server a CreatePermission request 606 specifying peer A's (server reflexive) IP address in the XOR-PEER- 607 ADDRESS attribute; if this was not done, the server would not relay 608 data between the client and the server. The client then sends data 609 to Peer A using a Send indication; at the server, the application 610 data is extracted and forwarded in a UDP datagram to Peer A, using 611 the relayed transport address as the source transport address. When 612 a UDP datagram from Peer A is received at the relayed transport 613 address, the contents are placed into a Data indication and forwarded 614 to the client. Later, the client attempts to exchange data with Peer 615 B, however no permission has been installed for Peer B, so the Send 616 indication from the client and the UDP datagram from the peer are 617 both dropped by the server. 619 2.5. Channels 621 For some applications (e.g. Voice over IP), the 36 bytes of overhead 622 that a Send indication or Data indication adds to the application 623 data can substantially increase the bandwidth required between the 624 client and the server. To remedy this, TURN offers a second way for 625 the client and server to associate data with a specific peer. 627 This second way uses an alternate packet format known as the 628 ChannelData message. The ChannelData message does not use the STUN 629 header used by other TURN messages, but instead has a 4-byte header 630 that includes a number known as a channel number. Each channel 631 number in use is bound to a specific peer and thus serves as a 632 shorthand for the peer's host transport address. 634 To bind a channel to a peer, the client sends a ChannelBind request 635 to the server, and includes an unbound channel number and the 636 transport address of the peer. Once the channel is bound, the client 637 can use a ChannelData message to send the server data destined for 638 the peer. Similarly, the server can relay data from that peer 639 towards the client using a ChannelData message. 641 Channel bindings last for 10 minutes unless refreshed -- this 642 lifetime was chosen to be longer than the permission lifetime. 643 Channel bindings are refreshed by sending another ChannelBind request 644 rebinding the channel to the peer. Like permissions (but unlike 645 allocations), there is no way to explicitly delete a channel binding; 646 the client must simply wait for it to time out. 647 TURN TURN Peer Peer 648 client server A B 649 | | | | 650 |-- ChannelBind req ---------------->| | | 651 | (Peer A to 0x4001) | | | 652 | | | | 653 |<---------- ChannelBind succ resp --| | | 654 | | | | 655 |-- [0x4001] data ------------------>| | | 656 | |=== data ===>| | 657 | | | | 658 | |<== data ====| | 659 |<------------------ [0x4001] data --| | | 660 | | | | 661 |--- Send ind (Peer A)-------------->| | | 662 | |=== data ===>| | 663 | | | | 664 | |<== data ====| | 665 |<------------------ [0x4001] data --| | | 666 | | | | 668 Figure 4 670 Figure 4 shows the channel mechanism in use. The client has already 671 created an allocation and now wishes to bind a channel to peer A. To 672 do this, the client sends a ChannelBind request to the server, 673 specifying the transport address of Peer A and a channel number 674 (0x4001). After that, the client can send application data 675 encapsulated inside ChannelData messages to Peer A: this is shown as 676 "[0x4001] data" where 0x4001 is the channel number. When the 677 ChannelData message arrives at the server, the server transfers the 678 data to a UDP datagram and sends it to the peer A, as indicated by 679 the channel number. When peer A sends a UDP datagram to the relayed 680 transport address, the data is placed inside a ChannelData message 681 and sent to the client. 683 Once a channel has been bound, the client is free to intermix 684 ChannelData messages and Send indications. In the figure, the client 685 later decides to use a Send indication rather than a ChannelData 686 message to send additional data to peer A. The client might decide to 687 do this, for example, so it can use the DONT-FRAGMENT attribute (see 688 the next section). However, once a channel is bound, the server will 689 always use a ChannelData message, as shown in the call flow. 691 Note that ChannelData messages can only be used for peers to which 692 the client has bound a channel. In the example above, Peer A has 693 been bound to a channel, but Peer B has not, so application data to 694 and from Peer B would use the Send mechanism. 696 2.6. Unprivileged TURN Servers 698 This version of TURN is designed so that the server can be 699 implemented as an application that runs in user space under commonly 700 available operating systems without requiring special privileges. 701 This design decision was taken to make it easy to deploy a TURN 702 server: for example, to allow a TURN server to be integrated into a 703 peer-to-peer application so that one peer can offer NAT traversal 704 services to another peer. 706 This design decision has the following implications for data relayed 707 by a TURN server: 709 o The value of the Diff-Serv field may not be preserved across the 710 server; 712 o The TTL field may be reset, rather than decremented, across the 713 server; 715 o The ECN field may be reset by the server; 717 o ICMP messages are not relayed by the server; 719 o There is no end-to-end fragmentation, since the packet is re- 720 assembled at the server. 722 Future work may specify alternate TURN semantics that address these 723 limitations. 725 2.7. Avoiding IP Fragmentation 727 For reasons described in [Frag-Harmful], applications, especially 728 those sending large volumes of data, should try hard to avoid having 729 their packets fragmented. Applications using TCP can more-or-less 730 ignore this issue because fragmentation avoidance is now a standard 731 part of TCP, but applications using UDP (and thus any application 732 using this version of TURN) must handle fragmentation avoidance 733 themselves. 735 The application running on the client and the peer can take one of 736 two approaches to avoid IP fragmentation. 738 The first approach is to avoid sending large amounts of application 739 data in the TURN messages/UDP datagrams exchanged between the client 740 and the peer. This is the approach taken by most VoIP 741 (Voice-over-IP) applications. In this approach, the application 742 exploits the fact that the IP specification [RFC0791] specifies that 743 IP packets up to 576 bytes should never need to be fragmented. 745 The exact amount of application data that can be included while 746 avoiding fragmentation depends the details of the TURN session 747 between the client and the server: whether UDP, TCP, or TLS transport 748 is used, whether ChannelData messages or Send/Data indications are 749 used, and whether any additional attributes (such as the DONT- 750 FRAGMENT attribute) are included. Another factor, which is hard to 751 determine, is whether the MTU is somewhere along the path is reduced 752 for other reasons, such as the use of IP-in-IP tunneling. 754 As a guideline, sending a maximum of 500 bytes of application data in 755 a single TURN message (by the client on the client-to-server leg) or 756 a UDP datagram (by the peer on the peer-to-server leg) will generally 757 avoid IP fragmentation. To further reduce the chance of 758 fragmentation, it is recommended that the client use ChannelData 759 messages when transferring significant volumes of data, since the 760 overhead of the ChannelData message is less than Send and Data 761 indications. 763 The second approach the client and peer can take to avoid 764 fragmentation is to use a path MTU discovery algorithm to determine 765 the maximum amount of application data than can be sent without 766 fragmentation. 768 Unfortunately, because servers implementing this version of TURN do 769 not relay ICMP messages, the classic Path MTU Discovery algorithm 770 defined in [RFC1191] is not able to discover the MTU of the 771 transmission path between the client and the peer. (Even if they did 772 relay ICMP messages, the algorithm would not always work since ICMP 773 messages are often filtered out by combined NAT/firewall devices). 775 So the client and server need to use a path MTU discovery algorithm 776 that does not require ICMP messages. The Packetized Path MTU 777 Discovery algorithm defined in [RFC4821] is one such algorithm. 779 The details of how to use the algorithm of [RFC4821] with TURN are 780 still under investigation. However, as a step towards this goal, 781 this version of TURN supports a DONT-FRAGMENT attribute. When the 782 client includes this attribute in a Send indication, this tells the 783 server to set the DF bit in the resulting UDP datagram that it sends 784 to the peer. Since some servers may be unable to set the DF bit, the 785 client should also include this attribute in the Allocate request -- 786 any server that does not support the DONT-FRAGMENT attribute will 787 indicate this by rejecting the Allocate request. 789 2.8. RTP Support 791 One of the envisioned uses of TURN is as a relay for clients and 792 peers wishing to exchange real-time data (e.g. voice or video) using 793 RTP. To facilitate the use of TURN for this purpose, TURN includes 794 some special support for older versions of RTP. 796 Old versions of RTP [RFC3550] required that the RTP stream be on an 797 even port number and the associated RTCP stream, if present, be on 798 the next highest port. To allow clients to work with peers that 799 still require this, TURN allows the client to request that the server 800 allocate a relayed-transport-address with an even port number, and to 801 optionally request the server reserve the next-highest port number 802 for a subsequent allocation. 804 2.9. Anycast Discovery of Servers 806 This version of TURN has been designed to permit the future 807 specification of a method of doing anycast discovery of a TURN server 808 over UDP. 810 Specifically, a TURN server can reject an Allocate request with the 811 suggestion that the server try an alternate server. To avoid certain 812 types of attacks, the client must use the same credentials with the 813 alternate server as it would have with the initial server. 815 3. Terminology 817 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 818 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 819 document are to be interpreted as described in RFC 2119 [RFC2119]. 821 Readers are expected to be familiar with [RFC5389] and the terms 822 defined there. 824 The following terms are used in this document: 826 TURN: The protocol spoken between a TURN client and a TURN server. 827 It is an extension to the STUN protocol [RFC5389]. The protocol 828 allows a client to allocate and use a relayed transport address. 830 TURN client: A STUN client that implements this specification. 832 TURN server: A STUN server that implements this specification. It 833 relays data between a TURN client and its peer(s). 835 Peer: A host with which the TURN client wishes to communicate. The 836 TURN server relays traffic between the TURN client and its 837 peer(s). The peer does not interact with the TURN server using 838 the protocol defined in this document; rather, the peer receives 839 data sent by the TURN server and the peer sends data towards the 840 TURN server. 842 Transport Address: The combination of an IP address and a port. 844 Host Transport Address: A transport address on a client or a peer. 846 Server-Reflexive Transport Address: A transport address on the 847 "public side" of a NAT. This address is allocated by the NAT to 848 correspond to a specific host transport address. 850 Relayed Transport Address: A transport address on the TURN server 851 that is used for relaying packets between the client and a peer. 852 A peer sends to this address on the TURN server, and the packet is 853 then relayed to the client. 855 TURN Server Transport Address: A transport address on the TURN 856 server that is used for sending TURN messages to the server. This 857 is the transport address that the client uses to communicate with 858 the server. 860 Peer Transport Address: The transport address of the peer as seen by 861 the server. When the peer is behind a NAT, this is the peer's 862 server-reflexive transport address. 864 Allocation: The relayed transport address granted to a client 865 through an Allocate request, along with related state, such as 866 permissions and expiration timers. 868 5-tuple: The combination (client IP address and port, server IP 869 address and port, and transport protocol (currently one of UDP, 870 TCP, or TLS)) used to communicate between the client and the 871 server. The 5-tuple uniquely identifies this communication 872 stream. The 5-tuple also uniquely identifies the Allocation on 873 the server. 875 Channel: A channel number and associated peer transport address. 876 Once a channel number is bound to a peer's transport address, the 877 client and server can use the more bandwidth-efficient ChannelData 878 message to exchange data. 880 Permission: The IP address and transport protocol (but not the port) 881 of a peer that is permitted to send traffic to the TURN server and 882 have that traffic relayed to the TURN client. The TURN server 883 will only forward traffic to its client from peers that match an 884 existing permission. 886 Realm A string used to describe the server or a context within the 887 server. The realm tells the client which username and password 888 combination to use to authenticate requests. 890 Nonce A string chosen at random by the server and included in the 891 message-digest. To prevent reply attacks, the server should 892 change the nonce regularly. 894 4. General Behavior 896 This section contains general TURN processing rules that apply to all 897 TURN messages. 899 TURN is an extension to STUN. All TURN messages, with the exception 900 of the ChannelData message, are STUN-formatted messages. All the 901 base processing rules described in [RFC5389] apply to STUN-formatted 902 messages. This means that all the message-forming and -processing 903 descriptions in this document are implicitly prefixed with the rules 904 of [RFC5389]. 906 [RFC5389] specifies a Long-Term Credential mechanism for STUN. TURN 907 servers and clients MUST implement this mechanism. The server SHOULD 908 demand that all requests from the client be authenticated using this 909 mechanism, and the client MUST be prepared to authenticate requests 910 if required. 912 In general, it is strongly recommended that servers require 913 requests to be authenticated, as the security of TURN can 914 otherwise be quite weak. One reason that a server might not 915 require requests to be authenticated is that TURN is being used in 916 a carefully controlled environment in which the risks of 917 unauthenticated requests by hostile third-parties have been 918 mitigated. See Section 17 for more discussion on this point. 920 Note that Long-Term Credential mechanism applies only to requests and 921 cannot be used to authenticate indications, thus indications in TURN 922 are never authenticated. If the server requires requests to be 923 authenticated, then the server's administrator MUST choose a realm 924 value that will uniquely identify the username and password 925 combination that the client must use, even if the client uses 926 multiple servers under different administrations. The server's 927 administrator MAY choose to allocate a unique username to each 928 client, or MAY choose to allocate the same username to more than one 929 client (for example, to all clients from the same department or 930 company). For each allocation, the server SHOULD generate a new 931 random nonce when the allocation is first attempted following the 932 randomness recommendations in [RFC4086] and SHOULD expire the nonce 933 at least once every hour during the lifetime of the allocation. 935 All requests after the initial Allocate must use the same username as 936 that used to create the allocation, to prevent attackers from 937 hijacking the client's allocation. Specifically, if the server 938 requires the use of the Long-Term Credential mechanism, and if a non- 939 Allocate request passes authentication under this mechanism, and if 940 the 5-tuple identifies an existing allocation, but the request does 941 not use the same username as used to create the allocation, then the 942 request MUST be rejected with a 441 (Wrong Credentials) error. 944 When a TURN message arrives at the server from the client, the server 945 uses the 5-tuple in the message to identify the associated 946 allocation. For all TURN messages (including ChannelData) EXCEPT an 947 Allocate request, if the 5-tuple does not identify an existing 948 allocation, then the message MUST either be rejected with a 437 949 Allocation Mismatch error (if it is a request), or silently ignored 950 (if it is an indication or a ChannelData message). A client 951 receiving a 437 error response to a request other than Allocate MUST 952 assume the allocation no longer exists. 954 The client SHOULD include the SOFTWARE attribute in all Allocate and 955 Refresh requests and MAY include it in any other requests or 956 indications. The server SHOULD include the SOFTWARE attribute in all 957 Allocate and Refresh responses (either success or failure) and MAY 958 include it in other responses or indications. The client and the 959 server MAY include the FINGERPRINT attribute in any STUN-formatted 960 messages defined in this document. 962 TURN does not use the backwards-compatibility mechanism described in 964 [RFC5389]. 966 By default, TURN runs on the same ports as STUN: 3478 for TURN over 967 UDP and TCP, and 5349 for TURN over TLS. However, TURN has its own 968 set of SRV service names: "turn" for UDP and TCP, and "turns" for 969 TLS. Either the SRV procedures or the ALTERNATE-SERVER procedures, 970 both described in Section 6, can be used to run TURN on a different 971 port. 973 TURN as defined in this specification only supports IPv4. The 974 client's IP address, the server's IP address and all IP addresses 975 appearing in a relayed-transport-address MUST be IPv4 addresses. 977 When UDP transport is used between the client and the server, the 978 client will retransmit a request if it does not receive a response 979 within a certain timeout period. Because of this, the server may 980 receive two (or more) requests with the same 5-tuple and same 981 transaction id. STUN requires that the server recognize this case 982 and treat the request as idempotent (see [RFC5389]). Some 983 implementations may choose to meet this requirement by remembering 984 all received requests and the corresponding responses for 40 seconds. 985 Other implementations may choose to reprocess the request and arrange 986 that such reprocessing returns essentially the same response. To aid 987 implementors who choose the latter approach (the so-called "stateless 988 stack approach"), this specification includes some implementation 989 notes on how this might be done. Implementations are free to choose 990 either approach or choose some other approach that gives the same 991 results. 993 When TCP transport is used between the client and the server, it is 994 possible that a bit error will cause a length field in a TURN packet 995 to become corrupted, causing the receiver to lose synchronization 996 with the incoming stream of TURN messages. A client or server which 997 detects a long sequence of invalid TURN messages over TCP transport 998 SHOULD close the corresponding TCP connection to help the other end 999 detect this situation more rapidly. 1001 To mitigate either intentional or unintentional denial-of-service 1002 attacks against the server by clients with valid usernames and 1003 passwords, it is RECOMMENDED that the server impose limits on both 1004 the number of allocations active at one time for a given username and 1005 on the amount of bandwidth those allocations can use. The server 1006 should reject new allocations that would exceed the limit on the 1007 allowed number of allocations active at one time with a 486 1008 (Allocation Quota Exceeded) (see Section 6.2), and should discard 1009 application data traffic that exceeds the bandwidth quota. 1011 5. Allocations 1013 All TURN operations revolve around allocations, and all TURN messages 1014 are associated with an allocation. An allocation conceptually 1015 consists of the following state data: 1017 o the relayed transport address 1019 o The 5-tuple: (client's IP address, client's port, server IP 1020 address, server port, transport protocol) 1022 o the authentication information 1024 o the time-to-expiry 1026 o A list of permissions 1028 o A list of channel to peer bindings 1030 The relayed transport address is the transport address allocated by 1031 the server for communicating with peers, while the 5-tuple describes 1032 the communication path between the client and the server. On the 1033 client, the 5-tuple uses the client's host transport address, while 1034 on the server the 5-tuple uses the client's server-reflexive 1035 transport address. 1037 Both the relayed-transport-address and the 5-tuple MUST be unique 1038 across all allocations, so either one can be used to uniquely 1039 identify the allocation. 1041 The authentication information (e.g., username, password, realm, and 1042 nonce) are used to both verify subsequent requests and to compute the 1043 message integrity of responses. The username, realm, and nonce 1044 values are initially those used in the authenticated Allocate request 1045 that creates the allocation, though the server can change the nonce 1046 value during the lifetime of the allocation using a 438 (Stale Nonce) 1047 reply. Note that rather than storing the password explicitly, it may 1048 be desirable for security reasons for the server to store the key 1049 value which is an MD5 hash over the username, realm and password (see 1050 [RFC5389]). 1052 The time-to-expiry is the time in seconds left until the allocation 1053 expires. Each Allocate or Refresh transaction sets this timer, which 1054 then ticks down towards 0. By default, each Allocate or Refresh 1055 transaction resets this timer to the default lifetime value of 600 1056 seconds (10 minutes), but the client can request a different value in 1057 the Allocate and Refresh request. Allocations can only be refreshed 1058 using the Refresh request; sending data to a peer does not refresh an 1059 allocation. When an allocation expires, the state data associated 1060 with the allocation can be freed. 1062 The list of permissions is described in Section 8 and the list of 1063 channels is described in Section 11. 1065 6. Creating an Allocation 1067 An allocation on the server is created using an Allocate transaction. 1069 6.1. Sending an Allocate Request 1071 The client forms an Allocate request as follows. 1073 The client first picks a host transport address. It is RECOMMENDED 1074 that the client pick a currently-unused transport address, typically 1075 by allowing the underlying OS to pick a currently-unused port for a 1076 new socket. 1078 The client then picks a transport protocol to use between the client 1079 and the server. The transport protocol MUST be one of UDP, TCP, or 1080 TLS over TCP. Since this specification only allows UDP between the 1081 server and the peers, it is RECOMMENDED that the client pick UDP 1082 unless it has a reason to use a different transport. One reason to 1083 pick a different transport would be that the client believes, either 1084 through configuration or by experiment, that it is unable to contact 1085 any TURN server using UDP. See Section 2.1 for more discussion. 1087 The client also picks a server transport address, which SHOULD be 1088 done as follows. The client receives (perhaps through configuration) 1089 a domain name for a TURN server. The client then uses the DNS 1090 procedures described in [RFC5389], but using an SRV service name of 1091 "turn" (or "turns" for TURN over TLS) instead of "stun" (or "stuns"). 1092 For example, to find servers in the example.com domain, the client 1093 performs a lookup for '_turn._udp.example.com', 1094 '_turn._tcp.example.com', and '_turns._tcp.example.com' if the client 1095 wants to communicate with the server using UDP, TCP, or TLS over TCP, 1096 respectively. 1098 The client MUST include a REQUESTED-TRANSPORT attribute in the 1099 request. This attribute specifies the transport protocol between the 1100 server and the peers (note that this is NOT the transport protocol 1101 that appears in the 5-tuple). In this specification, the REQUESTED- 1102 TRANSPORT type is always UDP. This attribute is included to allow 1103 future extensions specify other protocols. 1105 If the client wishes the server to initialize the time-to-expiry 1106 field of the allocation to some value other the default lifetime, 1107 then it MAY include a LIFETIME attribute specifying its desired 1108 value. This is just a request, and the server may elect to use a 1109 different value. Note that the server will ignore requests to 1110 initialize the field to less than the default value. 1112 If the client wishes to later use the DONT-FRAGMENT attribute in one 1113 or more Send indications on this allocation, then the client SHOULD 1114 include the DONT-FRAGMENT attribute in the Allocate request. This 1115 allows the client to test whether this attribute is supported by the 1116 server. 1118 If the client requires the port number of the relayed-transport 1119 address be even, the client includes the EVEN-PORT attribute. If 1120 this attribute is not included, then the port can be even or odd. By 1121 setting the R bit in the EVEN-PORT attribute to 1, the client can 1122 request that the server reserve the next highest port number (on the 1123 same IP address) for a subsequent allocation. If the R bit is 0, no 1124 such request is made. 1126 The client MAY also include a RESERVATION-TOKEN attribute in the 1127 request to ask the server to use a previously reserved port for the 1128 allocation. If the RESERVATION-TOKEN attribute is included, then the 1129 client MUST omit the EVEN-PORT attribute. 1131 Once constructed, the client sends the Allocate request on the 1132 5-tuple. 1134 6.2. Receiving an Allocate Request 1136 When the server receives an Allocate request, it performs the 1137 following checks: 1139 1. The server SHOULD require that the request be authenticated using 1140 the Long-Term Credential mechanism of [RFC5389]. 1142 2. The server checks if the 5-tuple is currently in use by an 1143 existing allocation. If yes, the server rejects the request with 1144 a 437 (Allocation Mismatch) error. 1146 3. The server checks if the request contain a REQUESTED-TRANSPORT 1147 attribute. If the REQUESTED-TRANSPORT attribute is not included 1148 or is malformed, the server rejects the request with a 400 (Bad 1149 Request) error. Otherwise, if the attribute is included but 1150 specifies a protocol other that UDP, the server rejects the 1151 request with a 442 (Unsupported Transport Protocol) error. 1153 4. The request may contain a DONT-FRAGMENT attribute. If it does, 1154 but the server does not support sending UDP datagrams with the DF 1155 bit set to 1 (see Section 12), then the server treats the DONT- 1156 FRAGMENT attribute in the Allocate request as an unknown 1157 comprehension-required attribute. 1159 5. The server checks if the request contains a RESERVATION-TOKEN 1160 attribute. If yes, and the request also contains a EVEN-PORT 1161 attribute, then the server rejects the request with a 400 (Bad 1162 Request) error. Otherwise it checks to see if the token is valid 1163 (i.e., the token is in range and has not expired, and the 1164 corresponding relayed transport address is still available). If 1165 the token is not valid for some reason, the server rejects the 1166 request with a 508 (Insufficient Port Capacity) error. 1168 6. The server checks if the request contains an EVEN-PORT attribute. 1169 If yes, then the server checks that it can satisfy the request 1170 (i.e., can allocate a relayed-transport-address as described 1171 below). If the server cannot satisfy the request, then the 1172 server rejects the request with a 508 (Insufficient Port 1173 Capacity) error. 1175 7. At any point, the server MAY choose to reject the request with a 1176 486 (Allocation Quota Reached) error if it feels the client is 1177 trying to exceed some locally-defined allocation quota. The 1178 server is free to define this allocation quota any way it wishes, 1179 but SHOULD define it based on the username used to authenticate 1180 the request, and not on the client's transport address. 1182 8. Also at any point, the server MAY choose to reject the request 1183 with a 300 (Try Alternate) error if it wishes to redirect the 1184 client to a different server. The use of this error code and 1185 attribute follow the specification in [RFC5389], with the 1186 modification that a TURN server MAY return this error code and 1187 attribute in unauthenticated error responses as well as in 1188 authenticated error responses. 1190 If all the checks pass, the server creates the allocation. The 1191 5-tuple is set to the 5-tuple from the Allocate request, while the 1192 list of permissions and the list of channels are initially empty. 1194 The server chooses a relayed-transport-address for the allocation as 1195 follows: 1197 o If the request contains a RESERVATION-TOKEN, the server uses the 1198 previously-reserved transport address corresponding to the 1199 included token (if it is still available). Note that the 1200 reservation is a server-wide reservation and is not specific to a 1201 particular allocation, since the Allocate request containing the 1202 RESERVATION-TOKEN uses a different 5-tuple than the Allocate 1203 request that made the reservation. The 5-tuple for the Allocate 1204 request containing the RESERVATION-TOKEN attribute can be any 1205 allowed 5-tuple; it can use a different client IP address and 1206 port, a different transport protocol, and even different server IP 1207 address and port (provided, of course, that the server IP address 1208 and port is one that the server is listening for TURN requests 1209 on). 1211 o If the request contains an EVEN-PORT attribute with the R bit set 1212 to 0, then the server allocates a relayed-transport-address with 1213 an even port number. 1215 o If the request contains an EVEN-PORT attribute with the R bit set 1216 to 1, then the server looks for a pair of port numbers N and N+1 1217 on the same IP address, where N is even. Port N is used in the 1218 current allocation, while the relayed transport address with port 1219 N+1 is assigned a token and reserved for a future allocation. The 1220 server MUST hold this reservation for at least 30 seconds, and MAY 1221 choose to hold longer (e.g. until the allocation with port N 1222 expires). The server then includes the token in a RESERVATION- 1223 TOKEN attribute in the success response. 1225 o Otherwise, the server allocates any available relayed-transport- 1226 address. 1228 In all cases, the server SHOULD only allocate ports from the range 1229 49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]), 1230 unless the TURN server application knows, through some means not 1231 specified here, that other applications running on the same host as 1232 the TURN server application will not be impacted by allocating ports 1233 outside this range. This condition can often be satisfied by running 1234 the TURN server application on a dedicated machine and/or by 1235 arranging that any other applications on the machine allocate ports 1236 before the TURN server application starts. In any case, the TURN 1237 server SHOULD NOT allocate ports in the range 0 - 1023 (the Well- 1238 Known Port range) to discourage clients from using TURN to run 1239 standard services. 1241 NOTE: The IETF is currently investigating the topic of randomized 1242 port assignments to avoid certain types of attacks (see 1243 [I-D.ietf-tsvwg-port-randomization]). It is strongly recommended 1244 that a TURN implementor keep abreast of this topic and, if 1245 appropriate, implement a randomized port assignment algorithm. 1246 This is especially applicable to servers that choose to pre- 1247 allocate a number of ports from the underlying OS and then later 1248 assign them to allocations; for example, a server may choose this 1249 technique to implement the EVEN-PORT attribute. 1251 The server determines the initial value of the time-to-expiry field 1252 as follows. If the request contains a LIFETIME attribute, then the 1253 server computes MIN(client's proposed lifetime, server's maximum 1254 allowed lifetime). If this computed lifetime is greater than the 1255 default lifetime, then the server uses that value. Otherwise, the 1256 server uses the default lifetime. It is RECOMMENDED that the server 1257 use a maximum allowed lifetime value of no more than 3600 seconds (1 1258 hour). Servers that implement allocation quotas or charge users for 1259 allocations in some way may wish to use a smaller maximum allowed 1260 lifetime (perhaps as small as the default lifetime) to more quickly 1261 remove orphaned allocations (that is, allocations where the 1262 corresponding client has crashed or terminated or the client 1263 connection has been lost for some reason). Also note that the time- 1264 to-expiry is recomputed with each successful Refresh request, and 1265 thus the value computed here applies only until the first refresh. 1267 Once the allocation is created, the server replies with a success 1268 response. The success response contains: 1270 o A XOR-RELAYED-ADDRESS attribute containing the relayed transport 1271 address; 1273 o A LIFETIME attribute containing the current value of the time-to- 1274 expiry timer; 1276 o A RESERVATION-TOKEN attribute (if a second relayed transport 1277 address was reserved). 1279 o An XOR-MAPPED-ADDRESS attribute containing the client's IP address 1280 and port (from the 5-tuple). 1282 NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response 1283 as a convenience to the client. TURN itself does not make use of 1284 this value, but clients running ICE can often need this value and 1285 can thus avoid having to do an extra Binding transaction with some 1286 STUN server to learn it. 1288 The response (either success or error) is sent back to the client on 1289 the 5-tuple. 1291 NOTE: Implementations may implement the idempotency of the 1292 Allocate request over UDP using the so-called "stateless stack 1293 approach" as follows. To detect retransmissions when the original 1294 request was successful in creating an allocation, the server can 1295 store the transaction id that created the request with the 1296 allocation data and compare it with incoming Allocate requests on 1297 the same 5-tuple. Once such a request is detected, the server can 1298 stop parsing the request and immediately generate a success 1299 response. When building this response, the value of the LIFETIME 1300 attribute can be taken from the time-to-expiry field in the 1301 allocate state data, even though this value may differ slightly 1302 from the LIFETIME value originally returned. In addition, the 1303 server may need to store an indication of any reservation token 1304 returned in the original response, so that this may be returned in 1305 any retransmitted responses. 1307 For the case where the original request was unsuccessful in 1308 creating an allocation, the server may choose to do nothing 1309 special. Note, however, that there is a rare case where the 1310 server rejects the original request but accepts the retransmitted 1311 request (because conditions have changed in the brief intervening 1312 time period). If the client receives the first failure response, 1313 it will ignore the second (success) response and believe that an 1314 allocation was not created. An allocation created in this matter 1315 will eventually timeout, since the client will not refresh it. 1316 Furthermore, if the client later retries with the same 5-tuple but 1317 different transaction id, it will receive a 437 (Allocation 1318 Mismatch), which will cause it to retry with a different 5-tuple. 1319 The server may use a smaller maximum lifetime value to minimize 1320 the lifetime of allocations "orphaned" in this manner. 1322 6.3. Receiving an Allocate Success Response 1324 If the client receives an Allocate success response, then it MUST 1325 check that the mapped address and the relayed transport address are 1326 in an address family that the client understands and is prepared to 1327 deal with. This specification only covers the case where these two 1328 addresses are IPv4 addresses. If these two addresses are not in an 1329 address family that the client is prepared to deal with, then the 1330 client MUST delete the allocation (Section 7) and MUST NOT attempt to 1331 create another allocation on that server until it believes the 1332 mismatch has been fixed. 1334 The IETF is currently considering mechanisms for transitioning 1335 between IPv4 and IPv6 that could result in a client originating an 1336 Allocate request over IPv6, but the request would arrive at the 1337 server over IPv4, or vica-versa. Hence the importance of this 1338 check. 1340 Otherwise, the client creates its own copy of the allocation data 1341 structure to track what is happening on the server. In particular, 1342 the client needs to remember the actual lifetime received back from 1343 the server, rather than the value sent to the server in the request. 1344 The client must also remember the 5-tuple used for the request and 1345 the username and password it used to authenticate the request to 1346 ensure that it reuses them for subsequent messages. The client also 1347 needs to track the channels and permissions it establishes on the 1348 server. 1350 The client will probably wish to send the relayed transport address 1351 to peers (using some method not specified here) so the peers can 1352 communicate with it. The client may also wish to use the server- 1353 reflexive address it receives in the XOR-MAPPED-ADDRESS attribute in 1354 its ICE processing. 1356 6.4. Receiving an Allocate Error Response 1358 If the client receives an Allocate error response, then the 1359 processing depends on the actual error code returned: 1361 o (Request timed out): There is either a problem with the server, or 1362 a problem reaching the server with the chosen transport. The 1363 client considers the current transaction as having failed but MAY 1364 choose to retry the Allocate request using a different transport 1365 (e.g., TCP instead of UDP). 1367 o 300 (Try Alternate): The server would like the client to use the 1368 server specified in the ALTERNATE-SERVER attribute instead. The 1369 client considers the current transaction as having failed, but 1370 SHOULD try the Allocate request with the alternate server before 1371 trying any other servers (e.g., other servers discovered using the 1372 SRV procedures). When trying the Allocate request with the 1373 alternate server, the client follows the ALTERNATE-SERVER 1374 procedures specified in [RFC5389] with the following changes: the 1375 client SHOULD accept unauthenticated error responses containing 1376 the 300 (Try Alternate) error code, the client MUST ensure that 1377 the realm value received from the alternate server is as expected, 1378 the client MUST use the same transport protocol to the alternate 1379 server as it used to the original server, and the client MUST use 1380 the same username and password as it would have with the original 1381 server. The latter checks protect against an attacker sending the 1382 client an unauthenticated Allocate error response that redirects 1383 the client to some totally different and unexpected server. 1385 o 400 (Bad Request): The server believes the client's request is 1386 malformed for some reason. The client considers the current 1387 transaction as having failed. The client MAY notify the user or 1388 operator and SHOULD NOT retry the request with this server until 1389 it believes the problem has been fixed. 1391 o 401 (Unauthorized): If the client has followed the procedures of 1392 the Long-Term Credential mechanism and still gets this error, then 1393 the server is not accepting the client's credentials. In this 1394 case, the client considers the current transaction as having 1395 failed and SHOULD notify the user or operator. The client SHOULD 1396 NOT send any further requests to this server until it believes the 1397 problem has been fixed. 1399 o 403 (Forbidden): The request is valid, but the server is refusing 1400 to perform it, likely due to administrative restrictions. The 1401 client considers the current transaction as having failed. The 1402 client MAY notify the user or operator and SHOULD NOT retry the 1403 same request with this server until it believes the problem has 1404 been fixed. 1406 o 420 (Unknown Attribute): If the client included a DONT-FRAGMENT 1407 attribute in the request and the server rejected the request with 1408 a 420 error code and listed the DONT-FRAGMENT attribute in the 1409 UNKNOWN-ATTRIBUTES attribute in the error response, then the 1410 client now knows that the server does not support the DONT- 1411 FRAGMENT attribute. The client considers the current transaction 1412 as having failed but MAY choose to retry the Allocate request 1413 without the DONT-FRAGMENT attribute. 1415 o 437 (Allocation Mismatch): This indicates that the client has 1416 picked a 5-tuple which the server sees as already in use. One way 1417 this could happen is if an intervening NAT assigned a mapped 1418 transport address that was used by another client which recently 1419 crashed. The client considers the current transaction as having 1420 failed. The client SHOULD pick another client transport address 1421 and retry the Allocate request (using a different transaction id). 1422 The client SHOULD try three different client transport addresses 1423 before giving up on this server. Once the client gives up on the 1424 server, it SHOULD NOT try to create another allocation on the 1425 server for 2 minutes. 1427 o 438 (Stale Nonce): See the procedures for the Long-Term Credential 1428 mechanism [RFC5389]. 1430 o 441 (Wrong Credentials): The client should not receive this error 1431 in response to a Allocate request. The client MAY notify the user 1432 or operator and SHOULD NOT retry the same request with this server 1433 until it believes the problem has been fixed. 1435 o 442 (Unsupported Transport Address): The client should not receive 1436 this error in response to a request for a UDP allocation. The 1437 client MAY notify the user or operator and SHOULD NOT reattempt 1438 the request with this server until it believes the problem has 1439 been fixed. 1441 o 486 (Allocation Quota Reached): The server is currently unable to 1442 create any more allocations with this username. The client 1443 considers the current transaction as having failed. The client 1444 SHOULD wait at least 1 minute before trying to create any more 1445 allocations on the server. 1447 o 508 (Insufficient Port Capacity): The server has no more relayed 1448 transport addresses available, or has none with the requested 1449 properties, or the one that was reserved is no longer available. 1450 The client considers the current operation as having failed. If 1451 the client is using either the EVEN-PORT or the RESERVATION-TOKEN 1452 attribute, then the client MAY choose to remove or modify this 1453 attribute and try again immediately. Otherwise, the client SHOULD 1454 wait at least 1 minute before trying to create any more 1455 allocations on this server. 1457 An unknown error response MUST be handled as described in [RFC5389]. 1459 7. Refreshing an Allocation 1461 A Refresh transaction can be used to either (a) refresh an existing 1462 allocation and update its time-to-expiry, or (b) delete an existing 1463 allocation. 1465 If a client wishes to continue using an allocation, then the client 1466 MUST refresh it before it expires. It is suggested that the client 1467 refresh the allocation roughly 1 minute before it expires. If a 1468 client no longer wishes to use an allocation, then it SHOULD 1469 explicitly delete the allocation. A client MAY also refresh an 1470 allocation at any time for other reasons. 1472 7.1. Sending a Refresh Request 1474 If the client wishes to immediately delete an existing allocation, it 1475 includes a LIFETIME attribute with a value of 0. All other forms of 1476 the request refresh the allocation. 1478 The Refresh transaction updates the time-to-expiry timer of an 1479 allocation. If the client wishes the server to set the time-to- 1480 expiry timer to something other than the default lifetime, it 1481 includes a LIFETIME attribute with the requested value. The server 1482 then computes a new time-to-expiry value in the same way as it does 1483 for an Allocate transaction, with the exception that a requested 1484 lifetime of 0 causes the server to immediately delete the allocation. 1486 7.2. Receiving a Refresh Request 1488 When the server receives a Refresh request, it processes as per 1489 Section 4 plus the specific rules mentioned here. 1491 The server computes a value called the "desired lifetime" as follows: 1492 If the request contains a LIFETIME attribute and the attribute value 1493 is 0, then the "desired lifetime" is 0. Otherwise, if the request 1494 contains a LIFETIME attribute, then the server computes MIN(client's 1495 requested lifetime, server's maximum allowed lifetime). If this 1496 computed value is greater than the default lifetime, then the 1497 "desired lifetime" is the computed value. Otherwise the "desired 1498 lifetime" is the default lifetime. 1500 Subsequent processing depends on the desired lifetime value: 1502 o If desired lifetime is 0, then the request succeeds and the 1503 allocation is deleted. 1505 o If the desired lifetime is non-zero, then the request succeeds and 1506 the allocation's time-to-expiry is set to the desired lifetime 1508 If the request succeeds, then server sends a success response 1509 containing: 1511 o A LIFETIME attribute containing the current value of the time-to- 1512 expiry timer. 1514 NOTE: A server need not do anything special to implement 1515 idempotency of Refresh requests over UDP using the "stateless 1516 stack approach". Retransmitted Refresh requests with a non-zero 1517 desired lifetime will simply refresh the allocation. A 1518 retransmitted Refresh request with a zero desired lifetime will 1519 cause a 437 (Allocation Mismatch) response if the allocation has 1520 already been deleted, but the client will treat this as equivalent 1521 to a success response (see below). 1523 7.3. Receiving a Refresh Response 1525 If the client receives a success response to its Refresh request with 1526 a non-zero lifetime, it updates its copy of the allocation data 1527 structure with the time-to-expiry value contained in the response. 1529 If the client receives a 437 (Allocation Mismatch) error response to 1530 a request to delete the allocation, then the allocation no longer 1531 exists and it should consider its request as having effectively 1532 succeeded. 1534 8. Permissions 1536 For each allocation, the server keeps a list of zero or more 1537 permissions. Each permission consists of an IP address which 1538 uniquely identifies the permission, and an associated time-to-expiry. 1539 The IP address describes a set of peers that are allowed to send data 1540 to the client, and the time-to-expiry is the number of seconds until 1541 the permission expires. 1543 By sending either CreatePermission requests or ChannelBind requests, 1544 the client can cause the server to install or refresh a permission 1545 for a given IP address. This causes one of two things to happen: 1547 o If no permission for that IP address exists, then a permission is 1548 created with the given IP address and a time-to-expiry equal to 1549 Permission Lifetime. 1551 o If a permission for that IP address already exists, then the time- 1552 to-expiry for that permission is reset to Permission Lifetime. 1554 The Permission Lifetime MUST be 300 seconds (= 5 minutes). 1556 Each permission's time-to-expiry decreases down once per second until 1557 it reaches 0, at which point the permission expires and is deleted. 1559 CreatePermission and ChannelBind requests may be freely intermixed on 1560 a permission. A given permission may be installed or refreshed at 1561 one point in time with a CreatePermission request, and then refreshed 1562 with a ChannelBind request at a different point in time, or vice- 1563 versa. 1565 When a UDP datagram arrives at the relayed transport address for the 1566 allocation, the server checks the list of permissions for that 1567 allocation. If there is a permission with an IP address that is 1568 equal to the source IP address of the UDP datagram, then the UDP 1569 datagram can be relayed to the client. Otherwise, the UDP datagram 1570 is silently discarded. Note that only IP addresses are compared; 1571 port numbers are irrelevant. 1573 The permissions for one allocation are totally unrelated to the 1574 permissions for a different allocation. If an allocation expires, 1575 all its permissions expire with it. 1577 NOTE: Though TURN permissions expire after 5 minutes, many NATs 1578 deployed at the time of publication expire their UDP bindings 1579 considerably faster. Thus an application using TURN will probably 1580 wish to send some sort of keep-alive traffic at a much faster 1581 rate. Applications using ICE should follow the keep-alive 1582 guidelines of ICE [I-D.ietf-mmusic-ice], and applications not 1583 using ICE are advised to do something similar. 1585 9. CreatePermission 1587 TURN supports two ways for the client to install or refresh 1588 permissions on the server. This section describes one way: the 1589 CreatePermission request. 1591 A CreatePermission request may be used in conjunction with either the 1592 Send mechanism in Section 10 or the Channel mechanism in Section 11. 1594 9.1. Forming a CreatePermission request 1596 The client who wishes to install or refresh one or more permissions 1597 can send a CreatePermission request to the server. 1599 When forming a CreatePermission request, the client MUST include at 1600 least one XOR-PEER-ADDRESS attribute, and MAY include more than one 1601 such attribute. The IP address portion of each XOR-PEER-ADDRESS 1602 attribute contains the IP address for which a permission should be 1603 installed or refreshed. The port portion of each XOR-PEER-ADDRESS 1604 attribute will be ignored and can be any arbitrary value. The 1605 various XOR-PEER-ADDRESS attributes can appear in any order. 1607 9.2. Receiving a CreatePermission request 1609 When the server receives the CreatePermission request, it processes 1610 as per Section 4 plus the specific rules mentioned here. 1612 The message is checked for validity. The CreatePermission request 1613 MUST contain at least XOR-PEER-ADDRESS attribute and MAY contain 1614 multiple such attributes. If no such attribute exists, or if any of 1615 these attributes are invalid, then a 400 (Bad Request) error is 1616 returned. If the request is valid, but the server is unable to 1617 satisfy the request due to some capacity limit or similar, then a 508 1618 (Insufficient Capacity) error is returned. 1620 The server MAY impose restrictions on the IP address and port values 1621 allowed in the XOR-PEER-ADDRESS attribute -- if a value is not 1622 allowed, the server rejects the request with a 403 (Forbidden) error. 1624 If the message is valid and the server is capable of carrying out the 1625 request, then the server installs or refreshes a permission for the 1626 IP address contained in each XOR-PEER-ADDRESS attribute as described 1627 in Section 8. The port portion of each attribute is ignored and may 1628 be any arbitrary value. 1630 The server then responds with a CreatePermission success response. 1631 There are no mandatory attributes in the success response. 1633 NOTE: A server need not do anything special to implement 1634 idempotency of CreatePermission requests over UDP using the 1635 "stateless stack approach". Retransmitted CreatePermission 1636 requests will simply refresh the permissions. 1638 9.3. Receiving a CreatePermission response 1640 If the client receives a valid CreatePermission success response, 1641 then the client updates its data structures to indicate that the 1642 permissions have been installed or refreshed. 1644 10. Send and Data Methods 1646 TURN supports two mechanisms for sending and receiving data from 1647 peers. This section describes the use of the Send and Data 1648 mechanism, while Section 11 describes the use of the Channel 1649 mechanism. 1651 10.1. Forming a Send Indication 1653 The client can use a Send indication to pass data to the server for 1654 relaying to a peer. A client may use a Send indication even if a 1655 channel is bound to that peer. However the client MUST ensure that 1656 there is a permission installed for the IP address of the peer to 1657 which the Send indication is being sent; this prevents a third party 1658 from using a TURN server to send data to arbitrary destinations. 1660 When forming a Send indication, the client MUST include a XOR-PEER- 1661 ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS 1662 attribute contains the transport address of the peer to which the 1663 data is to be sent, and the DATA attribute contains the actual 1664 application data to be sent to the peer. 1666 The client MAY include a DONT-FRAGMENT attribute in the Send 1667 indication if it wishes the server to set the DF bit on the UDP 1668 datagram sent to the peer. 1670 10.2. Receiving a Send Indication 1672 When the server receives a Send indication, it processes as per 1673 Section 4 plus the specific rules mentioned here. 1675 The message is first checked for validity. The Send indication MUST 1676 contain both a XOR-PEER-ADDRESS attribute and a DATA attribute. If 1677 one of these attributes is missing or invalid, then the message is 1678 discarded. Note that the DATA attribute is allowed to contain zero 1679 bytes of data. 1681 The Send indication may also contain the DONT-FRAGMENT attribute. If 1682 the server is unable to set the DF bit on outgoing UDP datagrams when 1683 this attribute is present, then the server acts as if the DONT- 1684 FRAGMENT attribute is an unknown comprehension-required attribute 1685 (and thus the Send indication is discarded). 1687 The server also checks that there is a permission installed for the 1688 IP address contained in the XOR-PEER-ADDRESS attribute. If no such 1689 permission exists, the message is discarded. Note that a Send 1690 indication never causes the server to refresh the permission. 1692 The server MAY impose restrictions on the IP address and port values 1693 allowed in the XOR-PEER-ADDRESS attribute -- if a value is not 1694 allowed, the server silently discards the Send indication. 1696 If everything is OK, then the server forms a UDP datagram as follows: 1698 o the source transport address is the relayed transport address of 1699 the allocation, where the allocation is determined by the 5-tuple 1700 on which the Send indication arrived; 1702 o the destination transport address is taken from the XOR-PEER- 1703 ADDRESS attribute; 1705 o the data following the UDP header is the contents of the value 1706 field of the DATA attribute. 1708 The handling of the DONT-FRAGMENT attribute (if present), is 1709 described in Section 12. 1711 The resulting UDP datagram is then sent to the peer. 1713 10.3. Receiving a UDP Datagram 1715 When the server receives a UDP datagram at a currently allocated 1716 relayed transport address, the server looks up the allocation 1717 associated with the relayed transport address. It then checks to see 1718 if relaying is permitted, as described in Section 8. 1720 If relaying is permitted, then the server checks if there is a 1721 channel bound to the peer that sent the UDP datagram (see 1722 Section 11). If a channel is bound, then processing proceeds as 1723 described in Section 11.7. 1725 If relaying is permitted but no channel is bound to the peer, then 1726 the server forms and sends a Data indication. The Data indication 1727 MUST contain both a XOR-PEER-ADDRESS and a DATA attribute. The DATA 1728 attribute is set to the value of the 'data octets' field from the 1729 datagram, and the XOR-PEER-ADDRESS attribute is set to the source 1730 transport address of the received UDP datagram. The Data indication 1731 is then sent on the 5-tuple associated with the allocation. 1733 10.4. Receiving a Data Indication 1735 When the client receives a Data indication, it checks that the Data 1736 indication contains both a XOR-PEER-ADDRESS and a DATA attribute, and 1737 discards the indication if it does not. The client SHOULD also check 1738 that the XOR-PEER-ADDRESS attribute value contains an IP address with 1739 which the client believes there is an active permission, and discard 1740 the Data indication otherwise. Note that the DATA attribute is 1741 allowed to contain zero bytes of data. 1743 NOTE: The latter check protects the client against an attacker who 1744 somehow manages to trick the server into installing permissions 1745 not desired by the client. 1747 If the Data indication passes the above checks, the client delivers 1748 the data octets inside the DATA attribute to the application, along 1749 with an indication that they were received from the peer whose 1750 transport address is given by the XOR-PEER-ADDRESS attribute. 1752 11. Channels 1754 Channels provide a way for the client and server to send application 1755 data using ChannelData messages, which have less overhead than Send 1756 and Data indications. 1758 The ChannelData message (see Section 11.4) starts with a two-byte 1759 field that carries the channel number. The values of this field are 1760 allocated as follows: 1762 0x0000 through 0x3FFF: These values can never be used for channel 1763 numbers. 1765 0x4000 through 0x7FFF: These values are the allowed channel 1766 numbers (16,383 possible values) 1768 0x8000 through 0xFFFF: These values are reserved for future use. 1770 Because of this division, ChannelData messages can be distinguished 1771 from STUN-formatted messages (e.g., Allocate request, Send 1772 indication, etc) by examining the first two bits of the message: 1774 0b00: STUN-formatted message (since the first two bits of a STUN- 1775 formatted message are always zero) 1777 0b01: ChannelData message (since the channel number is the first 1778 field in the ChannelData message and channel numbers fall in the 1779 range 0x4000 - 0x7FFF) 1781 0b10: Reserved 1783 0b11: Reserved 1785 The reserved values may be used in the future to extend the range of 1786 channel numbers. Thus an implementation MUST NOT assume that a TURN 1787 message always starts with a 0 bit. 1789 Channel bindings are always initiated by the client. The client can 1790 bind a channel to a peer at any time during the lifetime of the 1791 allocation. The client may bind a channel to a peer before 1792 exchanging data with it, or after exchanging data with it (using Send 1793 and Data indications) for some time, or may choose never to bind a 1794 channel to it. The client can also bind channels to some peers while 1795 not binding channels to other peers. 1797 Channel bindings are specific to an allocation, so that the use of a 1798 channel number or peer transport address in a channel binding in one 1799 allocation has no impact on their use in a different allocation. If 1800 an allocation expires, all its channel bindings expire with it. 1802 A channel binding consists of: 1804 o A channel number; 1806 o A transport address (of the peer); 1808 o A time-to-expiry timer. 1810 Within the context of an allocation, a channel binding is uniquely 1811 identified either by the channel number or by the peer's transport 1812 address. Thus the same channel cannot be bound to two different 1813 transport addresses, nor can the same transport address be bound to 1814 two different channels. 1816 A channel binding lasts for 10 minutes unless refreshed. Refreshing 1817 the binding (by the server receiving a ChannelBind request rebinding 1818 the channel to the same peer) resets the time-to-expiry timer back to 1819 10 minutes. 1821 When the channel binding expires, the channel becomes unbound. Once 1822 unbound, the channel number can be bound to a different transport 1823 address, and the transport address can be bound to a different 1824 channel number. To prevent race conditions, the client MUST wait 5 1825 minutes after the channel binding expires before attempting to bind 1826 the channel number to a different transport address or the transport 1827 address to a different channel number. 1829 When binding a channel to a peer, the client SHOULD be prepared to 1830 receive ChannelData messages on the channel from the server as soon 1831 as it has sent the ChannelBind request. Over UDP, it is possible for 1832 the client to receive ChannelData messages from the server before it 1833 receives a ChannelBind success response. 1835 In the other direction, the client MAY elect to send ChannelData 1836 messages before receiving the ChannelBind success response. Doing 1837 so, however, runs the risk of having the ChannelData messages dropped 1838 by the server if the ChannelBind request does not succeed for some 1839 reason (e.g., packet lost if the request is sent over UDP, or the 1840 server being unable to fulfill the request). A client that wishes to 1841 be safe should either queue the data, or use Send indications until 1842 the channel binding is confirmed. 1844 11.1. Sending a ChannelBind Request 1846 A channel binding is created or refreshed using a ChannelBind 1847 transaction. A ChannelBind transaction also creates or refreshes a 1848 permission towards the peer (see Section 8). 1850 To initiate the ChannelBind transaction, the client forms a 1851 ChannelBind request. The channel to be bound is specified in a 1852 CHANNEL-NUMBER attribute, and the peer's transport address is 1853 specified in a XOR-PEER-ADDRESS attribute. Section 11.2 describes 1854 the restrictions on these attributes. 1856 Rebinding a channel to the same transport address that it is already 1857 bound to provides a way to refresh a channel binding and the 1858 corresponding permission without sending data to the peer. Note 1859 however, that permissions need to be refreshed more frequently than 1860 channels. 1862 11.2. Receiving a ChannelBind Request 1864 When the server receives a ChannelBind request, it processes as per 1865 Section 4 plus the specific rules mentioned here. 1867 The server checks the following: 1869 o The request contains both a CHANNEL-NUMBER and a XOR-PEER-ADDRESS 1870 attribute; 1872 o The channel number is in the range 0x4000 through 0x7FFE 1873 (inclusive); 1875 o The channel number is not currently bound to a different transport 1876 address (same transport address is OK); 1878 o The transport address is not currently bound to a different 1879 channel number. 1881 If any of these tests fail, the server replies with a 400 (Bad 1882 Request) error. 1884 The server MAY impose restrictions on the IP address and port values 1885 allowed in the XOR-PEER-ADDRESS attribute -- if a value is not 1886 allowed, the server rejects the request with a 403 (Forbidden) error. 1888 If the request is valid, but the server is unable to fulfill the 1889 request due to some capacity limit or similar, the server replies 1890 with a 508 (Insufficient Capacity) error. 1892 Otherwise, the server replies with a ChannelBind success response. 1893 There are no required attributes in a successful ChannelBind 1894 response. 1896 If the server can satisfy the request, then the server creates or 1897 refreshes the channel binding using the channel number in the 1898 CHANNEL-NUMBER attribute and the transport address in the XOR-PEER- 1899 ADDRESS attribute. The server also installs or refreshes a 1900 permission for the IP address in the XOR-PEER-ADDRESS attribute as 1901 described in Section 8. 1903 NOTE: A server need not do anything special to implement 1904 idempotency of ChannelBind requests over UDP using the "stateless 1905 stack approach". Retransmitted ChannelBind requests will simply 1906 refresh the channel binding and the corresponding permission. 1907 Furthermore, the client must wait 5 minutes before binding a 1908 previously bound channel number or peer address to a different 1909 channel, eliminating the possibility that the transaction would 1910 initially fail but succeed on a retransmission. 1912 11.3. Receiving a ChannelBind Response 1914 When the client receives a ChannelBind success response, it updates 1915 its data structures to record that the channel binding is now active. 1916 It also updates its data structures to record that the corresponding 1917 permission has been installed or refreshed. 1919 If the client receives a ChannelBind failure response that indicates 1920 that the channel information is out-of-sync between the client and 1921 the server (e.g., an unexpected 400 "Bad Request" response), then it 1922 is RECOMMENDED that the client immediately delete the allocation and 1923 start afresh with a new allocation. 1925 11.4. The ChannelData Message 1927 The ChannelData message is used to carry application data between the 1928 client and the server. It has the following format: 1930 0 1 2 3 1931 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 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | Channel Number | Length | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | | 1936 / Application Data / 1937 / / 1938 | | 1939 | +-------------------------------+ 1940 | | 1941 +-------------------------------+ 1943 The Channel Number field specifies the number of the channel on which 1944 the data is traveling, and thus the address of the peer that is 1945 sending or is to receive the data. 1947 The Length field specifies the length in bytes of the application 1948 data field (i.e., it does not include the size of the ChannelData 1949 header). Note that 0 is a valid length. 1951 The Application Data field carries the data the client is trying to 1952 send to the peer, or that the peer is sending to the client. 1954 11.5. Sending a ChannelData Message 1956 Once a client has bound a channel to a peer, then when the client has 1957 data to send to that peer it may use either a ChannelData message or 1958 a Send indication; that is, the client is not obligated to use the 1959 channel when it exists and may freely intermix the two message types 1960 when sending data to the peer. The server, on the other hand, MUST 1961 use the ChannelData message if a channel has been bound to the peer. 1963 The fields of the ChannelData message are filled in as described in 1964 Section 11.4. 1966 Over stream transports, the ChannelData message MUST be padded to a 1967 multiple of four bytes in order to ensure the alignment of subsequent 1968 messages. The padding is not reflected in the length field of the 1969 ChannelData message, so the actual size of a ChannelData message 1970 (including padding) is (4 + Length) rounded up to the nearest 1971 multiple of 4. Over UDP, the padding is not required but MAY be 1972 included. 1974 The ChannelData message is then sent on the 5-tuple associated with 1975 the allocation. 1977 11.6. Receiving a ChannelData Message 1979 The receiver of the ChannelData message uses the first two bits to 1980 distinguish it from STUN-formatted messages, as described above. If 1981 the message uses a value in the reserved range (0x8000 through 1982 0xFFFF), then the message is silently discarded. 1984 If the ChannelData message is received in a UDP datagram, and if the 1985 UDP datagram is too short to contain the claimed length of the 1986 ChannelData message (i.e., the UDP header length field value is less 1987 than the ChannelData header length field value + 4 + 8), then the 1988 message is silently discarded. 1990 If the ChannelData message is received over TCP or over TLS over TCP, 1991 then the actual length of the ChannelData message is as described in 1992 Section 11.5. 1994 If the ChannelData message is received on a channel which is not 1995 bound to any peer, then the message is silently discarded. 1997 On the client, it is RECOMMENDED that the client discard the 1998 ChannelData message if the client believes there is no active 1999 permission towards the peer. On the server, the receipt of a 2000 ChannelData message MUST NOT refresh either the channel binding or 2001 the permission towards the peer. 2003 On the server, if no errors are detected, the server relays the 2004 application data to the peer by forming a UDP datagram as follows: 2006 o the source transport address is the relayed transport address of 2007 the allocation, where the allocation is determined by the 5-tuple 2008 on which the ChannelData message arrived; 2010 o the destination transport address is the transport address to 2011 which the channel is bound; 2013 o the data following the UDP header is the contents of the data 2014 field of the ChannelData message. 2016 The resulting UDP datagram is then sent to the peer. Note that if 2017 the Length field in the ChannelData message is 0, then there will be 2018 no data in the UDP datagram, but the UDP datagram is still formed and 2019 sent. 2021 11.7. Relaying Data from the Peer 2023 When the server receives a UDP datagram on the relayed transport 2024 address associated with an allocation, the server processes it as 2025 described in Section 10.3. If that section indicates that a 2026 ChannelData message should be sent (because there is a channel bound 2027 to the peer that sent to UDP datagram), then the server forms and 2028 sends a ChannelData message as described in Section 11.5. 2030 12. IP Header Fields 2032 This section describes how the server sets various fields in the IP 2033 header when relaying between the client and the peer or vica-versa. 2034 The descriptions in this section apply: (a) when the server sends a 2035 UDP datagram to the peer, or (b) when the server sends a Data 2036 indication or ChannelData message to the client over UDP transport. 2037 The descriptions in this section do not apply to TURN messages sent 2038 over TCP or TLS transport from the server to the client. 2040 The descriptions below have two parts: a preferred behavior and an 2041 alternate behavior. The server SHOULD implement the preferred 2042 behavior, but if that is not possible for a particular field, then it 2043 SHOULD implement the alternative behavior. 2045 Time to Live (TTL) field 2047 Preferred Behavior: If the incoming value is 0, then the drop the 2048 incoming packet. Otherwise set the outgoing Time to Live/Hop 2049 Count to one less than the incoming value. 2051 Alternate Behavior: Set the outgoing value to the default for 2052 outgoing packets. 2054 Diff-Serv Code Point (DSCP) field [RFC2474] 2056 Preferred Behavior: Set the outgoing value to the incoming value, 2057 unless the server includes a differentiated services classifier 2058 and marker [RFC2474]. 2060 Alternate Behavior: Set the outgoing value to a fixed value, which 2061 by default is Best Effort unless configured otherwise. 2063 In both cases, if the server is immediately adjacent to a 2064 differentiated services classifier and marker, then DSCP MAY be 2065 set to any arbitrary value in the direction towards the 2066 classifier. 2068 Explicit Congestion Notification (ECN) field [RFC3168] 2070 Preferred Behavior: Set the outgoing value to the incoming value, 2071 UNLESS the server is doing Active Queue Management, the incoming 2072 ECN field is ECT(1) (=0b01) or ECT(0) (=0b10), and the server 2073 wishes to indicate that congestion has been experienced, in which 2074 case set the outgoing value to CE (=0b11). 2076 Alternate Behavior: Set the outgoing value to Not-ECT (=0b00). 2078 IPv4 Fragmentation fields 2080 Preferred Behavior: 2082 When the server sends a packet to a peer in response to a Send 2083 indication containing the DONT-FRAGMENT attribute, then set the 2084 DF bit in the outgoing IP header to 1. In all other cases when 2085 sending an outgoing packet containing application data (e.g., 2086 Data indication, ChannelData message, or DONT-FRAGMENT 2087 attribute not included in the Send indication), copy the DF bit 2088 from the DF bit of the incoming packet that contained the 2089 application data. 2091 Set the other fragmentation fields (Identification, MF, 2092 Fragment Offset) as appropriate for a packet originating from 2093 the server. 2095 Alternate Behavior: As described in the Preferred Behavior, except 2096 always assume the incoming DF bit is 0. 2098 In both the Preferred and Alternate Behaviors, the resulting 2099 packet may be too large for the outgoing link. If this is the 2100 case, then the normal fragmentation rules apply [RFC1122]. 2102 IPv4 Options 2103 Preferred Behavior: The outgoing packet is sent without any IPv4 2104 options. 2106 Alternate Behavior: Same as preferred. 2108 13. New STUN Methods 2110 This section lists the codepoints for the new STUN methods defined in 2111 this specification. See elsewhere in this document for the semantics 2112 of these new methods. 2114 0x003 : Allocate (only request/response semantics defined) 2115 0x004 : Refresh (only request/response semantics defined) 2116 0x006 : Send (only indication semantics defined) 2117 0x007 : Data (only indication semantics defined) 2118 0x008 : CreatePermission (only request/response semantics defined 2119 0x009 : ChannelBind (only request/response semantics defined) 2121 14. New STUN Attributes 2123 This STUN extension defines the following new attributes: 2125 0x000C: CHANNEL-NUMBER 2126 0x000D: LIFETIME 2127 0x0010: Reserved (was BANDWIDTH) 2128 0x0012: XOR-PEER-ADDRESS 2129 0x0013: DATA 2130 0x0016: XOR-RELAYED-ADDRESS 2131 0x0018: EVEN-PORT 2132 0x0019: REQUESTED-TRANSPORT 2133 0x001A: DONT-FRAGMENT 2134 0x0021: Reserved (was TIMER-VAL) 2135 0x0022: RESERVATION-TOKEN 2137 Some of these attributes have lengths that are not multiples of 4. 2138 By the rules of STUN, any attribute whose length is not a multiple of 2139 4 bytes MUST be immediately followed by 1 to 3 padding bytes to 2140 ensure the next attribute (if any) would start on a 4-byte boundary 2141 (see [RFC5389]). 2143 14.1. CHANNEL-NUMBER 2145 The CHANNEL-NUMBER attribute contains the number of the channel. The 2146 value portion of this attribute is 4 bytes long and consists of a 16- 2147 bit unsigned integer, followed by a two-octet RFFU (Reserved For 2148 Future Use) field which MUST be set to 0 on transmission and MUST be 2149 ignored on reception. 2151 0 1 2 3 2152 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 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | Channel Number | RFFU = 0 | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 14.2. LIFETIME 2159 The LIFETIME attribute represents the duration for which the server 2160 will maintain an allocation in the absence of a refresh. The value 2161 portion of this attribute is 4-bytes long and consists of a 32-bit 2162 unsigned integral value representing the number of seconds remaining 2163 until expiration. 2165 14.3. XOR-PEER-ADDRESS 2167 The XOR-PEER-ADDRESS specifies the address and port of the peer as 2168 seen from the TURN server. (In other words, the peer's server- 2169 reflexive transport address if the peer is behind a NAT). It is 2170 encoded in the same way as XOR-MAPPED-ADDRESS [RFC5389]. 2172 14.4. DATA 2174 The DATA attribute is present in all Send and Data indications. The 2175 value portion of this attribute is variable-length and consists of 2176 the application data (that is, the data that would immediately follow 2177 the UDP header if the data was been sent directly between the client 2178 and the peer). If the length of this attribute is not a multiple of 2179 4, then padding must be added after this attribute. 2181 14.5. XOR-RELAYED-ADDRESS 2183 The XOR-RELAYED-ADDRESS is present in Allocate responses. It 2184 specifies the address and port that the server allocated to the 2185 client. It is encoded in the same way as XOR-MAPPED-ADDRESS 2186 [RFC5389]. 2188 14.6. EVEN-PORT 2190 This attribute allows the client to request that the port in the 2191 relayed-transport-address be even, and (optionally) that the server 2192 reserve the next-higher port number. The value portion of this 2193 attribute is 1 byte long. Its format is: 2195 0 2196 0 1 2 3 4 5 6 7 2197 +-+-+-+-+-+-+-+-+ 2198 |R| RFFU | 2199 +-+-+-+-+-+-+-+-+ 2201 The value contains a single 1-bit flag: 2203 R: If 1, the server is requested to reserve the next higher port 2204 number (on the same IP address) for a subsequent allocation. If 2205 0, no such reservation is requested. 2207 The other 7 bits of the attribute's value must be set to zero on 2208 transmission and ignored on reception. 2210 Since the length of this attribute is not a multiple of 4, padding 2211 must immediately follow this attribute. 2213 14.7. REQUESTED-TRANSPORT 2215 This attribute is used by the client to request a specific transport 2216 protocol for the allocated transport address. The value of this 2217 attribute is 4 bytes with the following format: 2218 0 1 2 3 2219 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 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | Protocol | RFFU | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 The Protocol field specifies the desired protocol. The codepoints 2225 used in this field are taken from those allowed in the Protocol field 2226 in the IPv4 header and the NextHeader field in the IPv6 header 2227 [Protocol-Numbers]. This specification only allows the use of 2228 codepoint 17 (User Datagram Protocol). 2230 The RFFU field MUST be set to zero on transmission and MUST be 2231 ignored on reception. It is reserved for future uses. 2233 14.8. DONT-FRAGMENT 2235 This attribute is used by the client to request that the server set 2236 the DF (Don't Fragment) bit in the IP header when relaying the 2237 application data onward to the peer. This attribute has no value 2238 part and thus the attribute length field is 0. 2240 14.9. RESERVATION-TOKEN 2242 The RESERVATION-TOKEN attribute contains a token that uniquely 2243 identifies a relayed transport address being held in reserve by the 2244 server. The server includes this attribute in a success response to 2245 tell the client about the token, and the client includes this 2246 attribute in a subsequent Allocate request to request the server use 2247 that relayed transport address for the allocation. 2249 The attribute value is 8 bytes and contains the token value. 2251 15. New STUN Error Response Codes 2253 This document defines the following new error response codes: 2255 403 (Forbidden): The request was valid, but cannot be performed due 2256 to administrative or similar restrictions. 2258 437 (Allocation Mismatch): A request was received by the server that 2259 requires an allocation to be in place, but there is none, or a 2260 request was received which requires no allocation, but there is 2261 one. 2263 441 (Wrong Credentials): The credentials in the (non-Allocate) 2264 request, though otherwise acceptable to the server, do not match 2265 those used to create the allocation. 2267 442 (Unsupported Transport Protocol): The Allocate request asked the 2268 server to use a transport protocol between the server and the peer 2269 that the server does not support. NOTE: This does NOT refer to 2270 the transport protocol used in the 5-tuple. 2272 486 (Allocation Quota Reached): No more allocations using this 2273 username can be created at the present time. 2275 508 (Insufficient Capacity): The server is unable to carry out the 2276 request due to some capacity limit being reached. In an Allocate 2277 response, this could be due to the server having no more relayed 2278 transport addresses available right now, or having none with the 2279 requested properties, or the one that corresponds to the specified 2280 reservation token is not available. 2282 16. Detailed Example 2284 This section gives a example of the use of TURN, showing in detail 2285 the contents of the messages exchanged. The example uses the network 2286 diagram shown in the Overview (Figure 1). 2288 For each message, the attributes included in the message and their 2289 values are shown. For convenience, values are shown in a human- 2290 readable format rather than showing the actual octets; for example 2291 "XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED- 2292 ADDRESS attribute is included with an address of 192.0.2.15 and a 2293 port of 9000, here the address and port are shown before the xor-ing 2294 is done. For attributes with string-like values (e.g. 2295 SOFTWARE="Example client, version 1.03" and 2296 NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"), the value of the attribute 2297 is shown in quotes for readability, but these quotes do not appear in 2298 the actual value. 2300 TURN TURN Peer Peer 2301 client server A B 2302 | | | | 2303 |--- Allocate request -------------->| | | 2304 | Transaction-Id=0xA56250D3F17ABE679422DE85 | | 2305 | SOFTWARE="Example client, version 1.03" | | 2306 | LIFETIME=3600 (1 hour) | | | 2307 | REQUESTED-TRANSPORT=17 (UDP) | | | 2308 | DONT-FRAGMENT | | | 2309 | | | | 2310 |<-- Allocate error response --------| | | 2311 | Transaction-Id=0xA56250D3F17ABE679422DE85 | | 2312 | SOFTWARE="Example server, version 1.17" | | 2313 | ERROR-CODE=401 (Unauthorized) | | | 2314 | REALM="example.com" | | | 2315 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2316 | | | | 2317 |--- Allocate request -------------->| | | 2318 | Transaction-Id=0xC271E932AD7446A32C234492 | | 2319 | SOFTWARE="Example client 1.03" | | | 2320 | LIFETIME=3600 (1 hour) | | | 2321 | REQUESTED-TRANSPORT=17 (UDP) | | | 2322 | DONT-FRAGMENT | | | 2323 | USERNAME="George" | | | 2324 | REALM="example.com" | | | 2325 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2326 | MESSAGE-INTEGRITY=... | | | 2327 | | | | 2328 |<-- Allocate success response ------| | | 2329 | Transaction-Id=0xC271E932AD7446A32C234492 | | 2330 | SOFTWARE="Example server, version 1.17" | | 2331 | LIFETIME=1200 (20 minutes) | | | 2332 | XOR-RELAYED-ADDRESS=192.0.2.15:50000 | | 2333 | XOR-MAPPED-ADDRESS=192.0.2.1:7000 | | 2334 | MESSAGE-INTEGRITY=... | | | 2336 The client begins by selecting a host transport address to use for 2337 the TURN session; in this example the client has selected 10.1.1.2: 2338 49721 as shown in Figure 1. The client then sends an Allocate 2339 request to the server at the server transport address. The client 2340 randomly selects a 96-bit transaction id of 2341 0xA56250D3F17ABE679422DE85 for this transaction; this is encoded in 2342 the transaction id field in the fixed header. The client includes a 2343 SOFTWARE attribute that gives information about the client's 2344 software; here the value is "Example client, version 1.03" to 2345 indicate that this is version 1.03 of something called the Example 2346 client. The client includes the LIFETIME attribute because it wishes 2347 the allocation to have a longer lifetime than the default of 10 2348 minutes; the value of this attribute is 3600 seconds, which 2349 corresponds to 1 hour. The client must always include a REQUESTED- 2350 TRANSPORT attribute in an Allocate request and the only value allowed 2351 by this specification is 17, which indicates UDP transport between 2352 the server and the peers. The client also includes the DONT-FRAGMENT 2353 attribute because it wishes to use the DONT-FRAGMENT attribute later 2354 in Send indications; this attribute consists of only an attribute 2355 header, there is no value part. We assume the client has not 2356 recently interacted with the server, thus the client does not include 2357 USERNAME, REALM, NONCE, or MESSAGE-INTEGRITY attribute. Finally, 2358 note that the order of attributes in a message is arbitrary (except 2359 for the MESSAGE-INTEGRITY and FINGERPRINT attributes) and the client 2360 could have used a different order. 2362 The server follows the recommended practice in this specification of 2363 requiring all requests to be authenticated. Thus when the server 2364 receives the initial Allocate request, it rejects the request because 2365 the request does not contain the authentication attributes. 2366 Following the procedures of the Long-Term Credential Mechanism of 2367 STUN [RFC5389], the server includes an ERROR-CODE attribute with a 2368 value of 401 (Unauthorized), a REALM attribute that specifies the 2369 authentication realm used by the server (in this case, the server's 2370 domain "example.com"), and a nonce value in a NONCE attribute. The 2371 server also includes a SOFTWARE attribute that gives information 2372 about the server's software. 2374 The client, upon receipt of the 401 error, re-attempts the Allocate 2375 request, this time including the authentication attributes. The 2376 client selects a new transaction id, and then populates the new 2377 Allocate request with the same attributes as before. The client 2378 includes a USERNAME attribute and uses the realm value received from 2379 the server to help it determine which value to use; here the client 2380 is configured to use the username "George" for the realm 2381 "example.com". The client also includes the REALM and NONCE 2382 attributes, which are just copied from the 401 error response. 2383 Finally, the client includes a MESSAGE-INTEGRITY attribute as the 2384 last attribute in the message, whose value is an HMAC-SHA1 hash over 2385 the contents of the message (shown as just "..." above); this HMAC- 2386 SHA1 computation includes a password value, thus an attacker cannot 2387 compute the message integrity value without somehow knowing the 2388 secret password. 2390 The server, upon receipt of the authenticated Allocate request, 2391 checks that everything is OK, then creates an allocation. The server 2392 replies with an Allocate success response. The server includes a 2393 LIFETIME attribute giving the lifetime of the allocation; here, the 2394 server has reduced the client's requested 1 hour lifetime to just 20 2395 minutes, because this particular server doesn't allow lifetimes 2396 longer than 20 minutes. The server includes an XOR-RELAYED-ADDRESS 2397 attribute whose value is the relayed transport address of the 2398 allocation. The server includes an XOR-MAPPED-ADDRESS attribute 2399 whose value is the server-reflexive address of the client; this value 2400 is not used otherwise in TURN but is returned as a convenience to the 2401 client. The server includes a MESSAGE-INTEGRITY attribute to 2402 authenticate the response and to insure its integrity; note that the 2403 response does not contain the USERNAME, REALM, and NONCE attributes. 2404 The server also includes a SOFTWARE attribute. 2406 TURN TURN Peer Peer 2407 client server A B 2408 |--- CreatePermission request ------>| | | 2409 | Transaction-Id=0xE5913A8F460956CA277D3319 | | 2410 | XOR-PEER-ADDRESS=192.0.2.150:0 | | | 2411 | USERNAME="George" | | | 2412 | REALM="example.com" | | | 2413 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2414 | MESSAGE-INTEGRITY=... | | | 2415 | | | | 2416 |<-- CreatePermission success resp.--| | | 2417 | Transaction-Id=0xE5913A8F460956CA277D3319 | | 2418 | MESSAGE-INTEGRITY=... | | | 2420 The client then creates a permission towards peer A in preparation 2421 for sending it some application data. This is done through a 2422 CreatePermission request. The XOR-PEER-ADDRESS attribute contains 2423 the IP address for which a permission is established (the IP address 2424 of peer A); note that the port number in the attribute is ignored 2425 when used in a CreatePermission request, and here it has been set to 2426 0; also note how the client uses Peer A's server-reflexive IP address 2427 and not its (private) host address. The client uses the same 2428 username, realm, and nonce values as in the previous request on the 2429 allocation. Though it is allowed to do so, the client has chosen not 2430 to include a SOFTWARE attribute in this request. 2432 The server receives the CreatePermission request, creates the 2433 corresponding permission, and then replies with a CreatePermission 2434 success response. Like the client, the server chooses not to include 2435 the SOFTWARE attribute in its reply. Again, note how success 2436 responses contain a MESSAGE-INTEGRITY attribute (assuming the server 2437 uses the Long-Term Credential Mechanism), but no USERNAME, REALM, and 2438 NONCE attributes. 2440 TURN TURN Peer Peer 2441 client server A B 2442 |--- Send indication --------------->| | | 2443 | Transaction-Id=0x1278E9ACA2711637EF7D3328 | | 2444 | XOR-PEER-ADDRESS=192.0.2.150:32102 | | 2445 | DONT-FRAGMENT | | | 2446 | DATA=... | | | 2447 | |-- UDP dgm ->| | 2448 | | data=... | | 2449 | | | | 2450 | |<- UDP dgm --| | 2451 | | data=... | | 2452 |<-- Data indication ----------------| | | 2453 | Transaction-Id=0x8231AE8F9242DA9FF287FEFF | | 2454 | XOR-PEER-ADDRSSS=192.0.2.150:32102 | | 2455 | DATA=... | | | 2457 The client now sends application data to Peer A using a Send 2458 indication. Peer A's server-reflexive transport address is specified 2459 in the XOR-PEER-ADDRESS attribute, and the application data (shown 2460 here as just "...") is specified in the DATA attribute. The client 2461 is doing a form of path MTU discovery at the application layer and 2462 thus specifies (by including the DONT-FRAGMENT attribute) that the 2463 server should set the DF bit in the UDP datagram send to the peer. 2464 Indications cannot be authenticated using the Long-Term Credential 2465 Mechanism of STUN, so no MESSAGE-INTEGRITY attribute is included in 2466 the message. An application wishing to ensure that its data is not 2467 altered or forged must integrity-protect its data at the application 2468 level. 2470 Upon receipt of the Send indication, the server extracts the 2471 application data and sends it in a UDP datagram to Peer A, with the 2472 relayed-transport-address as the source transport address of the 2473 datagram, and with the DF bit set as requested. Note that, had the 2474 client not previously established a permission for Peer A's server- 2475 reflexive IP address, then the server would have silently discarded 2476 the Send indication instead. 2478 Peer A then replies with its own UDP datagram containing application 2479 data. The datagram is sent to the relayed-transport-address on the 2480 server. When this arrives, the server creates a Data indication 2481 containing the source of the UDP datagram in the XOR-PEER-ADDRESS 2482 attribute, and the data from the UDP datagram in the DATA attribute. 2483 The resulting Data indication is then sent to the client. 2485 TURN TURN Peer Peer 2486 client server A B 2487 |--- ChannelBind request ----------->| | | 2488 | Transaction-Id=0x6490D3BC175AFF3D84513212 | | 2489 | CHANNEL-NUMBER=0x4000 | | | 2490 | XOR-PEER-ADDRESS=192.0.2.210:49191 | | 2491 | USERNAME="George" | | | 2492 | REALM="example.com" | | | 2493 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2494 | MESSAGE-INTEGRITY=... | | | 2495 | | | | 2496 |<-- ChannelBind success response ---| | | 2497 | Transaction-Id=0x6490D3BC175AFF3D84513212 | | 2498 | MESSAGE-INTEGRITY=... | | | 2500 The client now binds a channel to Peer B, specifying a free channel 2501 number (0x4000) in the CHANNEL-NUMBER attribute, and Peer B's 2502 transport address in the XOR-PEER-ADDRESS attribute. As before, the 2503 client re-uses the username, realm, and nonce from its last request 2504 in the message. 2506 Upon receipt of the request, the server binds the channel number to 2507 the peer, installs a permission for Peer B's IP address, and then 2508 replies with ChannelBind success response. 2510 TURN TURN Peer Peer 2511 client server A B 2512 |--- ChannelData ------------------->| | | 2513 | Channel-number=0x4000 |--- UDP datagram --------->| 2514 | Data=... | Data=... | 2515 | | | | 2516 | |<-- UDP datagram ----------| 2517 | | Data=... | | 2518 |<-- ChannelData --------------------| | | 2519 | Channel-number=0x4000 | | | 2520 | Data=... | | | 2522 The client now sends a ChannelData message to the server with data 2523 destined for Peer B. The ChannelData message is not a STUN message, 2524 and thus has no transaction id. Instead, it has only three fields: a 2525 channel number, data, and data length; here the channel number field 2526 is 0x4000 (the channel the client just bound to Peer B). When the 2527 server receives the ChannelData message, it checks that the channel 2528 is currently bound (which it is) and then sends the data onward to 2529 Peer B in a UDP datagram, using the relayed-transport-address as the 2530 source transport address and 192.0.2.210:49191 (the value of the XOR- 2531 PEER-ADDRESS attribute in the ChannelBind request) as the destination 2532 transport address. 2534 Later, Peer B sends a UDP datagram back to the relayed-transport- 2535 address. This causes the server to send a ChannelData message to the 2536 client containing the data from the UDP datagram. The server knows 2537 which client to send the ChannelData message to because of the 2538 relayed-transport-address the UDP datagram arrived at, and knows to 2539 use channel 0x4000 because this is the channel bound to 192.0.2.210: 2540 49191. Note that if there had not been any channel number bound to 2541 that address, the server would have used a Data indication instead. 2543 TURN TURN Peer Peer 2544 client server A B 2545 |--- Refresh request --------------->| | | 2546 | Transaction-Id=0x0864B3C27ADE9354B4312414 | | 2547 | SOFTWARE="Example client 1.03" | | | 2548 | USERNAME="George" | | | 2549 | REALM="example.com" | | | 2550 | NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | 2551 | MESSAGE-INTEGRITY=... | | | 2552 | | | | 2553 |<-- Refresh error response ---------| | | 2554 | Transaction-Id=0x0864B3C27ADE9354B4312414 | | 2555 | SOFTWARE="Example server, version 1.17" | | 2556 | ERROR-CODE=438 (Stale Nonce) | | | 2557 | REALM="example.com" | | | 2558 | NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | | 2559 | | | | 2560 |--- Refresh request --------------->| | | 2561 | Transaction-Id=0x427BD3E625A85FC731DC4191 | | 2562 | SOFTWARE="Example client 1.03" | | | 2563 | USERNAME="George" | | | 2564 | REALM="example.com" | | | 2565 | NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | | 2566 | MESSAGE-INTEGRITY=... | | | 2567 | | | | 2568 |<-- Refresh success response -------| | | 2569 | Transaction-Id=0x427BD3E625A85FC731DC4191 | | 2570 | SOFTWARE="Example server, version 1.17" | | 2571 | LIFETIME=600 (10 minutes) | | | 2573 Sometime before the 20 minute lifetime is up, the client refreshes 2574 the allocation. This is done using a Refresh request. As before, 2575 the client includes the latest username, realm, and nonce values in 2576 the request. The client also includes the SOFTWARE attribute, 2577 following the recommended practice of always including this attribute 2578 in Allocate and Refresh messages. When the server receives the 2579 Refresh request, it notices that the nonce value has expired, and so 2580 replies with 438 (Stale Nonce) error given a new nonce value. The 2581 client then reattempts the request, this time with the new nonce 2582 value. This second attempt is accepted, and the server replies with 2583 a success response. Note that the client did not include a LIFETIME 2584 attribute in the request, so the server refreshes the allocation for 2585 the default lifetime of 10 minutes (as can be seen by the LIFETIME 2586 attribute in the success response). 2588 17. Security Considerations 2590 This section considers attacks that are possible in a TURN 2591 deployment, and discusses how they are mitigated by mechanisms in the 2592 protocol or recommended practices in the implementation. 2594 Note: Most of the attacks on TURN are mitigated by the server 2595 requiring requests be authenticated using the Long-Term Credential 2596 mechanism of STUN. Thus it is strongly recommended that servers 2597 demand that requests be authenticated. However, in certain 2598 deployments, the use of this mechanism may be unnecessary. An 2599 example might be a deployment where access to the TURN server is 2600 available only through a network where their are fairly tight 2601 controls over what devices can connect to the network (and by whom) 2602 and what software these devices can use. Tightly-run corporate 2603 networks can arguably fall into this category. 2605 17.1. Outsider Attacks 2607 Outsider attacks are ones where the attacker has no credentials in 2608 the system, and is attempting to disrupt the service seen by the 2609 client or the server. 2611 17.1.1. Obtaining Unauthorized Allocations 2613 An attacker might wish to obtain allocations on a TURN server for any 2614 number of nefarious purposes. A TURN server provides a mechanism for 2615 sending and receiving packets while cloaking the actual IP address of 2616 the client. This makes TURN servers an attractive target for 2617 attackers who wish to use it to mask their true identity. 2619 An attacker might also wish to simply utilize the services of a TURN 2620 server without paying for them. Since TURN services require 2621 resources from the provider, it is anticipated that their usage will 2622 come with a cost. 2624 These attacks are prevented using the digest authentication mechanism 2625 which allows the TURN server to determine the identity of the 2626 requestor and whether the requestor is allowed to obtain the 2627 allocation. 2629 17.1.2. Offline Dictionary Attacks 2631 The digest authentication mechanism used by TURN is subject to 2632 offline dictionary attacks. An attacker that is capable of 2633 eavesdropping on a message exchange between a client and server can 2634 determine the password by trying a number of candidate passwords and 2635 seeing if one of them is correct. This attack works when the 2636 passwords are low entropy, such as a word from the dictionary. This 2637 attack can be mitigated by using strong passwords with large entropy. 2638 In situations where even stronger mitigation is required, TLS 2639 transport between the client and the server can be used. 2641 17.1.3. Faked Refreshes and Permissions 2643 An attacker might wish to attack an active allocation by sending it a 2644 Refresh request with an immediate expiration, in order to delete it 2645 and disrupt service to the client. This is prevented by 2646 authentication of refreshes. Similarly, an attacker wishing to send 2647 CreatePermission requests to create permissions to undesirable 2648 destinations is prevented from doing so through authentication. The 2649 motivations for such an attack are described in Section 17.2. 2651 17.1.4. Fake Data 2653 An attacker might wish to send data to the client or the peer, as if 2654 they came from the peer or client respectively. To do that, the 2655 attacker can send the client a faked Data Indication or ChannelData 2656 message, or send the TURN server a faked Send Indication or 2657 ChannelData message. 2659 Indeed, since indications and ChannelData messages are not 2660 authenticated, this attack is not prevented by TURN. However, this 2661 attack is generally present in IP-based communications and is not 2662 substantially worsened by TURN. Consider an normal, non-TURN IP 2663 session between hosts A and B. An attacker can send packets to B as 2664 if they came from A by sending packets towards A with a spoofed IP 2665 address of B. This attack requires the attacker to know the IP 2666 addresses of A and B. With TURN, an attacker wishing to send packets 2667 towards a client using a Data indication needs to know its IP address 2668 (and port), the IP address and port of the TURN server, and the IP 2669 address and port of the peer (for inclusion in the XOR-PEER-ADDRESS 2670 attribute). To send a fake ChannelData message to a client, an 2671 attacker needs to know the IP address and port of the client, the IP 2672 address and port of the TURN server, and the channel number. This 2673 particular combination is mildly more guessable than in the non-TURN 2674 case. 2676 These attacks are more properly mitigated by application layer 2677 authentication techniques. In the case of real time traffic, usage 2678 of SRTP [RFC3711] prevents these attacks. 2680 In some situations, the TURN server may be situated in the network 2681 such that it is able to send to hosts that the client cannot directly 2682 send to. This can happen, for example, if the server is located 2683 behind a firewall that allows packets from outside the firewall to be 2684 delivered to the server, but not to other hosts behind the firewall. 2685 In these situations, an attacker could send the server a Send 2686 indication with an XOR-PEER-ADDRESS attribute containing the 2687 transport address of one of the other hosts behind the firewall. If 2688 the server was to allow relaying of traffic to arbitrary peers, then 2689 this would provide a way for the attacker to attack arbitrary hosts 2690 behind the firewall. 2692 To mitigate this attack, TURN requires that the client establish a 2693 permission to a host before sending it data. Thus an attacker can 2694 only attack hosts that the client is already communicating with, 2695 unless the attacker is able to create authenticated requests. 2696 Furthermore, the server administrator may configure the server to 2697 restrict the range of IP addresses and ports that it will relay data 2698 to. To provide even greater security, the server administrator can 2699 require that the client use TLS for all communication between the 2700 client and the server. 2702 17.1.5. Impersonating a Server 2704 When a client learns a relayed address from a TURN server, it uses 2705 that relayed address in application protocols to receive traffic. 2706 Therefore, an attacker wishing to intercept or redirect that traffic 2707 might try to impersonate a TURN server and provide the client with a 2708 faked relayed address. 2710 This attack is prevented through the digest authentication mechanism, 2711 which provides message integrity for responses in addition to 2712 verifying that they came from the server. Furthermore, an attacker 2713 cannot replay old server responses as the transaction ID in the STUN 2714 header prevents this. Replay attacks are further thwarted through 2715 frequent changes to the nonce value. 2717 17.1.6. Eavesdropping Traffic 2719 TURN concerns itself primarily with authentication and message 2720 integrity. Confidentiality is only a secondary concern, as TURN 2721 control messages do not include information that is particularly 2722 sensitive. The primary protocol content of the messages is the IP 2723 address of the peer. If it is important to prevent an eavesdropper 2724 on a TURN connection from learning this, TURN can be run over TLS. 2726 Confidentiality for the application data relayed by TURN is best 2727 provided by the application protocol itself, since running TURN over 2728 TLS does not protect application data between the server and the 2729 peer. If confidentiality of application data is important, then the 2730 application should encrypt or otherwise protect its data. For 2731 example, for real time media, confidentiality can be provided by 2732 using SRTP. 2734 17.1.7. TURN loop attack 2736 An attacker might attempt to cause data packets to loop indefinitely 2737 between two TURN servers. The attack goes as follows. First, the 2738 attacker sends an Allocate request to server A, using the source 2739 address of server B. Server A will send its response to server B, and 2740 for the attack to succeed, the attacker must have the ability to 2741 either view or guess the contents of this response, so that the 2742 attacker can learn the allocated relayed-transport-address. The 2743 attacker then sends an Allocate request to server B, using the source 2744 address of server A. Again, the attacker must be able to view or 2745 guess the contents of the response, so it can send learn the 2746 allocated relayed-transport-address. Using the same spoofed source 2747 address technique, the attacker then binds a channel number on server 2748 A to the relayed-transport-address on server B, and similarly binds 2749 the same channel number on server B to the relayed-transport-address 2750 on server A. Finally, the attacker sends a ChannelData message to 2751 server A. 2753 The result is a data packet that loops from the relayed-transport- 2754 address on server A to the relayed-transport-address on server B, 2755 then from server B's transport address to server A's transport 2756 address, and then around the loop again. 2758 This attack is mitigated as follows. By requiring all requests to be 2759 authenticated and/or by randomizing the port number allocated for the 2760 relayed-transport-address, the server forces the attacker to either 2761 intercept or view responses sent to a third party (in this case, the 2762 other server) so that the attacker can authenticate the requests and 2763 learn the relayed-transport-address. Without one of these two 2764 measures, an attacker can guess the contents of the responses without 2765 needing to see them, which makes the attack much easier to perform. 2766 Furthermore, by requiring authenticated requests, the server forces 2767 the attacker to have credentials acceptable to the server, which 2768 turns this from an outsider attack into an insider attack and allows 2769 the attack to be traced back to the client initiating it. 2771 The attack can be further mitigated by imposing a per-username limit 2772 on the bandwidth used to relay data by allocations owned by that 2773 username, to limit the impact of this attack on other allocations. 2775 More mitigation can be achieved by decrementing the TTL when relaying 2776 data packets (if the underlying OS allows this). 2778 17.2. Firewall Considerations 2780 A key aspect of TURN's security considerations is that it should not 2781 weaken the protections afforded by firewalls deployed between a 2782 client and a TURN server. It is anticipated that TURN servers will 2783 often be present on the public Internet, and clients may often be 2784 inside enterprise networks with corporate firewalls. If TURN servers 2785 provide a 'backdoor' for reaching into the enterprise, TURN will be 2786 blocked by these firewalls. 2788 TURN servers therefore emulate the behavior of NAT devices which 2789 implement address-dependent filtering [RFC4787], a property common in 2790 many firewalls as well. When a NAT or firewall implements this 2791 behavior, packets from an outside IP address are only allowed to be 2792 sent to an internal IP address and port if the internal IP address 2793 and port had recently sent a packet to that outside IP address. TURN 2794 servers introduce the concept of permissions, which provide exactly 2795 this same behavior on the TURN server. An attacker cannot send a 2796 packet to a TURN server and expect it to be relayed towards the 2797 client, unless the client has tried to contact the attacker first. 2799 It is important to note that some firewalls have policies which are 2800 even more restrictive than address-dependent filtering. Firewalls 2801 can also be configured with address and port dependent filtering, or 2802 can be configured to disallow inbound traffic entirely. In these 2803 cases, if a client is allowed to connect the TURN server, 2804 communications to the client will be less restrictive than what the 2805 firewall would normally allow. 2807 17.2.1. Faked Permissions 2809 In firewalls and NAT devices, permissions are granted implicitly 2810 through the traversal of a packet from the inside of the network 2811 towards the outside peer. Thus, a permission cannot, by definition, 2812 be created by any entity except one inside the firewall or NAT. With 2813 TURN, this restriction no longer holds. Since the TURN server sits 2814 outside the firewall, at attacker outside the firewall can now send a 2815 message to the TURN server and try to create a permission for itself. 2817 This attack is prevented because all messages which create 2818 permissions (i.e., ChannelBind and CreatePermission) are 2819 authenticated. 2821 17.2.2. Blacklisted IP Addresses 2823 Many firewalls can be configured with blacklists which prevent a 2824 client behind the firewall from sending packets to, or receiving 2825 packets from, ranges of blacklisted IP addresses. This is 2826 accomplished by inspecting the source and destination addresses of 2827 packets entering and exiting the firewall, respectively. 2829 If a client connects to a TURN server, it will be able to bypass such 2830 blacklisting policies and communicate with IP addresses which the 2831 firewall would otherwise restrict. This is a problem for other 2832 protocols that provide tunneling functions, such as VPNs. It is 2833 possible to build TURN-aware firewalls which inspect TURN messages, 2834 and check the IP address of the correspondent. TURN messages to 2835 offending destinations can then be rejected. TURN is designed so 2836 that this inspection can be done statelessly. 2838 17.2.3. Running Servers on Well-Known Ports 2840 A malicious client behind a firewall might try to connect to a TURN 2841 server and obtain an allocation which it then uses to run a server. 2842 For example, a client might try to run a DNS server or FTP server. 2844 This is not possible in TURN. A TURN server will never accept 2845 traffic from a peer for which the client has not installed a 2846 permission. Thus, peers cannot just connect to the allocated port in 2847 order to obtain the service. 2849 17.3. Insider Attacks 2851 In insider attacks, a client has legitimate credentials but defies 2852 the trust relationship that goes with those credentials. These 2853 attacks cannot be prevented by cryptographic means but need to be 2854 considered in the design of the protocol. 2856 17.3.1. DoS Against TURN Server 2858 A client wishing to disrupt service to other clients might obtain an 2859 allocation and then flood it with traffic, in an attempt to swamp the 2860 server and prevent it from servicing other legitimate clients. This 2861 is mitigated by the recommendation that the server limit the amount 2862 of bandwidth it will relay for a given username. This won't prevent 2863 a client from sending a large amount of traffic, but it allows the 2864 server to immediately discard traffic in excess. 2866 Since each allocation uses a port number on the IP address of the 2867 TURN server, the number of allocations on a server is finite. An 2868 attacker might attempt to consume all of them by requesting a large 2869 number of allocations. This is prevented by the recommendation that 2870 the server impose a limit of the number of allocations active at a 2871 time for a given username. 2873 17.3.2. Anonymous Relaying of Malicious Traffic 2875 TURN servers provide a degree of anonymization. A client can send 2876 data to correspondent peers without revealing their own IP addresses. 2877 TURN servers may therefore become attractive vehicles for attackers 2878 to launch attacks against targets without fear of detection. Indeed, 2879 it is possible for a client to chain together multiple TURN servers, 2880 such that any number of relays can be used before a target receives a 2881 packet. 2883 Administrators who are worried about this attack can maintain logs 2884 which capture the actual source IP and port of the client, and 2885 perhaps even every permission that client installs. This will allow 2886 for forensic tracing to determine the original source, should it be 2887 discovered that an attack is being relayed through a TURN server. 2889 17.3.3. Manipulating other Allocations 2891 An attacker might attempt to disrupt service to other users of the 2892 TURN server by sending Refresh requests or CreatePermission requests 2893 which (through source address spoofing) appear to be coming from 2894 another user of the TURN server. TURN prevents this by requiring 2895 that the credentials used in CreatePermission, Refresh, and 2896 ChannelBind messages match those used to create the initial 2897 allocation. Thus, the fake requests from the attacker will be 2898 rejected. 2900 17.4. Other Considerations 2902 Any relay addresses learned through an Allocate request will not 2903 operate properly with IPSec Authentication Header (AH) [RFC4302] in 2904 transport or tunnel mode. However, tunnel-mode IPSec ESP [RFC4303] 2905 should still operate. 2907 18. IANA Considerations 2909 Since TURN is an extension to STUN [RFC5389], the methods, attributes 2910 and error codes defined in this specification are new methods, 2911 attributes, and error codes for STUN. This section requests IANA to 2912 add these new protocol elements to the IANA registry of STUN protocol 2913 elements. 2915 The codepoints for the new STUN methods defined in this specification 2916 are listed in Section 13. 2918 The codepoints for the new STUN attributes defined in this 2919 specification are listed in Section 14. 2921 The codepoints for the new STUN error codes defined in this 2922 specification are listed in Section 15. 2924 IANA is requested to allocate the SRV service name of "turn" for TURN 2925 over UDP or TCP, and the service name of "turns" for TURN over TLS. 2927 IANA is requested to create a registry for TURN channel numbers, 2928 initially populated as follows: 2930 0x0000 through 0x3FFF: Not available for use, since they conflict 2931 with the STUN header. 2933 0x4000 through 0x7FFF: A TURN implementation is free to use 2934 channel numbers in this range. 2936 0x8000 through 0xFFFF: Reserved. 2938 Any change to this registry must be made through an IETF Standards 2939 Action. 2941 19. IAB Considerations 2943 The IAB has studied the problem of "Unilateral Self Address Fixing", 2944 which is the general process by which a client attempts to determine 2945 its address in another realm on the other side of a NAT through a 2946 collaborative protocol reflection mechanism [RFC3424]. The TURN 2947 extension is an example of a protocol that performs this type of 2948 function. The IAB has mandated that any protocols developed for this 2949 purpose document a specific set of considerations. These 2950 considerations and the responses for TURN are documented in this 2951 section. 2953 Consideration 1: Precise definition of a specific, limited-scope 2954 problem that is to be solved with the UNSAF proposal. A short term 2955 fix should not be generalized to solve other problems. Such 2956 generalizations lead to the prolonged dependence on and usage of the 2957 supposed short term fix -- meaning that it is no longer accurate to 2958 call it "short term". 2960 Response: TURN is a protocol for communication between a relay (= 2961 TURN server) and its client. The protocol allows a client that is 2962 behind a NAT to obtain and use a public IP address on the relay. As 2963 a convenience to the client, TURN also allows the client to determine 2964 its server-reflexive transport address. 2966 Consideration 2: Description of an exit strategy/transition plan. 2967 The better short term fixes are the ones that will naturally see less 2968 and less use as the appropriate technology is deployed. 2970 Response: TURN will no longer be needed once there are no longer any 2971 NATs. Unfortunately, as of the date of publication of this document, 2972 it no longer seems very likely that NATs will go away any time soon. 2973 However, the need for TURN will also decrease as the number of NATs 2974 with the mapping property of Endpoint-Independent Mapping [RFC4787] 2975 increases. 2977 Consideration 3: Discussion of specific issues that may render 2978 systems more "brittle". For example, approaches that involve using 2979 data at multiple network layers create more dependencies, increase 2980 debugging challenges, and make it harder to transition. 2982 Response: TURN is "brittle" in that it requires the NAT bindings 2983 between the client and the server to be maintained unchanged for the 2984 lifetime of the allocation. This is typically done using keep- 2985 alives. If this is not done, then the client will lose its 2986 allocation and can no longer exchange data with its peers. 2988 Consideration 4: Identify requirements for longer term, sound 2989 technical solutions; contribute to the process of finding the right 2990 longer term solution. 2992 Response: The need for TURN will be reduced once NATs implement the 2993 recommendations for NAT UDP behavior documented in [RFC4787]. 2994 Applications are also strongly urged to use ICE [I-D.ietf-mmusic-ice] 2995 to communicate with peers; though ICE uses TURN, it does so only as a 2996 last resort, and uses it in a controlled manner. 2998 Consideration 5: Discussion of the impact of the noted practical 2999 issues with existing deployed NATs and experience reports. 3001 Response: Some NATs deployed today exhibit a mapping behavior other 3002 than Endpoint-Independent mapping. These NATs are difficult to work 3003 with, as they make it difficult or impossible for protocols like ICE 3004 to use server-reflexive transport addresses on those NATs. A client 3005 behind such a NAT is often forced to use a relay protocol like TURN 3006 because "UDP hole punching" techniques [RFC5128] do not work. 3008 20. Open Issues 3010 Note to RFC Editor: Please remove this section prior to publication 3011 of this document as an RFC. 3013 This section lists the known issues in this version of the 3014 specification. 3016 (No known issues at this time). 3018 21. Changes from Previous Versions 3020 Note to RFC Editor: Please remove this section prior to publication 3021 of this document as an RFC. 3023 This section lists the technical and major editorial changes between 3024 the various versions of this specification. Minor editorial changes 3025 are not described. 3027 21.1. Changes from -14 to -15 3029 o Added text saying that TURN servers and client MUST implement the 3030 Long-Term Credential Mechanism. Added text strongly recommending 3031 that servers require that all requests be authenticated. Noted a 3032 few cases where not using the Long-Term Credential Mechanism might 3033 be acceptable. 3035 o Added text to section Section 6.4 saying that unknown error 3036 responses must be handled as per [RFC5389]. 3038 o Added text clarifying the exact length of each attribute and 3039 reminding the reader that certain attributes must be immediately 3040 followed by 1 to 3 padding bytes. 3042 o Added a sentence to the acknowledgment section thanking Marc 3043 Petit-Huginen for his efforts in implementing many previous 3044 versions of the specification. 3046 o Fixed a number of minor document errors. 3048 21.2. Changes from -13 to -14 3050 o Reworded the text in Section 6.2 and Section 7.2 to more clearly 3051 describe how the allocation lifetime is computed in the case where 3052 a client requests a lifetime that is greater than both the default 3053 lifetime and the server's maximum allowed lifetime. 3055 o In Section 8, changed the term "default permission lifetime" to 3056 "Permission Lifetime" to make it clearer that the lifetime of a 3057 permission is not configurable. 3059 o In Section 6.2, swapped the steps that check the RESERVATION-TOKEN 3060 and EVEN-PORT attributes to correctly handle the case where an 3061 Allocate request contains both attributes. The new text correctly 3062 returns 400 Bad Request in this case. 3064 o Added text in the Overview section to describe why various timer 3065 values were chosen. 3067 o Added a sentence to the IAB consideration section saying that the 3068 disappearance of NATs in the near-term seems unlikely. 3070 o The former "Other Features" section of the Overview has been 3071 replaced with a series of sections describing various secondary 3072 features of TURN, and the text describing and motivating these 3073 secondary features has been expanded. As a part of this rewrite, 3074 there is now a section that describes how to avoid IP 3075 fragmentation when using TURN. 3077 o Added some additional text in the Overview to explain how a client 3078 would select between UDP, TCP, and TLS transport. 3080 o Fixed various minor typos. 3082 21.3. Changes from -12 to -13 3084 o Added a new error code: 403 (Forbidden). 3086 o When processing a CreatePermission or ChannelBind request 3087 containing a XOR-PEER-ADDRESS attribute, the server is allow to 3088 reject certain IP address and port combinations for administrative 3089 or other reasons by returning a 403 (Forbidden) error. 3091 o Added a request to IANA to establish a registery for channel 3092 numbers. 3094 o Clarified the usage of the nonce value: a new random nonce SHOULD 3095 be selected for each Allocate attempt, and the nonce SHOULD be 3096 expired at least once an hour. Referenced [RFC4086] for 3097 guidelines on selecting the nonce value. 3099 o Made a number of minor editoral changes. 3101 21.4. Changes from -11 to -12 3103 o Changed the port numbers used in the examples for the client, the 3104 peers, and the relayed-transport-address to put them in the 3105 Dynamic port range. They were previously in the Registered port 3106 range, which was arguably unrealistic. 3108 o Noted that the XOR-MAPPED-ADDRESS attribute is defined in RFC 3109 5389. 3111 o Used the codepoint names (Not-ECT, ECT(0), ECT(1), and CE) when 3112 talking about the ECN field. 3114 o Updated the Introduction to note that the client must not only 3115 communicate its relayed-transport-address to the peers, but also 3116 learn the peers' server-reflexive transport addresses. As a 3117 result, removed the suggestion that the client could use a webpage 3118 to communicate with its peers. 3120 o Added a description of the "TURN Loop attack" and its mitigation 3121 to the Security Considerations section. 3123 o Fixed some errors in the examples in the Overview section. They 3124 had not been updated to be consistent with the change introduced 3125 in version -11 that a permission must be created before a client 3126 can send data to a peer. 3128 o In the Additional Features subsection of the Overview, reworded 3129 the discussion of what end-to-end features are preserved by TURN. 3130 The previous text said that a number of features did not work, but 3131 as of version -11, these features _may_ work. At the same time, 3132 added a sentence noting that any Path MTU Discovery mechanism 3133 using the DONT-FRAGMENT attribute will not receive ICMP messages 3134 and will thus have to use techniques like those described in 3135 [RFC4821]. 3137 o Added the recommendation that, when TCP transport is used between 3138 the client and the server, both ends should close the connection 3139 if they notice a long sequence of invalid TURN messages. A likely 3140 cause of this is an undetected bit error corrupting a length field 3141 somewhere. 3143 o Reworded the paragraph explaining that channel bindings are per- 3144 allocation to further stress this point. 3146 o In the discussion on setting the fragmentation fields, added a 3147 sentence saying that the client or server should follow the normal 3148 rules for fragmentation as described in [RFC1122]. 3150 21.5. Changes from -10 to -11 3152 o Clarified that, when the client is redirected to an alternate 3153 server, the client uses the same transport protocol to the 3154 alternate server as it did to the original server. 3156 o Clarified the information that the server needs to store to 3157 authenticate requests and to compute the message-integrity on 3158 responses. Noted that the server need not store the password 3159 explicitly, but can instead store the key value, which may be 3160 desirable for security reasons. 3162 o Clarified that TURN runs on the same ports as TURN by default, but 3163 noted that a server can use a different port because TURN has its 3164 own SRV service names. Strengthened the language for using the 3165 SRV procedures from "typically" to "SHOULD". Also added a 3166 sentence in the IANA considerations section requesting that IANA 3167 reserve the service names for TURN; previously they were described 3168 in the text but not mentioned in the IANA considerations section. 3170 o Added a detailed example, complete with attributes and their 3171 values, of the use of TURN. 3173 o Reduced the range of channel numbers. Channel numbers now range 3174 from 0x4000 through 0x7FFF. Values in the range 0x8000 through 3175 0xFFFF are now reserved. 3177 o Rewrote the IAB Considerations section to directly address the 3178 considerations listed in [RFC3424]. 3180 o Generalized the 508 error code so it can be used for any sort of 3181 capacity-related problem. This error code was previously allowed 3182 only in Allocate responses, but is now also allowed in 3183 CreatePermission and ChannelBind responses to indicate that the 3184 server is unable to carry out the request due to some capacity 3185 problem. 3187 o Changed the syntax of the CreatePermission request to allow 3188 multiple XOR-PEER-ADDRESS attributes to appear in the message, so 3189 that multiple permissions can be created or refreshed at the same 3190 time. 3192 o Added the restriction that the server must already have a 3193 permission installed for the IP address in the XOR-PEER-ADDRESS 3194 attribute of a Send indication, otherwise the Send indication is 3195 ignored by the server. 3197 o Put back the preferred behaviors into Section 12, reversing the 3198 change made in version -10. 3200 o Explicitly allow the server to restrict the range of IP addresses 3201 and ports it is willing to relay data too. 3203 21.6. Changes from -09 to -10 3205 o Changed the recommendation for using the SOFTWARE attribute. 3206 Previously its use was recommended in all requests and responses; 3207 now it is only recommended in Allocate and Refresh requests and 3208 responses, though it may appear elsewhere. Also, version -09 3209 incorrectly referred to this attribute as "SOFTWARE-TYPE". 3211 o Changed the name of the PEER-ADDRESS and RELAYED-ADDRESS 3212 attributes to XOR-PEER-ADDRESS and XOR-RELAYED-ADDRESS 3213 respectively for consistency with other specifications. 3215 o Removed the concept of a "preserving" allocation. All allocations 3216 are now non-preserving. This simplifies the base specification 3217 and allows it to advance more rapidly; see the discussion in the 3218 BEHAVE meeting of 29 July 2008. The concept of a preserving 3219 allocation will be advanced as an extension to TURN. As part of 3220 this change, the P bit in the REQUESTED-PROPS attribute, the ICMP 3221 attribute, and ICMP message relaying was removed. Further, in 3222 Section 12, the preferred behaviors were removed, leaving the 3223 alternate behaviors as the specified behaviors. 3225 o Replaced the REQUESTED-PROPS attribute with the EVEN-PORT 3226 attribute. The new attribute lacks the feature of the old 3227 attribute of being an alternate way to specify new allocation 3228 properties. As a consequence, the only way to specify a new 3229 allocation property is to define a new attribute. 3231 o Added text recommending that the client check that the IP address 3232 in XOR-PEER-ADDRESS attribute in a received Data indication is one 3233 with which the client believes there is an active permission. 3234 Similarly, it is recommended that the client check that a 3235 permission exist when receiving a ChannelData message. 3237 o Added text recommending that the client delete the allocation if 3238 it receives a ChannelBind failure response on an unbound channel. 3240 o Added the CreatePermission request/response transaction which adds 3241 or updates permissions, and removed the ability for Send 3242 indications and ChannelBind messages to install or update 3243 permissions. The net effect is that only authenticate-able 3244 messages (i.e., CreatePermission requests and ChannelBind 3245 requests) can install or refresh permissions; unauthenticate-able 3246 Send indications and ChannelData messages do not. 3248 o Removed all support for IPv6. All IPv6 support, including ways of 3249 relaying between IPv4 and IPv6, will now be covered in 3250 [I-D.ietf-behave-turn-ipv6]. 3252 o Reserved attribute code point 0x0021. This was previously used 3253 for the TIMER-VAL attribute, which was removed when the 3254 SetActiveDestination feature was removed. 3256 o Added the DONT-FRAGMENT attribute which allows the client to 3257 request that the server set the DF bit when sending the UDP 3258 datagram to the peer. This attribute may appear in both Allocate 3259 requests and Send indications. 3261 o Changed how the ALTERNATE-SERVER attribute is used. The attribute 3262 can no longer be used with any error code, but must be used with 3263 300 (Try Alternative). It can now appear in unauthenticated 3264 responses, however there are restrictions around how the 3265 subsequent Allocate request is authenticated. 3267 o Reworked the details of how idempotency of requests is handled, 3268 making it clear that the stack can either remember all 3269 transactions for 40 seconds, or can handle this using the so- 3270 called "stateless stack approach". Made some changes to the 3271 semantics of the Allocate, Refresh, and ChannelBind requests as a 3272 consequence. 3274 o Added the requirement that a client cannot re-use previously bound 3275 channel number or transport address until 5 minutes after the 3276 channel binding expires. This avoids various race conditions. 3278 o Removed the requirement that an allocation cannot be re-used 3279 within 2 minutes of having been deleted. This requirement was put 3280 in place to prevent mis-delivered packets but is no longer seen as 3281 having any real value. 3283 o Added a recommendation that the server impose quotas on both the 3284 number of allocations and the amount of bandwidth a given username 3285 can use at one time. These quotas help protect against denial-of- 3286 service attacks. 3288 o Completely rewrote the security considerations section. 3290 o Made quite a few changes to the descriptive text in both the 3291 Overview and the normative text to try to further clarify 3292 concepts. 3294 21.7. Changes from -08 to -09 3296 o Added text to properly define the ICMP attribute. This attribute 3297 was introduced in TURN-08, but not fully defined due to an 3298 oversight. Clarified that the attribute can appear in a Data 3299 indication, but not a Send indication. Added text to the section 3300 on receiving a Data indication that points out that this attribute 3301 may be present. 3303 o Changed the wording around the handling of the DSCP field to allow 3304 the server to set the DSCP to an arbitrary value if the next hop 3305 is a Diff-Serv classifier and marker. 3307 o When the server generates a 508 response due to an unsupported 3308 flag in the REQUESTED-PROPS attribute, the server now includes the 3309 REQUESTED-PROPS attribute in the response with all the flags it 3310 supports set to 1. This allows the client to see if the server 3311 does not understand one of its flags. Similarly, the client is 3312 now allowed to immediately retry the request if it modifies the 3313 included REQUESTED-PROPS attribute. 3315 o Clarified that the REQUESTED-PROPS attribute can be used in 3316 conjunction with the RESERVATION-TOKEN attribute as long as both 3317 the E and R bits are 0. The spec previously contradicted itself 3318 on this point. 3320 o Clarified that when the server receives a ChannelData message with 3321 a length field of 0, it sends a UDP Datagram to the peer that 3322 contains no application data. 3324 o Rewrote some text around relaying incoming UDP Datagrams to avoid 3325 duplication of text in the Data indication and Channel sections. 3327 o Added a note that points out that the on-going work on randomizing 3328 port allocations [I-D.ietf-tsvwg-port-randomization] may be 3329 applicable to TURN. 3331 o Clarified that the Allocate request containing a RESERVATION-TOKEN 3332 attribute can use any 5-tuple, and that 5-tuple need not have any 3333 specific relationship to the 5-tuple of the Allocate request that 3334 created the reservation. 3336 o Added a note that discusses retransmitted Allocate requests over 3337 UDP where the first request receives a failure response, but the 3338 second receives a success response. The server may elect to 3339 remember transmitted failure responses to avoid this situation. 3341 o Added text about the usage of the SOFTWARE-TYPE attribute 3342 (formerly known as the SERVER attribute) in TURN messages. 3344 o Rewrote the text in the Overview that motivates why TURN supports 3345 TCP and TLS between the client and the server. The previous text 3346 had been identified by various readers as inadequate and 3347 misleading. 3349 o Rewrote the section how a server handles a Refresh request to 3350 clarify processing in various error conditions. The new text 3351 makes it clear that it is OK to delete a non-existent allocation. 3352 It also clarifies how to handle retransmissions of Refresh 3353 requests over UDP. 3355 o Renamed the "RELAY-ADDRESS" attribute to "RELAYED-ADDRESS", since 3356 the text consistently uses the term "relayed transport address" 3357 for the concept and ICE uses the term "relayed candidate". 3359 o Changed the codepoint assigned to the error code "Wrong 3360 Credentials" from 438 to 441 to avoid a conflict with the "Stale 3361 Nonce" error code of STUN. 3363 o Changed the text to consistently use non-capitalized "request", 3364 "response" and "indication", except in headings, error code names, 3365 etc. 3367 o Added a note mentioning that TURN packets can be demuxed from 3368 other packets arriving on the same socket by looking at the 3369 5-tuple of the arriving packet. 3371 o Clarified that there are no required attributes is a ChannelBind 3372 success response. 3374 21.8. Changes from -07 to -08 3376 o Removed the BANDWIDTH attribute and all associated text (including 3377 error code 507 "Insufficient Bandwidth Capacity"), as the 3378 requirements for this feature were not clear and it was felt the 3379 feature could be easily added later. 3381 o Changed the format of the REQUESTED-PROPS attribute from a one- 3382 byte field to a set of bit flags. Changed the semantics of the 3383 unused portion of the value from RFFU to "MUST be 0" to give a 3384 more desirable behavior when new flags are defined. 3386 o Introduced the concept of Preserving vs. Non-Preserving 3387 allocations. As a result, completely revamped the rules for how 3388 to set the fields in the IP header, and added rules for relaying 3389 ICMP messages when the allocation is Preserving. 3391 21.9. Changes from -06 to -07 3393 o Rewrote the General Behavior section, making various changes in 3394 the process. 3396 o Changed the usage of authentication from MUST to SHOULD. 3398 o Changed the requirement that subsequent requests use the same 3399 username and password from MUST to SHOULD to allow for the 3400 possibility of changing the credentials using some unspecified 3401 mechanism. 3403 o Introduced a 438 (Wrong Credentials) error which is used when a 3404 non-Allocate request authenticates but does not use the same 3405 username and password as the Allocate request. Having a separate 3406 error code for this case avoids the client being confused over 3407 what the error actually is. 3409 o The server must now prevent the relayed transport address and the 3410 5-tuple from being reused in different allocations for 2 minutes 3411 after the allocation expires. 3413 o Changed the usage of FINGERPRINT from MUST NOT to MAY, to allow 3414 for the possible multiplexing of TURN with some other protocol. 3416 o Rewrote much of the section on Allocations, splitting it into 3417 three new sections (one on allocations in general, one on creating 3418 an allocation, and one on refreshing an allocation). 3420 o Replaced the mechanism for requesting relayed transport addresses 3421 with specific properties. The new mechanism is less powerful: a 3422 client can request an even port, or a pair of ports, but cannot 3423 request a single odd port or a specific port as was possible under 3424 the old mechanism. Nor can the client request a specific IP 3425 address. 3427 o Changed the rules for handling ALTERNATE-SERVER, removing the 3428 requirement that the referring server have "positive knowledge" 3429 about the state of the alternate server. The new rules instead 3430 rely on text in STUN to prevent referral loops. 3432 o Changed the rules for allocation lifetimes. Allocations lifetimes 3433 are now a minimum of 10 minutes; the client can ask for longer 3434 values, but requests for shorter values are ignored. The text now 3435 recommends that the client refresh an allocation one minute before 3436 it expires. 3438 o Put in temporary procedures for handling the BANDWIDTH attribute, 3439 modelled on the LIFETIME attribute. These procedures are mostly 3440 placeholders and likely to change in the next revision. 3442 o Added a detailed description of how a client reacts to the various 3443 errors it can receive in reply to an Allocate request. This 3444 replaces the various descriptions that were previously scattered 3445 throughout the document, which were inconsistent and sometimes 3446 contradictory. 3448 o Added a new section that gives the normative rules for 3449 permissions. 3451 o Changed the rules around permission lifetimes. The text used to 3452 recommend a value of one minute; it MUST now be 5 minutes. 3454 o Removed the errors "Channel Missing or Invalid", "Peer Address 3455 Missing or Invalid" and "Lifetime Malformed or Invalid" and used 3456 400 "Bad Request" instead. 3458 o Rewrote portions of the section on Send and Data indications and 3459 the section on Channels to try to make the client vs. server 3460 behavior clearer. 3462 o Channel bindings now expire after 10 minutes, and must be 3463 refreshed to keep them alive. 3465 o Binding a channel now installs or refreshes a permission for the 3466 IP address of corresponding peer. 3468 o Changed the wording describing the situation when the client sends 3469 a ChannelData message before receiving the ChannelBind success 3470 response. -06 said that client SHOULD NOT do this; -07 now says 3471 that a client MAY, but describes the consequences of doing it. 3473 o Added a section discussing the setting of fields in the IP header. 3475 o Replaced the REQUESTED-PORT-PROPS attribute with the REQUESTED- 3476 PROPS attribute that has a different format and semantics, but 3477 reuses the same code point. 3479 o Replaced the REQUESTED-IP attribute with the RESERVATION-TOKEN 3480 attribute, which has a different format and semantics, but reuses 3481 the same code point. 3483 o Removed error codes 443 and 444, and replaced them with 508 3484 (Insufficient Port Capacity). Also changed the error text for 3485 code 507 from "Insufficient Capacity" to "Insufficient Bandwidth 3486 Capacity". 3488 21.10. Changes from -05 to -06 3490 o Changed the mechanism for allocating channels to the one proposed 3491 by Eric Rescorla at the Dec 2007 IETF meeting. 3493 o Removed the framing mechanism (which was used to frame all 3494 messages) and replaced it with the ChannelData message. As part 3495 of this change, noted that the demux of ChannelData messages from 3496 TURN messages can be done using the first two bits of the message. 3498 o Rewrote the sections on transmitted and receiving data as a result 3499 of the above to changes, splitting it into a section on Send and 3500 Data indications and a separate section on channels. 3502 o Clarified the handling of Allocate request messages. In 3503 particular, subsequent Allocate request messages over UDP with the 3504 same transaction id are not an error but a retransmission. 3506 o Restricted the range of ports available for allocation to the 3507 Dynamic and/or Private Port range, and noted when ports outside 3508 this range can be used. 3510 o Changed the format of the REQUESTED-TRANSPORT attribute. The 3511 previous version used 00 for UDP and 01 for TCP; the new version 3512 uses protocol numbers from the IANA protocol number registry. The 3513 format of the attribute also changed. 3515 o Made a large number of changes to the non-normative portion of the 3516 document to reflect technical changes and improve the 3517 presentation. 3519 o Added the Issues section. 3521 21.11. Changes from -04 to -05 3523 o Removed the ability to allocate addresses for TCP relaying. This 3524 is now covered in a separate document. However, communication 3525 between the client and the server can still run over TCP or TLS/ 3526 TCP. This resulted in the removal of the Connect method and the 3527 TIMER-VAL and CONNECT-STAT attributes. 3529 o Added the concept of channels. All communication between the 3530 client and the server flows on a channel. Channels are numbered 3531 0..65535. Channel 0 is used for TURN messages, while the 3532 remaining channels are used for sending unencapsulated data to/ 3533 from a remote peer. This concept adds a new Channel Confirmation 3534 method and a new CHANNEL-NUMBER attribute. The new attribute is 3535 also used in the Send and Data methods. 3537 o The framing mechanism formally used just for stream-oriented 3538 transports is now also used for UDP, and the former Type and 3539 Reserved fields in the header have been replaced by a Channel 3540 Number field. The length field is zero when running over UDP. 3542 o TURN now runs on its own port, rather than using the STUN port. 3543 The use of channels requires this. 3545 o Removed the SetActiveDestination concept. This has been replaced 3546 by the concept of channels. 3548 o Changed the allocation refresh mechanism. The new mechanism uses 3549 a new Refresh method, rather than repeating the Allocation 3550 transaction. 3552 o Changed the syntax of SRV requests for secure transport. The new 3553 syntax is "_turns._tcp" rather than the old "_turn._tls". This 3554 change mirrors the corresponding change in STUN SRV syntax. 3556 o Renamed the old REMOTE-ADDRESS attribute to PEER-ADDRESS, and 3557 changed it to use the XOR-MAPPED-ADDRESS format. 3559 o Changed the RELAY-ADDRESS attribute to use the XOR-MAPPED-ADDRESS 3560 format (instead of the MAPPED-ADDRESS format)). 3562 o Renamed the 437 error code from "No Binding" to "Allocation 3563 Mismatch". 3565 o Added a discussion of what happens if a client's public binding on 3566 its outermost NAT changes. 3568 o The document now consistently uses the term "peer" as the name of 3569 a remote endpoint with which the client wishes to communicate. 3571 o Rewrote much of the document to describe the new concepts. At the 3572 same time, tried to make the presentation clearer and less 3573 repetitive. 3575 22. Acknowledgements 3577 The authors would like to thank the various participants in the 3578 BEHAVE working group for their many comments on this draft. Marc 3579 Petit-Huguenin, Remi Denis-Courmont, Jason Fischl, Derek MacDonald, 3580 Scott Godin, Cullen Jennings, Lars Eggert, Magnus Westerlund, Benny 3581 Prijono, and Eric Rescorla have been particularly helpful, with Eric 3582 suggesting the channel allocation mechanism, Cullen suggesting the 3583 REQUESTED-PORT-PROPS mechanism, and Marc spending many hours 3584 implementing the preliminary versions to look for problems. 3585 Christian Huitema was an early contributor to this document and was a 3586 co-author on the first few drafts. Finally, the authors would like 3587 to thank Dan Wing for both his contributions to the text and his huge 3588 help in restarting progress on this draft after work had stalled. 3590 23. References 3592 23.1. Normative References 3594 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 3595 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 3596 October 2008. 3598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3599 Requirement Levels", BCP 14, RFC 2119, March 1997. 3601 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3602 "Definition of the Differentiated Services Field (DS 3603 Field) in the IPv4 and IPv6 Headers", RFC 2474, 3604 December 1998. 3606 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3607 of Explicit Congestion Notification (ECN) to IP", 3608 RFC 3168, September 2001. 3610 [RFC1122] Braden, R., "Requirements for Internet Hosts - 3611 Communication Layers", STD 3, RFC 1122, October 1989. 3613 23.2. Informative References 3615 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3616 November 1990. 3618 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3619 September 1981. 3621 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 3622 E. Lear, "Address Allocation for Private Internets", 3623 BCP 5, RFC 1918, February 1996. 3625 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 3626 Self-Address Fixing (UNSAF) Across Network Address 3627 Translation", RFC 3424, November 2002. 3629 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3630 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3631 RFC 4787, January 2007. 3633 [I-D.ietf-mmusic-ice] 3634 Rosenberg, J., "Interactive Connectivity Establishment 3635 (ICE): A Protocol for Network Address Translator (NAT) 3636 Traversal for Offer/Answer Protocols", 3637 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 3639 [I-D.ietf-behave-turn-tcp] 3640 Perreault, S. and J. Rosenberg, "Traversal Using Relays 3641 around NAT (TURN) Extensions for TCP Allocations", 3642 draft-ietf-behave-turn-tcp-03 (work in progress), 3643 May 2009. 3645 [I-D.ietf-behave-turn-ipv6] 3646 Camarillo, G. and O. Novo, "Traversal Using Relays around 3647 NAT (TURN) Extension for IPv6", 3648 draft-ietf-behave-turn-ipv6-06 (work in progress), 3649 March 2009. 3651 [I-D.ietf-tsvwg-port-randomization] 3652 Larsen, M. and F. Gont, "Port Randomization", 3653 draft-ietf-tsvwg-port-randomization-03 (work in progress), 3654 March 2009. 3656 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 3657 Peer (P2P) Communication across Network Address 3658 Translators (NATs)", RFC 5128, March 2008. 3660 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 3661 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 3662 March 1996. 3664 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3665 Jacobson, "RTP: A Transport Protocol for Real-Time 3666 Applications", STD 64, RFC 3550, July 2003. 3668 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3669 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 3670 RFC 3711, March 2004. 3672 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 3673 December 2005. 3675 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 3676 RFC 4303, December 2005. 3678 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3679 Discovery", RFC 4821, March 2007. 3681 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3682 A., Peterson, J., Sparks, R., Handley, M., and E. 3683 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3684 June 2002. 3686 [I-D.rosenberg-mmusic-ice-nonsip] 3687 Rosenberg, J., "Guidelines for Usage of Interactive 3688 Connectivity Establishment (ICE) by non Session 3689 Initiation Protocol (SIP) Protocols", 3690 draft-rosenberg-mmusic-ice-nonsip-01 (work in progress), 3691 July 2008. 3693 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3694 Requirements for Security", BCP 106, RFC 4086, June 2005. 3696 [Frag-Harmful] 3697 Kent and Mogul, "Fragmentation Considered Harmful". 3699 Proc. SIGCOMM '87, vol. 17, No. 5, October 1987 3701 [Port-Numbers] 3702 "IANA Port Numbers Registry", 3703 . 3705 [Protocol-Numbers] 3706 "IANA Protocol Numbers Registry", 2005, 3707 . 3709 Authors' Addresses 3711 Jonathan Rosenberg 3712 Cisco Systems, Inc. 3713 Edison, NJ 3714 USA 3716 Email: jdrosen@cisco.com 3717 URI: http://www.jdrosen.net 3719 Rohan Mahy 3720 (Unaffiliated) 3722 Email: rohan@ekabal.com 3723 Philip Matthews 3724 Alcatel-Lucent 3725 600 March Road 3726 Ottawa, Ontario 3727 Canada 3729 Phone: 3730 Fax: 3731 Email: philip_matthews@magma.ca 3732 URI: