idnits 2.17.1 draft-ietf-tram-turn-server-discovery-12.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 abstract seems to contain references ([RFC5766]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5766, updated by this document, for RFC5378 checks: 2006-03-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 12, 2017) is 2655 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) == Unused Reference: 'RFC1035' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC5198' is defined on line 590, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Downref: Normative reference to an Informational RFC: RFC 6024 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-16 == Outdated reference: A later version (-02) exists of draft-ietf-rtcweb-return-01 -- Obsolete informational reference (is this intentional?): RFC 3188 (Obsoleted by RFC 8458) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Patil 3 Internet-Draft T. Reddy 4 Updates: 5766 (if approved) Cisco 5 Intended status: Standards Track D. Wing 6 Expires: July 16, 2017 January 12, 2017 8 TURN Server Auto Discovery 9 draft-ietf-tram-turn-server-discovery-12 11 Abstract 13 Current Traversal Using Relays around NAT (TURN) server discovery 14 mechanisms are relatively static and limited to explicit 15 configuration. These are usually under the administrative control of 16 the application or TURN service provider, and not the enterprise, 17 ISP, or the network in which the client is located. Enterprises and 18 ISPs wishing to provide their own TURN servers need auto discovery 19 mechanisms that a TURN client could use with no or minimal 20 configuration. This document describes three such mechanisms for 21 TURN server discovery. 23 This draft updates [RFC5766] to relax the requirement for mutual 24 authentication in certain cases. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 16, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 3 63 4. Discovery using Service Resolution . . . . . . . . . . . . . 4 64 4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 5 65 4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5 67 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6 69 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 7 71 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 72 7.1. Mobility and Changing IP addresses . . . . . . . . . . . 8 73 7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 8 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. IPv4 Anycast . . . . . . . . . . . . . . . . . . . . . . 8 76 8.2. IPv6 Anycast . . . . . . . . . . . . . . . . . . . . . . 9 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 11 79 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 11 80 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 11.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 TURN [RFC5766] is a protocol that is often used to improve the 90 connectivity of Peer-to-Peer (P2P) applications (as defined in 91 section 2.7 of [RFC5128]). TURN allows a connection to be 92 established when one or both sides are incapable of a direct P2P 93 connection. It is an important building block for interactive, real- 94 time communication using audio, video, collaboration etc. 96 While TURN services are extensively used today, the means to auto 97 discover TURN servers do not exist. TURN clients are usually 98 explicitly configured with a well known TURN server. To allow TURN 99 applications to operate seamlessly across different types of networks 100 and encourage the use of TURN without the need for manual 101 configuration, it is important that there exists an auto discovery 102 mechanism for TURN services. Web Real-Time Communication (WebRTC) 103 [I-D.ietf-rtcweb-overview] usages and related extensions, which are 104 mostly based on web applications, need TURN server discovery 105 mechanisms. 107 This document describes three discovery mechanisms, so as to maximize 108 opportunity for discovery, based on the network in which the TURN 109 client finds itself. The three discovery mechanisms are: 111 o A resolution mechanism based on straightforward Naming Authority 112 Pointer (S-NAPTR) resource records in the Domain Name System 113 (DNS). [RFC5928] describes details on retrieving a list of server 114 transport addresses from DNS that can be used to create a TURN 115 allocation. 117 o DNS Service Discovery 119 o A mechanism based on anycast address for TURN. 121 In general, if a client wishes to communicate using one of its 122 interfaces using a specific IP address family, it SHOULD query the 123 TURN server(s) that has been discovered for that specific interface 124 and address family. How to select an interface and IP address family 125 is out of the scope of this document. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 [RFC2119]. 134 3. Discovery Procedure 136 TURN clients, by default, discover TURN server(s) by means of local 137 or manual TURN configuration (i.e., TURN servers configured at the 138 system level). Configuration discovered from an application, e.g., a 139 Java Script specified TURN server for Web Real-Time Communication 140 (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions, is 141 considered as local configuration. An implementation may give the 142 user an opportunity (e.g., by means of configuration file options or 143 menu items) to specify a TURN server for each address family. A 144 client can choose auto-discovery in the absence of local 145 configuration, if local configuration doesn't work or in addition to 146 local configuration. This document does not offer a recommendation 147 on server selection. 149 A TURN client that implements the auto discovery algorithm, to 150 discover TURN servers in the attached network, uses the following 151 mechanisms for discovery: 153 o Service Resolution : The TURN client attempts to perform TURN 154 service resolution using the host's DNS domain. 156 o DNS SD: DNS Service Discovery. 158 o Anycast : Send TURN allocate request to the assigned TURN anycast 159 request for each combination of interface and address family. 161 Not all TURN servers may be discovered using NAPTR records or DNS SD; 162 Similarly, not all TURN servers may support anycast. For best 163 results, a client SHOULD implement all discovery mechanisms described 164 above. 166 The document does not prescribe a strict order that a client must 167 follow for discovery. An implementation may choose to perform all 168 the above steps in parallel for discovery OR choose to follow any 169 desired order and stop the discovery procedure if a mechanism 170 succeeds. 172 On hosts with more than one interface or address family (IPv4/v6), 173 the TURN server discovery procedure has to be performed for each 174 combination of interface and address family. A client MAY choose to 175 perform the discovery procedure only for a desired interface/address 176 combination if the client does not wish to discover a TURN server for 177 all combinations of interface and address family. 179 4. Discovery using Service Resolution 181 This mechanism is performed in two steps: 183 1. A DNS domain name is retrieved for each combination of interface 184 and address family. 186 2. Retrieved DNS domain names are then used for S-NAPTR lookups as 187 per [RFC5928]. Further DNS lookups may be necessary to determine 188 TURN server IP address(es). 190 4.1. Retrieving Domain Name 192 A client has to determine the domain in which it is located. The 193 following sections provide two possible mechanisms to learn the 194 domain name, but other means of retrieving domain names may be used, 195 which are outside the scope of this document e.g. local 196 configuration. 198 Implementations may allow the user to specify a default name that is 199 used if no specific name has been configured. 201 4.1.1. DHCP 203 DHCP can be used to determine the domain name related to an 204 interface's point of network attachment. Network operators may 205 provide the domain name to be used for service discovery within an 206 access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define 207 DHCP IPv4 and IPv6 access network domain name options, 208 OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN respectively, to 209 identify a domain name that is suitable for service discovery within 210 the access network. 212 For IPv4, the discovery procedure MUST request the access network 213 domain name option in a Parameter Request List option, as described 214 in [RFC2131]. [RFC2132] defines the DHCP IPv4 domain name option; 215 while this option is less suitable, a client MAY request for it if 216 the access network domain name defined in [RFC5986] is not available. 218 For IPv6, the discovery procedure MUST request for the access network 219 domain name option in an Options Request Option (ORO) within an 220 Information-request message, as described in [RFC3315]. 222 If neither option can be retrieved the procedure fails for this 223 interface. If a result can be retrieved it will be used as an input 224 for S-NAPTR resolution. 226 4.1.2. From own Identity 228 For a TURN client with an understanding of the protocol mechanics of 229 calling applications, the client may wish to extract the domain name 230 from its own identity i.e canonical identifier used to reach the 231 user. 233 Example 235 SIP : 'sip:alice@example.com' 236 Bare JID : 'alice@example.com' 237 email : 'alice@example.com' 239 'example.com' is retrieved from the above examples. 241 A client may support multiple users, potentially with different 242 domains, or for a single user to use different domains for different 243 services. The means to choose and extract the domain name may be 244 different based on the type of identifier, service being used etc., 245 which are outside the scope of this document. 247 4.2. Resolution 249 Once the TURN discovery procedure has retrieved domain names, the 250 resolution mechanism described in [RFC5928] is followed. An S-NAPTR 251 lookup with 'RELAY' application service and the desired protocol tag 252 is made to obtain information necessary to connect to the 253 authoritative TURN server within the given domain. 255 If no TURN-specific S-NAPTR records can be retrieved, the discovery 256 procedure fails for this domain name (and the corresponding interface 257 and IP protocol version). If more domain names are known, the 258 discovery procedure may perform the corresponding S-NAPTR lookups 259 immediately. However, before retrying a lookup that has failed, a 260 client must wait a time period that is appropriate for the 261 encountered error (NXDOMAIN, timeout, etc.). 263 5. DNS Service Discovery 265 DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS 266 (mDNS) [RFC6762] provide generic solutions for discovering services 267 available in a local network. DNS-SD/mDNS define a set of naming 268 rules for certain DNS record types that they use for advertising and 269 discovering services. 271 Section 4.1 of [RFC6763] specifies that a service instance name in 272 DNS-SD has the following structure: 274 . . 276 The portion specifies the DNS sub-domain where the service 277 instance is registered. It may be "local.", indicating the mDNS 278 local domain, or it may be a conventional domain name such as 279 "example.com.". The portion of the TURN service instance 280 name MUST be "_turn._udp" or "_turn._tcp" or "_turns._udp" or 281 "_turns._tcp", as introduced in [RFC5766]. 283 5.1. mDNS 285 A TURN client can proactively discover TURN servers being advertised 286 in the site by multicasting a PTR query to one or all of the 287 following: 289 o "_turn._udp.local." 291 o "_turn._tcp.local" 293 o "_turns._udp.local." 295 o "_turns._tcp.local" 297 A TURN server can send out gratuitous multicast DNS answer packets 298 whenever it starts up, wakes from sleep, or detects a change in 299 network configuration. TURN clients receive these gratuitous packets 300 and cache information contained in it. 302 6. Discovery using Anycast 304 IP anycast can also be used for TURN service discovery. A packet 305 sent to an anycast address is delivered to the "topologically 306 nearest" network interface with the anycast address. Using the TURN 307 anycast address, the only two things that need to be deployed in the 308 network for discovery are the two things that actually use TURN. 310 When a client requires TURN services, it sends a TURN allocate 311 request to the assigned anycast address. A TURN anycast server 312 performs checks 1 to 7 discussed in Section 6.2 of [RFC5766]. If all 313 checks pass, the TURN anycast server MUST respond with a 300 (Try 314 Alternate) error as described in Section 2.9 of [RFC5766]; The 315 response contains the TURN unicast address in the ALTERNATE-SERVER 316 attribute. For subsequent communication with the TURN server, the 317 client uses the responding server's unicast address. This has to be 318 done because two packets addressed to an anycast address may reach 319 two different anycast servers. The client, thus, also needs to 320 ensure that the initial request fits in a single packet. An 321 implementation may choose to send out every new TURN Allocation 322 request to the anycast address to discover the closest and the most 323 optimal unicast address for the TURN server. 325 7. Deployment Considerations 327 7.1. Mobility and Changing IP addresses 329 A change of IP address on an interface may invalidate the result of 330 the TURN server discovery procedure. For instance, if the IP address 331 assigned to a mobile host changes due to host mobility, it may be 332 required to re-run the TURN server discovery procedure without 333 relying on earlier gained information. New requests should be made 334 to the newly learned TURN servers learned after TURN discovery re- 335 run. However, if an earlier learned TURN server is still accessible 336 using the new IP address, procedures described for mobility using 337 TURN defined in [I-D.ietf-tram-turn-mobility] can be used for ongoing 338 streams. 340 7.2. Recursively Encapsulated TURN 342 WebRTC endpoints SHOULD treat any TURN server discovered through the 343 mechanisms described in this specification as an enterprise/gateway 344 or access network server, in accordance with Recursively Encapsulated 345 TURN [I-D.ietf-rtcweb-return]. 347 8. IANA Considerations 349 8.1. IPv4 Anycast 351 IANA has assigned a single IPv4 address from the 192.0.0.0/24 prefix 352 and registered it in the "IANA IPv4 Special-Purpose Address Registry" 353 [RFC6890]. 355 +----------------------+-------------------------------------------+ 356 | Attribute | Value | 357 +----------------------+-------------------------------------------+ 358 | Address Block | 192.0.0.???/32 (??? = TBD1 by IANA) | 359 | Name | Traversal Using Relays around NAT Anycast | 360 | RFC | TBD2 | 361 | Allocation Date | TBD3 (Date of approval of this document) | 362 | Termination Date | N/A | 363 | Source | True | 364 | Destination | True | 365 | Forwardable | True | 366 | Global | True | 367 | Reserved-by-Protocol | False | 368 +----------------------+-------------------------------------------+ 370 8.2. IPv6 Anycast 372 IANA has assigned a single IPv6 address from the 2001:0000::/23 373 prefix and registered it in the "IANA IPv6 Special-Purpose Address 374 Registry" [RFC6890]. 376 +----------------------+-------------------------------------------+ 377 | Attribute | Value | 378 +----------------------+-------------------------------------------+ 379 | Address Block | 2001:1::???/128 (??? = TBD4 by IANA) | 380 | Name | Traversal Using Relays around NAT Anycast | 381 | RFC | TBD2 | 382 | Allocation Date | TBD3 (Date of approval of this document) | 383 | Termination Date | N/A | 384 | Source | True | 385 | Destination | True | 386 | Forwardable | True | 387 | Global | True | 388 | Reserved-by-Protocol | False | 389 +----------------------+-------------------------------------------+ 391 9. Security Considerations 393 Use of Session Traversal Utilities for NAT (STUN) [RFC5389] 394 authentication is OPTIONAL for TURN servers provided by the local 395 network or by the access network. A network provided TURN server MAY 396 be configured to accept Allocation requests without STUN 397 authentication, and a TURN client MAY be configured to accept 398 Allocation success responses without STUN authentication from a 399 network provided TURN server. 401 Making STUN authentication optional is a downgrade of a MUST level 402 requirement defined in [RFC5766]. The downgrade allows TURN servers 403 provided by local or access network to accept Allocation requests 404 from new and/or guest users in the network who do not necessarily 405 possess long term credentials for STUN authentication. The 406 intention, in such deployments, being to provide TURN services to all 407 users in the local or access network. However, this opens up a TURN 408 server to a variety of attacks described in Section 17 of [RFC5766]. 409 A TURN server in such cases must be configured to only process STUN 410 requests from the trusted local network or subscribers of the access 411 network. Operational measures must be taken in order protect the 412 TURN server; some of these measures include, but not limited to, 413 access control by means of access-lists, firewalls, subscriber quota 414 limits, ingress filtering etc. 416 A TURN client in the absence of STUN long-term credential mechanism 417 [RFC5389] or STUN Extension for Third-Party Authorization [RFC7635] 418 MUST use (D)TLS unless it trusts the network infrastructure to defend 419 against attacks discussed in [RFC5766]. It is RECOMMENDED that the 420 TURN client use one of the following techniques with (D)TLS to 421 validate the TURN server: 423 o For certificate-based authentication, a pre-populated trust anchor 424 store [RFC6024] allows a TURN client to perform path validation 425 for the server certificate obtained during the (D)TLS handshake. 426 If the client used a domain name to discover the TURN server, that 427 domain name also provides a mechanism for validation of the TURN 428 server. The client MUST use the rules and guidelines given in 429 section 6 of [RFC6125] to validate the TURN server identity. 431 o Certification authorities that issue TURN server certificates 432 SHOULD support the CN-ID, DNS-ID, SRV-ID and URI-ID identifier 433 types. TURN service providers SHOULD prefer the use of DNS-ID, 434 SRV-ID and URI-ID over CN-ID identifier types in certificate 435 requests (as described in Section 2.3 from [RFC6125]) and the 436 wildcard character '*' SHOULD NOT be included in presented 437 identifier. 439 o For TURN servers that don't have a certificate trust chain (e.g., 440 because they are on a home network or a corporate network), a 441 configured list of TURN servers can contain the Subject Public Key 442 Info (SPKI) fingerprint of the TURN servers. The public key is 443 used for the same reasons HTTP pinning [RFC7469] uses the public 444 key. 446 o Raw public key-based authentication, as defined in [RFC7250], 447 could also be used to authenticate a TURN server. 449 An auto-discovered TURN server is considered to be only as trusted as 450 the path between the client and the TURN server. In order to safely 451 use auto-discovered TURN servers for sessions with 'strict privacy' 452 requirements, the user needs to be able to define privacy criteria 453 (e.g. a trusted list of servers, networks, or domains) that are 454 considered acceptable for such traffic. Any discovered TURN server 455 outside the criteria is considered untrusted and therefore MUST NOT 456 be used for privacy sensitive communication. 458 In some auto-discovery scenarios, it might not be possible for the 459 TURN client to use (D)TLS authentication to validate the TURN server. 460 However, fall-back to clear text in such cases could leave the TURN 461 client open to on-path injection of spoofed TURN messages. A TURN 462 client could fall back to encryption-only (D)TLS when (D)TLS 463 authentication is not available, but MUST NOT fall back without 464 explicit administrator choice. Another reason to fall-back to 465 encryption-only is for privacy, which is analogous to SMTP 466 opportunistic encryption [RFC7435] where one does not require privacy 467 but one desires privacy when possible. 469 In order to allow the TURN client to fallback to (D)TLS as described 470 above, a TURN server that does not require either STUN long term 471 authentication [RFC5389] or STUN Extension for Third Party 472 Authorization [RFC7635] MUST support (D)TLS and if the network 473 infrastructure is capable of defending against attacks discussed in 474 [RFC5766] then the TURN server MAY allow fallback to clear text. 476 A TURN client could fall back to clear text if it does not support 477 unauthenticated (D)TLS, but MUST NOT fall back without explicit 478 administrator choice. Fallback to clear text is NOT RECOMMENDED 479 because it makes the client more susceptible to man-in-the-middle 480 attacks and on-path packet injection. 482 9.1. Service Resolution 484 The primary attack against the methods described in this document is 485 one that would lead to impersonation of a TURN server. An attacker 486 could attempt to compromise the S-NAPTR resolution. Security 487 considerations described in [RFC5928] are applicable here as well. 489 In addition to considerations related to S-NAPTR, it is important to 490 recognize that the output of this is entirely dependent on its input. 491 An attacker who can control the domain name can also control the 492 final result. Because more than one method can be used to determine 493 the domain name, a host implementation needs to consider attacks 494 against each of the methods that are used. 496 If DHCP is used, the integrity of DHCP options is limited by the 497 security of the channel over which they are provided. Physical 498 security and separation of DHCP messages from other packets are 499 commonplace methods that can reduce the possibility of attack within 500 an access network; alternatively, DHCP authentication [RFC3188] can 501 provide a degree of protection against modification. When using DHCP 502 discovery, clients are encouraged to use unicast DHCP INFORM queries 503 instead of broadcast queries which are more easily spoofed in 504 insecure networks. 506 9.2. DNS Service Discovery 508 Since DNS-SD is just a specification for how to name and use records 509 in the existing DNS system, it has no specific additional security 510 requirements over and above those that already apply to DNS queries 511 and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) 512 [RFC4033] should be used where the authenticity of information is 513 important. For DNS updates, secure updates [RFC2136][RFC3007] should 514 generally be used to control which clients have permission to update 515 DNS records. 517 For mDNS, in addition to what has been described above, a principal 518 security threat is a security threat inherent to IP multicast routing 519 and any application that runs on it. A rogue system can advertise 520 that it is a TURN server. Discovery of such rogue systems as TURN 521 servers, in itself, is not a security threat if there is a means for 522 the TURN client to authenticate and authorize the discovered TURN 523 servers. 525 9.3. Anycast 527 In a network without any TURN server that is aware of the TURN 528 anycast address, outgoing TURN requests could leak out onto the 529 external Internet, possibly revealing information. 531 Using an IANA-assigned well-known TURN anycast address enables border 532 gateways to block such outgoing packets. In the default-free zone, 533 routers should be configured to drop such packets. Such 534 configuration can occur naturally via BGP messages advertising that 535 no route exists to said address. 537 Sensitive clients that do not wish to leak information about their 538 presence can set an IP TTL on their TURN requests that limits how far 539 they can travel into the public Internet. 541 10. Acknowledgements 543 The authors would like to thank Simon Perrault, Paul Kyzivat, Troy 544 Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba, Karl Stahl, 545 Brian Weis, Ralph Dromes, Ben Campbell, Suresh Krishnan and Brandon 546 Williams for their review and valuable comments. Thanks to Adam 547 Roach for his detailed review and suggesting DNS Service Discovery as 548 an additional discovery mechanism. 550 11. References 552 11.1. Normative References 554 [RFC1035] Mockapetris, P., "Domain names - implementation and 555 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 556 November 1987, . 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, 560 DOI 10.17487/RFC2119, March 1997, 561 . 563 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 564 RFC 2131, DOI 10.17487/RFC2131, March 1997, 565 . 567 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 568 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 569 . 571 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 572 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 573 RFC 2136, DOI 10.17487/RFC2136, April 1997, 574 . 576 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 577 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 578 . 580 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 581 C., and M. Carney, "Dynamic Host Configuration Protocol 582 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 583 2003, . 585 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 586 Rose, "DNS Security Introduction and Requirements", 587 RFC 4033, DOI 10.17487/RFC4033, March 2005, 588 . 590 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 591 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 592 . 594 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 595 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 596 DOI 10.17487/RFC5389, October 2008, 597 . 599 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 600 Relays around NAT (TURN): Relay Extensions to Session 601 Traversal Utilities for NAT (STUN)", RFC 5766, 602 DOI 10.17487/RFC5766, April 2010, 603 . 605 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 606 (TURN) Resolution Mechanism", RFC 5928, 607 DOI 10.17487/RFC5928, August 2010, 608 . 610 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 611 Location Information Server (LIS)", RFC 5986, 612 DOI 10.17487/RFC5986, September 2010, 613 . 615 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 616 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 617 2010, . 619 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 620 DOI 10.17487/RFC6762, February 2013, 621 . 623 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 624 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 625 . 627 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 628 "Special-Purpose IP Address Registries", BCP 153, 629 RFC 6890, DOI 10.17487/RFC6890, April 2013, 630 . 632 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 633 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 634 Transport Layer Security (TLS) and Datagram Transport 635 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 636 June 2014, . 638 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 639 "Session Traversal Utilities for NAT (STUN) Extension for 640 Third-Party Authorization", RFC 7635, 641 DOI 10.17487/RFC7635, August 2015, 642 . 644 11.2. Informative References 646 [I-D.ietf-rtcweb-overview] 647 Alvestrand, H., "Overview: Real Time Protocols for 648 Browser-based Applications", draft-ietf-rtcweb-overview-16 649 (work in progress), November 2016. 651 [I-D.ietf-rtcweb-return] 652 Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN 653 (RETURN) for Connectivity and Privacy in WebRTC", draft- 654 ietf-rtcweb-return-01 (work in progress), January 2016. 656 [I-D.ietf-tram-turn-mobility] 657 Reddy, T., Wing, D., Patil, P., and P. Martinsen, 658 "Mobility with TURN", draft-ietf-tram-turn-mobility-09 659 (work in progress), September 2016. 661 [RFC3188] Hakala, J., "Using National Bibliography Numbers as 662 Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, 663 October 2001, . 665 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 666 Peer (P2P) Communication across Network Address 667 Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 668 2008, . 670 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 671 Verification of Domain-Based Application Service Identity 672 within Internet Public Key Infrastructure Using X.509 673 (PKIX) Certificates in the Context of Transport Layer 674 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 675 2011, . 677 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 678 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 679 December 2014, . 681 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 682 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 683 2015, . 685 Authors' Addresses 687 Prashanth Patil 688 Cisco Systems, Inc. 690 Email: praspati@cisco.com 692 Tirumaleswar Reddy 693 Cisco Systems, Inc. 694 Cessna Business Park, Varthur Hobli 695 Sarjapur Marathalli Outer Ring Road 696 Bangalore, Karnataka 560103 697 India 699 Email: tireddy@cisco.com 700 Dan Wing 701 USA 703 Email: dwing-ietf@fuggles.com