idnits 2.17.1 draft-schwartz-tram-turnbyname-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 156: '... Servers are NOT REQUIRED to support t...' RFC 2119 keyword, line 159: '...ompliant servers MUST reply with Error...' RFC 2119 keyword, line 162: '...rt this extension MUST comply with the...' RFC 2119 keyword, line 169: '...x01 and 0x02. The server MUST respond...' RFC 2119 keyword, line 178: '...message type, it MUST respond with Err...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (March 5, 2015) is 3339 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 585, but not defined == Outdated reference: A later version (-29) exists of draft-ietf-tram-turnbis-02 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6156 (Obsoleted by RFC 8656) -- No information found for draft-schwartz-return - is the name correct? -- Duplicate reference: RFC5766, mentioned in 'RFC1928', was also mentioned in 'RFC5766'. -- Obsolete informational reference (is this intentional?): RFC 5766 (ref. 'RFC1928') (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Schwartz 3 Internet-Draft J. Uberti 4 Intended status: Standards Track Google 5 Expires: September 6, 2015 March 5, 2015 7 TURN by name: an extension to TURN for contacting an endpoint by its DNS 8 name. 9 draft-schwartz-tram-turnbyname-00 11 Abstract 13 When tunneling traffic through TURN, a client may sometimes desire to 14 contact a remote endpoint that it knows by its DNS name, not its IP 15 address. This document describes an extension to TURN that allows 16 such a client to contact a named endpoint. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 6, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. New Address Family for DNS names . . . . . . . . . . . . . . 3 54 3. Extension to the XOR-PEER-ADDRESS attribute format . . . . . 3 55 4. Changes to TURN server behavior . . . . . . . . . . . . . . . 4 56 4.1. Servers that do not support the extension . . . . . . . . 4 57 4.2. Supported attributes . . . . . . . . . . . . . . . . . . 4 58 4.3. Supported messages . . . . . . . . . . . . . . . . . . . 4 59 4.4. Name mapping storage . . . . . . . . . . . . . . . . . . 4 60 4.5. Lookup behavior . . . . . . . . . . . . . . . . . . . . . 5 61 4.6. CreatePermission . . . . . . . . . . . . . . . . . . . . 6 62 4.6.1. Implications of this permission model . . . . . . . . 6 63 4.7. Send . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.8. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 65 4.8.1. Implications of this channel binding model . . . . . 8 66 4.9. Receiving Data . . . . . . . . . . . . . . . . . . . . . 9 67 4.9.1. Implications of this data receipt model . . . . . . . 9 68 5. Changes to TURN client behavior . . . . . . . . . . . . . . . 10 69 5.1. When to use this extension . . . . . . . . . . . . . . . 10 70 5.2. Issuing Send, CreatePermission, and ChannelBind requests 71 for DNS names . . . . . . . . . . . . . . . . . . . . . . 10 72 5.3. Receiving Data indications . . . . . . . . . . . . . . . 10 73 5.4. Handling dynamic addressing . . . . . . . . . . . . . . . 11 74 5.5. Dual-stack behavior . . . . . . . . . . . . . . . . . . . 11 75 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 10.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 The TURN standard [RFC5766] extends STUN to allow proxying 87 connections directly through the server. Clients send messages to 88 the server in order to request the allocation of ports on the server, 89 and identify the remote peers with whom they want to exchange 90 packets. These remote peers are identified by an XOR-PEER-ADDRESS 91 attribute, which includes the remote peer's IP address and port. 93 TURN is most commonly used as a component of an ICE [RFC5245] 94 implementation, to allow communication between endpoints that each 95 send their own transport address to the other in the form of an ICE 96 candidate. These candidates are typically constructed using STUN, or 97 by direct interrogation of the network interfaces, so they normally 98 contain IP addresses, although domain names are also allowed. 100 However, TURN is now attracting a wider range of use cases, 101 especially on enterprise networks and in conjunction with WebRTC. 102 Some use cases employ TURN as an "escape hatch" in an otherwise 103 tightly restricted network, with the intention that users would 104 tunnel much or all of their UDP traffic through the TURN server. On 105 some restricted networks, DNS access is also restricted, which may 106 prevent users from determining the IP address of a domain (e.g. an 107 application-specified TURN server, for RETURN 108 [I-D.schwartz-rtcweb-return], or an ICE candidate that contains a 109 domain name) that they wish to contact through the escape-hatch TURN 110 server. 112 Extending TURN to support named peers allows TURN to work for clients 113 who are attempting to contact an endpoint by name, on networks where 114 resolving those names is not otherwise possible. 116 2. New Address Family for DNS names 118 The Address Family 0x03 is defined to indicate that the specified 119 address is a DNS name. This family is only permitted under certain 120 circumstances, detailed below. 122 3. Extension to the XOR-PEER-ADDRESS attribute format 124 STUN/TURN attributes are Type-Length-Value encoded ([RFC5389], 125 Section 15). For both of the existing Families, the attribute's 126 encoded length is a known constant, because the length of the address 127 is constant. For the newly defined Family 0x03, the length is 128 variable, and the indicated length from the TLV encoding is necessary 129 in order to parse the attribute. 131 The DNS name is transmitted in the X-Address field, and is encoded by 132 the following procedure: 134 1. Define the "legacy transaction ID" as a 128-bit value consisting 135 of the 32-bit magic cookie followed by the 96-bit transaction ID. 137 2. Define the DNS name as a standard dot-separated UTF-8 byte-string 138 (not null-terminated). 140 3. Compute the encoded address (X-Address) by XOR'ing each byte of 141 the DNS name with the corresponding byte of the legacy 142 transaction ID. 144 * If the DNS name is longer than 128 bits, the corresponding 145 byte with which to XOR wraps around to the beginning of the 146 legacy transaction ID. 148 This procedure is an extension of the encoding for families 0x01 and 149 0x02, so all three XOR-PEER-ADDRESS families can be encoded and 150 parsed by a single procedure, without any special cases. 152 4. Changes to TURN server behavior 154 4.1. Servers that do not support the extension 156 Servers are NOT REQUIRED to support this extension. No change is 157 required to servers that do not support the extension. Upon 158 receiving a message containing an XOR-PEER-ADDRESS attribute with 159 Family 0x03, existing compliant servers MUST reply with Error 440 160 (Address Family not Supported). 162 Servers that do support this extension MUST comply with the 163 requirements that follow in this section. 165 4.2. Supported attributes 167 Address Family 0x03 is only permitted in the context of the XOR-PEER- 168 ADDRESS attribute. All other attributes that use address families 169 remain restricted to families 0x01 and 0x02. The server MUST respond 170 with Error 440 (Address Family not Supported) when encountering this 171 address family in an attribute where it is not supported. 173 4.3. Supported messages 175 The XOR-PEER-ADDRESS attribute may only have family 0x03 in the 176 context of a CreatePermission, Send, Data, or ChannelBind message. 177 If the server encounters this address family in the context of any 178 other message type, it MUST respond with Error 440 (Address Family 179 not Supported). 181 If a TURN server supports address family 0x03 in one of these 182 messages, it MUST support it in all of these messages. 184 4.4. Name mapping storage 186 Baseline TURN servers must store two kinds of state for each 187 Allocation: Permissions and Channel Bindings. This extension adds a 188 third kind of state: Name Mappings. Each DNS Name Mapping consists 189 of: 191 o a DNS name 192 o an IP address 194 o a reference count, which is always either 1 or 2 196 Name Mappings do not have an expiration time, but the server MUST 197 delete them if their reference count falls to zero. Like Permissions 198 and Channel Bindings, Name Mappings are scoped to a single 199 Allocation. 201 Each IP address appears in only one Name Mapping for an Allocation. 202 The requirements for CreatePermission and ChannelBind are structured 203 to maintain this invariant. 205 Server implementations SHOULD implement Name Mappings in a way that 206 enables fast bidirectional lookup. 208 4.5. Lookup behavior 210 When a DNS name lookup is required, the server's behavior depends on 211 the current Allocation. Each supported message is associated with an 212 Allocation, whose address family is IPv4, IPv6 [RFC6156], or Both 213 (via ADDITIONAL-ADDRESS-FAMILY [I-D.ietf-tram-turnbis]). 215 If the address family is IPv4, then the server MUST search for an A 216 record for the name, and similarly if the address family is IPv6, the 217 server MUST search for a AAAA record. The server MUST handle errors 218 as follows: 220 o If resolution fails due to a server error (e.g. DNS SERVFAIL), 221 reply with error code 500 (Server Error). 223 o If the resolution fails because there is no record of the required 224 type (e.g. DNS NOERROR), respond with error code 443 (Peer 225 Address Family Mismatch). 227 o For all other DNS errors, return error code 447 (Connection 228 timeout or failure). 230 The TURN server implementation MAY use a high-level DNS resolution 231 API, such as gethostbyname or getaddrinfo, to perform the lookup. 233 If the Allocation has both address families, then it MUST look for an 234 IPv6 address, and fall back to IPv4 only if a AAAA record is not 235 found. 237 4.6. CreatePermission 239 In baseline TURN, each CreatePermission message creates or renews a 240 Permission to send and receive messages to some specified IP address. 241 With this extension, a Permission may indicate either an IP address 242 or a DNS name. Both types of Permissions are subject to the same 243 expiration policy. 245 At any given time, there is at most one Permission that specifies any 246 IP address, or any DNS name, but there may be a Permission specifying 247 a DNS name that resolves to an IP address that is specified in 248 another Permission. 250 Upon receiving a CreatePermission message on an Allocation, the 251 server MUST perform these steps: 253 1. If the CreatePermission message contains a peer address of family 254 0x01 or 0x02, create or update a Permission for the given 255 address. (No change from baseline.) 257 2. If the CreatePermission message contains peer address of family 258 0x03: 260 A. Look for an existing Permission with the given DNS name. If 261 one exists, refresh its expiration time and return success. 263 B. Otherwise, check if there is a Name Mapping for the DNS name. 265 i. If one exists, increment its reference count. 267 ii. Otherwise, perform a DNS lookup for the name. If it 268 succeeds, add a DNS name mapping for the name and the 269 resolved address, with reference count 1. 271 C. Install a new permission for the DNS name. 273 When a Permission containing a DNS name expires, the server MUST 274 decrement the reference count on the Name Mapping for this DNS name, 275 and delete the Name Mapping if its reference count falls to zero. 277 4.6.1. Implications of this permission model 279 As long as a permission is regularly refreshed with the same DNS 280 name, the effective IP address will not change. 282 Permission refreshes for an IP address do not extend the lifetime of 283 DNS resolutions to that address. 285 Permission requests for an IP address are not sufficient to allow 286 Send requests to a DNS name that resolves to that IP address, and 287 vice versa. 289 4.7. Send 291 Upon receiving a Send message on an Allocation, the server MUST 292 perform these steps: 294 1. If the Send message contains a peer address of family 0x01 or 295 0x02, check for a Permission that indicates that IP address. 296 (There will be at most one.) If a Permission matches, send the 297 packet; otherwise silently drop it. (No change from baseline.) 299 2. If the Send message contains a peer address of family 0x03, check 300 if there is a Permission for the given DNS name. (There will be 301 at most one.) If one exists, send the packet to the IP address 302 indicated for that DNS name in its Name Mapping; otherwise 303 silently drop it. 305 4.8. Channel Binding 307 In baseline TURN, each ChannelBind message creates or renews a 308 channel binding, which consists of a transport ID, a peer's IP 309 address, and a port on that address. It also creates or renews a 310 permission for the peer's IP address, exactly as if a 311 CreatePermission message had been received for that IP address. 313 In this extension, each channel binding includes either an IP address 314 or a DNS name. 316 Upon receiving a ChannelBind message on an Allocation, the server 317 MUST perform these steps: 319 1. If the ChannelBind indicates a peer address of family 0x01 or 320 0x02 322 A. If a binding already exists with the specified transport ID, 323 IP address, and port, refresh the binding. 325 B. If a binding already exists for the specified transport ID 326 with a different or unspecified IP address or port, report 327 Error 400 (Bad Request). 329 C. If a binding already exists with this port and this IP 330 address, or a DNS name that maps to this IP address, report 331 Error 400 (Bad Request) and include a CHANNEL-NUMBER 332 attribute that indicates the number of the conflicting 333 channel. 335 D. Otherwise, create a binding. 337 E. Install or refresh a permission for the originally indicated 338 peer IP address. 340 2. If the ChannelBind indicates a peer address of family 0x03 342 A. If a binding already exists with the specified transport ID, 343 DNS name, and port, refresh the binding, including the IP 344 address. 346 B. Otherwise, resolve the DNS name to an IP address, using the 347 name mapping table if it exists, and performing a DNS lookup 348 only if no name mapping exists for this DNS name. 350 i. If a binding already exists for the specified transport 351 ID with a different IP address or port, report Error 352 400 (Bad Request). 354 ii. If a binding already exists with a different transport 355 ID, for this port, and this IP address or a DNS name 356 that is mapped to this IP address, report Error 400 357 (Bad Request) and include a CHANNEL-NUMBER attribute 358 that indicates the number of the conflicting channel. 360 C. Install a channel binding with the specified transport ID, 361 DNS name, and port. 363 D. Increment the name mapping's reference count, or Install a 364 new name mapping if one does not already exist for this DNS 365 name. 367 E. Perform the steps required when receiving a CreatePermission 368 message for this DNS name. 370 When a channel binding that indicates a DNS name expires, the server 371 MUST decrement the reference count on the matching name mapping, and 372 delete the mapping if the reference count falls to zero. 374 4.8.1. Implications of this channel binding model 376 As long as a channel is refreshed before it times out, it will 377 continue to resolve to a constant address. 379 There can never be two channels bound to the same remote transport 380 address. If that were possible, it would result in traffic 381 amplification (sending each received packet to all matching channels) 382 or other strange behaviors (e.g. selecting one arbitrary channel to 383 receive the packet). 385 Each time a new channel is bound for a DNS name, it checks for a Name 386 Mapping before doing any external resolution, so the resolved IP 387 address is guaranteed to be consistent with the active Permission for 388 this DNS name, if one exists. As a result, DNS resolution results 389 can persist indefinitely within an Allocation, longer than the DNS 390 TTL or any individual connection, if they are maintained by 391 ChannelBind or CreatePermission calls to different ports on the same 392 remote peer that overlap in time. 394 If two ChannelBind requests are received for the same port on two 395 different DNS names that resolve to the same IP address, the second 396 request will fail with a generic error code (400), but will also let 397 the client know which existing channel to use instead. The same is 398 true of collisions between IP and DNS channel binding requests. 400 Installing a channel binding to a DNS name also enables Send messages 401 to the DNS name, but not to the resolved IP address. 403 4.9. Receiving Data 405 Upon receiving an incoming packet on an Allocation, the server MUST 406 perform these steps: 408 1. Check if there is a channel binding to this source port and IP 409 address, or a DNS name that is mapped to this IP address. (There 410 will be at most one such channel.) If there is, let the channel 411 handle the packet. 413 2. Otherwise, check if there is any DNS permission that is mapped to 414 the source IP address. If there is, produce a Data message with 415 that DNS name. 417 3. Otherwise, check if there is any IP permission that matches the 418 source IP address. If there is, produce a Data message with the 419 source IP address; otherwise discard the packet. 421 4.9.1. Implications of this data receipt model 423 If a name mapping exists for an IP address, all packets received from 424 that address will be labeled with the DNS name, not the IP address. 425 Clients never learn the IP address for a DNS name unless they provoke 426 a conflict, similar to the naming model used by SOCKS5 [RFC1928]. 428 If a channel is bound for a port on a peer, all packets from that 429 port will be routed to the channel exclusively. 431 5. Changes to TURN client behavior 433 Clients are NOT REQUIRED to support this extension. No change is 434 required to existing clients. The requirements in this section only 435 apply to clients that opt to support the extension. 437 5.1. When to use this extension 439 When the client receives a request to contact an endpoint that is 440 identified by its DNS name, the client SHOULD attempt to use this 441 extension to reach that endpoint, and SHOULD NOT attempt to perform a 442 local DNS lookup for the name, so that connections may succeed even 443 if the local DNS server fails to return a correct result. 445 If the TURN server responds with Error 440 (Address Family Not 446 Supported), then the TURN client application SHOULD attempt to 447 perform a local DNS lookup for the name, and retry the connection by 448 IP address. (This functionality is logically separable from the TURN 449 protocol itself, and might best be implemented by having a TURN 450 client library that indicates the error, leaving the DNS lookup to be 451 the responsibility of the application that uses the library.) 453 5.2. Issuing Send, CreatePermission, and ChannelBind requests for DNS 454 names 456 When attempting to contact an endpoint by its DNS name, the client 457 SHOULD transmit a CreatePermission or ChannelBind request whose XOR- 458 PEER-ADDRESS attribute contains family 0x03, conveying the DNS name 459 formatted as described above. 461 If the server responds with Error 440 (Address family not supported), 462 then the client SHOULD abandon all requests using DNS, because the 463 server does not support this extension. 465 If a ChannelBind request fails with Error 400, but includes a 466 CHANNEL-NUMBER attribute, then that channel is already bound to the 467 remote transport address. 469 5.3. Receiving Data indications 471 Clients MAY send CreatePermission requests for both an IP address and 472 a DNS name that maps to that IP address, and both requests will 473 succeed. However, all Data messages from the remote peer will be 474 marked as being received from the DNS name. Therefore, clients MUST 475 NOT assume that replies from a Send to an IP address are labeled with 476 that IP address. 478 5.4. Handling dynamic addressing 480 The IP address to which a DNS name resolves is not a constant. It 481 may change occasionally due to address reassignment, or it may even 482 change on every lookup, in the case of round-robin DNS. 484 The TURN server ensures that the IP address associated with a 485 permission or channel binding does not change as long as the 486 permission or binding is refreshed before it expires. Therefore, 487 clients that need to send messages to a stable IP address MUST 488 refresh their DNS name permissions and channel bindings even while 489 they are not in use, to ensure that they do not expire and later 490 resolve to a different IP address. 492 If the client has previously connected to a DNS name on an 493 Allocation, and wishes to connect again to the same DNS name with an 494 up-to-date IP address resolution, it SHOULD request a new Allocation, 495 and connect to the DNS name on the new Allocation. 497 5.5. Dual-stack behavior 499 If a specific address family is not indicated for the remote 500 endpoint, and the server does not support dual allocation (e.g. 501 ADDITIONAL-ADDRESS-FAMILY [I-D.ietf-tram-turnbis]]), then the 502 client's behavior is implementation-defined. For example, when 503 processing a request to send the first packet to a DNS name, the 504 client MAY use an approach inspired by Happy Eyeballs [RFC6555]: 506 o Create an Allocation for the system's preferred address family 507 (e.g. IPv6). 509 o Attempt to connect to the DNS name on this Allocation using a 510 ChannelBind message. 512 * If the server replies with error code 443 (Peer Address Family 513 Mismatch), immediately discard the Allocation and try again 514 with an Allocation of the other family. 516 * If a response message is received before some timeout (e.g. 300 517 ms), use this Allocation 519 * If no response message is received before some timeout (e.g. 520 300 ms), attempt to connect using a new Allocation of the other 521 address family, and use whichever Allocation receives a 522 response first. Discard the other Allocation. 524 6. Examples 526 TURN TURN Peer DNS 527 client server A Server 528 | | | | 529 |-- ChannelBind req ---------------->| | | 530 | (peer-a.example.com to 0x4001) | | | 531 | |======= DNS query ========>| 532 | | (peer-a.example.com) | 533 | |<=======DNS result=========| 534 | | (192.0.2.15) | 535 |<---------- ChannelBind succ resp --| | | 536 | | | | 537 |-- [0x4001] data ------------------>| | | 538 | |=== data ===>| | 539 | | | | 540 | |<== data ====| | 541 |<------------------ [0x4001] data --| | | 543 Figure 1: Using DNS names with ChannelBind 545 TURN TURN Peer DNS 546 client server A Server 547 | | | | 548 |----- CreatePermission req -------->| | | 549 | (peer-a.example.com) | | | 550 | |======= DNS query ========>| 551 | | (peer-a.example.com) | 552 | |<=======DNS result=========| 553 | | (192.0.2.15) | 554 |<-- CreatePermission success resp --| | | 555 | | | | 556 |-- Send ind (peer-a.example.com) -->| | | 557 | |=== data ===>| | 558 | | | | 559 | |<== data ====| | 560 |<-- Data ind (peer-a.example.com) --| | | 561 | | | | 563 Figure 2: Using DNS names with CreatePermission and Send 565 TURN TURN Peer DNS 566 client server A Server 567 | | | | 568 |------- CreatePermission req ------>| | | 569 | (peer-a.example.com) | | | 570 | |======= DNS query ========>| 571 | | (peer-a.example.com) | 572 | |<=======DNS result=========| 573 | | (192.0.2.15) | 574 |<-- CreatePermission success resp --| | | 575 | | | | 576 |------- ChannelBind req ----------->| | | 577 | (peer-a.example.com to 0x4001) | | | 578 | | | | 579 |<---- ChannelBind succ resp --------| | | 580 | | | | 581 |-- Send ind (peer-a.example.com) -->| | | 582 | |=== data ===>| | 583 | | | | 584 | |<== data ====| | 585 |<---------- [0x4001] data ----------| | | 586 | | | | 588 Figure 3: Sharing DNS names between CreatePermission and ChannelBind 590 7. Security Considerations 592 TURN servers that implement this specification can be made to parse 593 arbitrary DNS records. They should make sure to use secure, well- 594 tested DNS client implementations. 596 Clients can cause the TURN server to perform an arbitrary number of 597 DNS lookups. Server implementations MAY limit the rate at which an 598 individual client can trigger lookups, and return Error 508 599 (Insufficient Capacity) when a client exceeds the limit. 601 A malicious server could forward messages to the wrong IP address for 602 a specified domain name, but this does not represent a change in 603 security relative to the basic TURN standard. 605 To provide this functionality, the server is required to store a 606 number of DNS Name Mappings that is at most the number of active 607 permissions or channels. Implementers should take care to avoid 608 resource leaks in the DNS mapping implementation, to maintain this 609 bound. 611 8. IANA Considerations 613 This draft adds a new STUN address family, 0x03 (DNS name). 615 9. Acknowledgements 617 Thanks to Warren Kumari for his early review. 619 10. References 621 10.1. Normative References 623 [I-D.ietf-tram-turnbis] 624 Reddy, T., Johnston, A., Matthews, P., and J. Rosenberg, 625 "Traversal Using Relays around NAT (TURN): Relay 626 Extensions to Session Traversal Utilities for NAT (STUN)", 627 draft-ietf-tram-turnbis-02 (work in progress), February 628 2015. 630 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 631 (ICE): A Protocol for Network Address Translator (NAT) 632 Traversal for Offer/Answer Protocols", RFC 5245, April 633 2010. 635 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 636 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 637 October 2008. 639 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 640 Relays around NAT (TURN): Relay Extensions to Session 641 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 643 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 644 Using Relays around NAT (TURN) Extension for IPv6", RFC 645 6156, April 2011. 647 10.2. Informative References 649 [I-D.schwartz-rtcweb-return] 650 Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN 651 (RETURN) for Connectivity and Privacy in WebRTC", draft- 652 schwartz-return-04 (work in progress), November 2014. 654 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 655 L. Jones, "SOCKS Protocol Version 5", RFC 5766, March 656 1996. 658 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 659 Dual-Stack Hosts", RFC 6555, April 2012. 661 Authors' Addresses 663 Benjamin M. Schwartz 664 Google, Inc. 665 111 8th Ave 666 New York, NY 10011 667 USA 669 Email: bemasc@webrtc.org 671 Justin Uberti 672 Google, Inc. 673 747 6th Street South 674 Kirkland, WA 98033 675 USA 677 Email: justin@uberti.name