idnits 2.17.1 draft-ietf-rtcweb-mdns-ice-candidates-04.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 7 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2019) is 1655 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'WebRTCSpec' is defined on line 814, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB Y. Fablet 3 Internet-Draft Apple Inc. 4 Intended status: Informational J. de Borst 5 Expires: April 18, 2020 J. Uberti 6 Q. Wang 7 Google 8 October 16, 2019 10 Using Multicast DNS to protect privacy when exposing ICE candidates 11 draft-ietf-rtcweb-mdns-ice-candidates-04 13 Abstract 15 WebRTC applications collect ICE candidates as part of the process of 16 creating peer-to-peer connections. To maximize the probability of a 17 direct peer-to-peer connection, client private IP addresses are 18 included in this candidate collection. However, disclosure of these 19 addresses has privacy implications. This document describes a way to 20 share local IP addresses with other clients while preserving client 21 privacy. This is achieved by concealing IP addresses with 22 dynamically generated Multicast DNS (mDNS) names. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 18, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3 62 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1.2. Implementation Guidance . . . . . . . . . . . . . . . 5 64 3.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 6 65 3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2.2. Implementation Guidance . . . . . . . . . . . . . . . 7 67 3.3. Additional Privacy Considerations . . . . . . . . . . . . 7 68 3.3.1. Statistics . . . . . . . . . . . . . . . . . . . . . 7 69 3.3.2. Interactions With TURN Servers . . . . . . . . . . . 7 70 3.3.3. Generated Name Reuse . . . . . . . . . . . . . . . . 8 71 3.3.4. Specific Browsing Contexts . . . . . . . . . . . . . 8 72 3.3.5. Network Interface Enumeration . . . . . . . . . . . . 8 73 3.3.6. Monitoring of Sessions . . . . . . . . . . . . . . . 9 74 4. Potential Limitations . . . . . . . . . . . . . . . . . . . . 9 75 4.1. Reduced Connectivity . . . . . . . . . . . . . . . . . . 9 76 4.2. Connection Setup Latency . . . . . . . . . . . . . . . . 10 77 4.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10 78 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. Normal Handling . . . . . . . . . . . . . . . . . . . . . 11 80 5.2. Peer-reflexive Candidate From Slow Signaling . . . . . . 12 81 5.3. Peer-reflexive Candidate From Slow Resolution . . . . . . 12 82 5.4. IPv4, IPv6, and STUN handling . . . . . . . . . . . . . . 12 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 6.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 15 85 6.2. Malicious Responses to Deny Name Registration . . . . . . 16 86 6.3. Unsolicited ICE Communications . . . . . . . . . . . . . 16 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 8.2. Informative References . . . . . . . . . . . . . . . . . 17 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 As detailed in [IPHandling], exposing client private IP addresses by 96 default to web applications maximizes the probability of successfully 97 creating direct peer-to-peer connections between clients, but creates 98 a significant surface for user fingerprinting. [IPHandling] 99 recognizes this issue, but also admits that there is no current 100 solution to this problem; implementations that choose to use Mode 3 101 to address the privacy concerns often suffer from failing or 102 suboptimal connections in WebRTC applications. This is particularly 103 an issue on unmanaged networks, typically homes or small offices, 104 where NAT loopback may not be supported. 106 This document proposes an overall solution to this problem by 107 providing a mechanism for WebRTC implementations to register 108 ephemeral mDNS [RFC6762] names for local private IP addresses, and 109 then provide those names, rather than the IP addresses, in their ICE 110 candidates. While this technique is intended to benefit WebRTC 111 implementations in web browsers, by preventing collection of private 112 IP addresses by arbitrary web pages, it can also be used by any 113 endpoint that wants to avoid disclosing information about its local 114 network to remote peers on other networks. 116 WebRTC and WebRTC-compatible endpoints [Overview] that receive ICE 117 candidates with mDNS names will resolve these names to IP addresses 118 and perform ICE processing as usual. In the case where the endpoint 119 is a web application, the WebRTC implementation will manage this 120 resolution internally and will not disclose the actual IP addresses 121 to the application. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Description 131 This section uses the concept of ICE agent as defined in [RFC8445]. 132 In the remainder of the document, it is assumed that each browsing 133 context (as defined in Section 7.1 of [HTMLSpec]) has its own ICE 134 agent. 136 3.1. ICE Candidate Gathering 138 This section outlines how mDNS should be used by ICE agents to 139 conceal local IP addresses. 141 3.1.1. Procedure 143 For each host candidate gathered by an ICE agent as part of the 144 gathering process described in [RFC8445], Section 5.1.1, the 145 candidate is handled as described below. 147 1. Check whether this IP address satisfies the ICE agent's policy 148 regarding whether an address is safe to expose. If so, expose 149 the candidate and abort this process. 151 2. Check whether the ICE agent has previously generated, registered, 152 and stored an mDNS hostname for this IP address as per steps 3 to 153 5. If it has, skip ahead to step 6. 155 3. Generate a unique mDNS hostname. The unique name MUST consist of 156 a version 4 UUID as defined in [RFC4122], followed by ".local". 158 4. Register the candidate's mDNS hostname as defined in [RFC6762]. 159 The ICE agent SHOULD send an mDNS announcement for the hostname, 160 but as the hostname is expected to be unique, the ICE agent 161 SHOULD skip probing of the hostname. 163 5. Store the mDNS hostname and its related IP address in the ICE 164 agent for future reuse. 166 6. Replace the IP address of the ICE candidate with its mDNS 167 hostname and provide the candidate to the web application. 169 ICE agents can implement this procedure in any way as long as it 170 produces equivalent results. An implementation may for instance pre- 171 register mDNS hostnames by executing steps 3 to 5 and prepopulate an 172 ICE agent accordingly. By doing so, only step 6 of the above 173 procedure will be executed at the time of gathering candidates. 175 In order to prevent web applications from using this mechanism to 176 query for mDNS support in the local network, the ICE agent SHOULD 177 still provide mDNS candidates in step 6 even if the local network 178 does not support mDNS or mDNS registration fails in step 4. 180 This procedure ensures that an mDNS name is used to replace only one 181 IP address. Specifically, an ICE agent using an interface with both 182 IPv4 and IPv6 addresses MUST expose a different mDNS name for each 183 address. 185 3.1.2. Implementation Guidance 187 3.1.2.1. Registration 189 Sending the mDNS announcement to the network can be delayed, for 190 instance due to rate limits. An ICE agent SHOULD provide the 191 candidate to the web application as soon as its mDNS name is 192 generated, regardless of whether the announcement has been sent on 193 the network. 195 3.1.2.2. Determining Address Privacy and Server-Reflexive Candidates 197 Naturally, an address that is already exposed to the Internet does 198 not need to be protected by mDNS, as it can be trivially observed by 199 the web server or remote endpoint. However, determining this ahead 200 of time is not straightforward; while the fact that an IPv4 address 201 is private can sometimes be inferred by its value, e.g., whether it 202 is an [RFC1918] address, the reverse is not necessarily true. IPv6 203 addresses present their own complications, e.g., private IPv6 204 addresses as a result of NAT64 [RFC6146]. 206 Instead, the determination of whether an address is public can be 207 reliably made as part of the ICE gathering process. For each mDNS 208 host candidate generated according the guidance above, the usual STUN 209 [RFC5389] request is sent to a STUN server. This can be done for 210 both IPv4 and IPv6 local addresses, provided that the application has 211 configured both IPv4 and IPv6 STUN servers. If the STUN response 212 returns the same value as the local IP address, this indicates the 213 address is in fact public. 215 Regardless of the result, a server-reflexive candidate will be 216 generated; the transport address of this candidate is an IP address 217 and therefore distinct from the hostname transport address of the 218 associated mDNS candidate, and as such MUST NOT be considered 219 redundant per the guidance in [RFC8445], Section 5.1.3. To avoid 220 accidental IP address disclosure, this server-reflexive candidate 221 MUST have its raddr field set to "0.0.0.0"/"::" and its rport field 222 set to "9", as discussed in [ICESDP], Section 9.1. 224 Once an address has been identified as public, the ICE agent MAY 225 cache this information and omit mDNS protection for that address in 226 future ICE gathering phases. 228 3.1.2.3. Special Handling for IPv6 Addresses 230 As noted in [IPHandling], private IPv4 addresses are especially 231 problematic because of their unbounded lifetime. However, the 232 [RFC4941] IPv6 addresses recommended for WebRTC have inherent privacy 233 protections, namely a short lifetime and the lack of any stateful 234 information. Accordingly, implementations MAY choose to not conceal 235 [RFC4941] addresses with mDNS names as a tradeoff for improved peer- 236 to-peer connectivity. 238 3.1.2.4. mDNS Candidate Encoding 240 The mDNS name of an mDNS candidate MUST be used in the connection- 241 address field of its candidate attribute. However, when an mDNS 242 candidate would be the default candidate, typically because there are 243 no other candidates, its mDNS name MUST NOT be used in the 244 connection-address field of the SDP "c=" line, as experimental 245 deployment has indicated that many remote endpoints will fail to 246 handle such a SDP. In this situation, the IP address values 247 "0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and 248 m= lines, similar to how the no-candidates case is handled in 249 [ICESDP], Section 4.3.1. 251 Any candidates exposed to the application via local descriptions MUST 252 be identical to those provided during candidate gathering (i.e., MUST 253 NOT contain private host IP addresses). 255 3.2. ICE Candidate Processing 257 This section outlines how received ICE candidates with mDNS names are 258 processed by ICE agents, and is relevant to all endpoints. 260 3.2.1. Procedure 262 For any remote ICE candidate received by the ICE agent, the following 263 procedure is used: 265 1. If the connection-address field value of the ICE candidate does 266 not end with ".local" or if the value contains more than one ".", 267 then process the candidate as defined in [RFC8445]. 269 2. Otherwise, resolve the candidate using mDNS. The ICE agent 270 SHOULD set the unicast-response bit of the corresponding mDNS 271 query message; this minimizes multicast traffic, as the response 272 is probably only useful to the querying node. 274 3. If it resolves to an IP address, replace the mDNS hostname of the 275 ICE candidate with the resolved IP address and continue 276 processing of the candidate as defined in [RFC8445]. 278 4. Otherwise, ignore the candidate. 280 3.2.2. Implementation Guidance 282 An ICE agent may use a hostname resolver that transparently supports 283 both Multicast and Unicast DNS. In this case the resolution of a 284 ".local" name may happen through Unicast DNS as noted in [RFC6762], 285 Section 3. 287 An ICE agent SHOULD ignore candidates where the hostname resolution 288 returns more than one IP address. 290 An ICE agent MAY add additional restrictions regarding the ICE 291 candidates it will resolve using mDNS, as this mechanism allows 292 attackers to send ICE traffic to devices with well-known mDNS names. 294 3.3. Additional Privacy Considerations 296 The goal of this mechanism is to keep knowledge of private host IP 297 addresses within the ICE agent while continuing to allow the 298 application to transmit ICE candidates. Besides keeping private host 299 IP addresses out of ICE candidates, implementations must take steps 300 to prevent these IP addresses from being exposed to web applications 301 through other means. 303 3.3.1. Statistics 305 Statistics related to ICE candidates that are accessible to the web 306 application MUST NOT contain the IP address of a local or remote mDNS 307 candidate; the mDNS name SHOULD be used instead. 309 In addition, a peer-reflexive remote candidate may be constructed 310 from a remote host IP address as a result of an ICE connectivity 311 check, as described in Section 7.3.1.3 of [RFC8445]. This check may 312 arrive before the candidate due to signaling or mDNS resolution 313 delays, as shown in the examples above. 315 To prevent disclosure of the host IP address to the application in 316 this scenario, statistics related to ICE candidates MUST NOT contain 317 the IP address of any peer-reflexive candidate, unless that IP has 318 already been learned through signaling of a candidate with the same 319 address and either the same or a different port; this includes cases 320 where the signaled candidate is discarded as redundant according to 321 Section 5.1.3 of [RFC8445]. 323 3.3.2. Interactions With TURN Servers 325 When sending data to a TURN [RFC5766] server, the sending client 326 tells the server the destination IP and port for the data. This 327 means that if the client uses TURN to send to an IP that was obtained 328 by mDNS resolution, the TURN server will learn the underlying host IP 329 and port, and this information can then be relayed to the web 330 application, defeating the value of the mDNS wrapping. 332 To prevent disclosure of the host IP address to a TURN server, the 333 ICE agent MUST NOT form candidate pairs between its own relay 334 candidates and remote mDNS candidates. Note that the converse is not 335 an issue; the ICE agent MAY form candidate pairs between its own mDNS 336 candidates and remote relay candidates, as in this situation host IPs 337 will not be sent directly to the TURN server. 339 This restriction has no effect on connectivity; in the cases where 340 host IP addresses are private and need to be wrapped with mDNS names, 341 they will be unreachable from the TURN server, and as noted above, 342 the reverse path will continue to work normally. 344 3.3.3. Generated Name Reuse 346 It is important that use of registered mDNS hostnames is limited in 347 time and/or scope. Indefinitely reusing the same mDNS hostname 348 candidate would provide applications an even more reliable tracking 349 mechanism than the private IP addresses that this specification is 350 designed to hide. In the case of a web application, the use of 351 registered mDNS hostnames SHOULD be scoped by the web application 352 origin, and SHOULD have the lifetime of the page executing the web 353 application. 355 3.3.4. Specific Browsing Contexts 357 As noted in [IPHandling], privacy may be breached if a web 358 application running in two browsing contexts can determine whether it 359 is running on the same device. While the approach in this document 360 prevents the application from directly comparing local private IP 361 addresses, a successful local WebRTC connection can also present a 362 threat to user privacy. Specifically, when the latency of a WebRTC 363 connection latency is close to zero, the probability is high that the 364 two peers are running on the same device. 366 To avoid this issue, browsers SHOULD NOT register mDNS names for 367 WebRTC applications running in a third-party browsing context (i.e., 368 a context that has a different origin than the top-level browsing 369 context), or a private browsing context. 371 3.3.5. Network Interface Enumeration 373 Even when local IP addresses are not exposed, the number of mDNS 374 hostname candidates can still provide a fingerprinting dimension. 375 This is in particular the case for network interfaces with limited 376 connectivity that will not generate server-reflexive or relay 377 candidates. 379 The more mDNS names an endpoint exposes through mDNS hostname 380 candidates, the higher the fingerprinting risk. One countermeasure 381 is to limit this number to a small value. 383 Note that no additional fingerprinting risk is introduced when 384 restricting mDNS hostname candidates to default route only. 386 3.3.6. Monitoring of Sessions 388 A malicious endpoint in the local network may also record other 389 endpoints who are registering, unregistering, and resolving mDNS 390 names. By doing so, they can create a session log that shows which 391 endpoints are communicating, and for how long. If both endpoints in 392 the session are on the same network, the fact they are communicating 393 can be discovered. 395 Mitigation of this threat is beyond the scope of this proposal. 397 4. Potential Limitations 399 4.1. Reduced Connectivity 401 With typical ICE, endpoints on the same network will usually be able 402 to establish a direct connection between their local IP addresses. 403 When using the mDNS technique, a direct connection is still possible, 404 but only if at least one side can properly resolve the provided mDNS 405 candidates. This may not be possible in all scenarios. 407 First, some networks may entirely disable mDNS. Second, mDNS queries 408 have limited scope. On large networks, this may mean that an mDNS 409 name cannot be resolved if the remote endpoint is too many segments 410 away. 412 When mDNS fails, ICE will attempt to fall back to either NAT hairpin, 413 if supported, or TURN relay if not. This may result in reduced 414 connectivity, reduced throughput and increased latency, as well as 415 increased cost in case of TURN relay. 417 During experimental testing of the mDNS technique across a set of 418 known mDNS-aware endpoints that had configured a STUN server but not 419 a TURN server, the observed impact to ICE connection rate was 2% 420 (relative) when mDNS was enabled on both sides, compared to when mDNS 421 was only enabled on one side. In this testing, the percentage of 422 connections that required STUN (i.e., went through a NAT) increased 423 from 94% to 97%, indicating that mDNS succeeded about half the time, 424 and fell back to NAT hairpin for the remainder. The most likely 425 explanation for the overall connection rate drop is that hairpinning 426 failed in some cases. 428 One potential mitigation, as discussed in Section 3.3, is to not 429 conceal candidates created from [RFC4941] IPv6 addresses. This 430 permits connectivity even in large internal networks or where mDNS is 431 disabled. Future versions of this document will include experimental 432 data regarding this option. 434 4.2. Connection Setup Latency 436 As noted in Section 3, ICE agents using the mDNS technique are 437 responsible for registering and resolving mDNS names as part of the 438 ICE process. These steps may delay establishment of a direct peer- 439 to-peer connection, compared to when raw local IP addresses are used. 441 Given that these mDNS registrations and queries are typically 442 occurring on a local network, any associated delays should be small. 443 Also, as noted in Section 3.1, pre-registration can be employed to 444 eliminate gathering delays entirely. 446 4.3. Backward Compatibility 448 For the most part, backward compatibility does not present a 449 significant issue for the mDNS technique. When an endpoint that 450 supports mDNS communicates with an endpoint that does not, the legacy 451 endpoint will still provide its local IP addresses, and accordingly a 452 direct connection can still be attempted, even though the legacy 453 endpoint cannot resolve the mDNS names provided by the new endpoint. 454 In the event the legacy endpoint attempts to resolve mDNS names using 455 Unicast DNS, this may cause ICE to take somewhat longer to fully 456 complete, but should not have any effect on connectivity or 457 connection setup time. 459 However, some legacy endpoints are not fully spec-compliant and can 460 behave unpredictably in the presence of ICE candidates that contain a 461 hostname, potentially leading to ICE failure. Some endpoints may 462 also fail to handle a connectivity check from an address that they 463 have not received in signaling. During the aforementioned 464 experimental testing, the connection rate when interacting with 465 endpoints that provided raw IP addresses (and therefore should be 466 unaffected) decreased by 3% (relative), presumably for these reasons. 468 5. Examples 470 The examples below show how the mDNS technique is used during ICE 471 processing. The first example shows a simple case, the next two 472 examples demonstrate how peer-reflexive candidates for local IP 473 addresses can be created due to timing differences, and the final 474 example shows a real-world case with IPv4, IPv6, and STUN. 476 5.1. Normal Handling 478 In this example, mDNS candidates are exchanged between peers and 479 resolved normally to obtain the corresponding IP addresses. 481 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 482 | | 485 |------- mDNS Candidate N1 ------>| 486 | | 489 |<------ mDNS Candidate N2 -------| 490 | | mDNS name N1> 492 |<=== STUN check to 192.0.2.1 ====| 493 |==== STUN check to 192.0.2.2 ===>| 494 | | 496 The exchange of ICE candidates relies on out-of-band signaling, for 497 example, the SDP Offer/Answer procedure defined in [ICESDP]. In the 498 above example, the candidate attributes in the SDP messages to 499 exchange the mDNS candidates between ICE Agent 1 and 2 are as 500 follows: 502 ICE Agent 1: 504 a=candidate:1 1 udp 2122262783 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 505 54596 typ host 507 ICE Agent 2: 509 a=candidate:1 1 udp 2122262783 2579ef4b-50ae-4bfe-95af-70b3376ecb9c.local 510 61606 typ host 512 5.2. Peer-reflexive Candidate From Slow Signaling 514 In this example, a peer-reflexive candidate is generated because the 515 mDNS candidate is signaled after the STUN checks begin. 517 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 518 | | 521 |------- mDNS Candidate N1 ------>| 522 | | 524 |<=== STUN check to 192.0.2.1 ====| 525 prflx candidate | | 528 |<------ mDNS Candidate N2 -------| 529 | | 531 5.3. Peer-reflexive Candidate From Slow Resolution 533 In this example, a peer-reflexive candidate is generated because the 534 mDNS resolution for name N2 does not complete until after the STUN 535 checks are received. 537 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 538 | | 192.0.2.2> 541 |------- mDNS Candidate N1 ------>| 542 |<------ mDNS Candidate N2 -------| 543 545 . |<=== STUN check to 192.0.2.1 ====| 546 . prflx candidate | | 547 . 192.0.2.2 created | | 548 name | | 549 N2> | | 551 5.4. IPv4, IPv6, and STUN handling 553 This last example demonstrates the overall ICE gathering process for 554 two endpoints, each with a private IPv4 address and a public IPv6 555 address. They preregister their mDNS names to speed up ICE 556 gathering. 558 ICE Agent 1 ICE Agent 2 559 192.168.1.1 STUN 192.168.1.2 560 2001:db8::1 Server 2001:db8::2 561 ---------------------------------------------------------------------- 562 Pre-registration of mDNS names 563 | | | 564 | | | 192.168.1.2> 567 | | | 2001:db8::2> 570 | | | 571 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 572 ICE Agent 1 sends mDNS candidates 573 | | | 574 |------- mDNS Candidate C1.1 ----->| 575 |------- mDNS Candidate C1.2 ----->| 576 | | | 579 | | | 582 | | | 583 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 584 ICE Agent 1 sends server-reflexive candidates 585 | | | 586 <192.168.1.1 |--Binding Req-->| | 587 is 192.0.2.1> |<-Binding Resp--| | 588 <192.0.2.1> |------ srflx Candidate C1.3 ----->| 589 <2001:db8::1 |--Binding Req-->| | 590 is 2001:db8::1> |<-Binding Resp--| | 591 <2001:db8::1> |------ srflx Candidate C1.4 ----->| 593 | | | 594 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 595 ICE Agent 2 sends mDNS candidates, resolution is slow 596 | | | 597 |<------ mDNS Candidate C2.1 ------| 598 |<------ mDNS Candidate C2.2 ------| 599 | | | 601 | | | 603 | | | 604 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 605 ICE Agent 2 sends server-reflexive candidates, resolution completes 606 | | | 607 | |<--Binding Req---| <192.168.1.2 608 | |---Binding Resp->| is 192.0.2.2> 609 |<----- srflx Candidate C2.3 ------| <192.0.2.2> 610 | |<--Binding Req---| <2001:db8::2 611 | |---Binding Resp->| is 2001:db8::2> 612 |<----- srflx Candidate C2.4 ------| <2001:db8::2> 613 | | | 614 <... N2.1 is | | | 615 192.168.1.2> | | | 616 <... N2.2 is | | | 617 2001:db8::2, | | | 618 discard C2.4> | | | 619 | | | 620 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 621 ICE connectivity checks 622 | | | 623 2001:db8::1 |<============= STUN ==============| 2001:db8::2 624 2001:db8::1 |============== STUN =============>| 2001:db8::2 625 192.168.1.1 |<============= STUN ==============| 192.168.1.2 626 192.168.1.1 |============== STUN =============>| 192.168.1.2 627 192.0.2.1 | Failed <-- STUN --------------| 192.168.1.2 628 192.168.1.1 |---------------STUN --> Failed | 192.0.2.2 629 2001:db8::1 |====== STUN(USE-CANDIDATE) ======>| 2001:db8::2 631 Ice Agent 1 candidates: 633 C1.1: candidate:1 1 udp 2122262783 9b36eaac-bb2e-49bb-bb78- 634 21c41c499900.local 10004 typ host 635 C1.2: candidate:2 1 udp 2122262527 76c82649-02d6-4030-8aef- 636 a2ba3a9019d5.local 10006 typ host 637 C1.3: candidate:1 1 udp 1686055167 192.0.2.1 638 30004 typ srflx raddr 0.0.0.0 rport 0 639 C1.4: candidate:2 1 udp 1686054911 2001:db8::1 640 10006 typ srflx raddr 0.0.0.0 rport 0 642 Ice Agent 2 candidates: 644 C2.1: candidate:1 1 udp 2122262783 b977f597-260c-4f70-9ac4- 645 26e69b55f966.local 20004 typ host 646 C2.2: candidate:2 1 udp 2122262527 ac4595a7-7e42-4e85-85e6- 647 c292abe0e681.local 20006 typ host 648 C2.3: candidate:1 1 udp 1686055167 192.0.2.2 649 40004 typ srflx raddr 0.0.0.0 rport 0 650 C2.4: candidate:2 1 udp 1686054911 2001:db8::2 651 20006 typ srflx raddr 0.0.0.0 rport 0 653 6. Security Considerations 655 6.1. mDNS Message Flooding 657 The implementation of this proposal requires the mDNS querying 658 capability of the browser for registering mDNS names or adding remote 659 ICE host candidates with such names. It also requires the mDNS 660 responding capability of either the browser or the operating platform 661 of the browser for registering, removing or resolving mDNS names. In 662 particular, 664 o the registration of name requires optional probing queries and 665 mandatory announcing responses ([RFC6762], Section 8), and this is 666 performed at the beginning of ICE gathering; 668 o the addition of remote ICE host candidates with mDNS names 669 generates mDNS queries for names of each candidate; 671 o the removal of names could happen when the browsing context of the 672 ICE agent is destroyed in an implementation, and goodbye responses 673 should be sent to invalidate records generated by the ICE agent in 674 the local network ([RFC6762], Section 10.1). 676 A malicious Web application could flood the local network with mDNS 677 messages by: 679 o creating browsing contexts that create ICE agents and start 680 gathering of local ICE host candidates; 682 o destroying these local candidates soon after the name registration 683 is done; 685 o adding fictitious remote ICE host candidates with mDNS names. 687 [RFC6762] defines a general per-question and per-record multicast 688 rate limiting rule, in which a given question or record on a given 689 interface cannot be sent less than one second since its last 690 transmission. This rate limiting rule however does not mitigate the 691 above attacks, in which new names, hence new questions or records, 692 are constantly created and sent. Therefore, a browser-wide mDNS 693 message rate limit MUST be provided for all mDNS queries and 694 responses that are dispatched during the ICE candidate gathering and 695 processing described in Section 3. A browser MAY implement more 696 specific rate limits, e.g., to ensure a single origin does not 697 prevent other origins from registering, unregistering, or resolving 698 mDNS names. 700 6.2. Malicious Responses to Deny Name Registration 702 If the optional probing queries are implemented for the name 703 registration, a malicious endpoint in the local network, which is 704 capable of responding mDNS queries, could send responses to block the 705 use of the generated names. This would lead to the discarding of 706 this ICE host candidate as in Step 5 in Section 3.1. 708 The above attack can be mitigated by skipping the probing when 709 registering a name, which also conforms to Section 8 in [RFC6762], 710 given that the name is randomly generated for the probabilistic 711 uniqueness (e.g. a version 4 UUID) in Step 3 in Section 3.1. 712 However, a similar attack can be performed by exploiting the negative 713 responses (defined in [RFC6762], Section 8.1), in which NSEC resource 714 records are sent to claim the nonexistence of records related to the 715 gathered ICE host candidates. 717 The existence of malicious endpoints in the local network poses a 718 generic threat, and requires dedicated protocol suites to mitigate, 719 which is beyond the scope of this proposal. 721 6.3. Unsolicited ICE Communications 723 As noted in Section 4.2 of [RTCWebSecurity], an attacker may use ICE 724 as a way to send unsolicited network traffic to specific endpoints. 725 While this is not specific to mDNS hostname candidates, this 726 technique makes it easier to target devices with well-known mDNS 727 names. 729 As noted in Section 3.2, ICE agents may decide to not resolve mDNS 730 names, for example, if these names are not in the format defined by 731 Section 3.1. 733 7. IANA Considerations 735 This document requires no actions from IANA. 737 8. References 739 8.1. Normative References 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, 743 DOI 10.17487/RFC2119, March 1997, 744 . 746 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 747 Unique IDentifier (UUID) URN Namespace", RFC 4122, 748 DOI 10.17487/RFC4122, July 2005, 749 . 751 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 752 Extensions for Stateless Address Autoconfiguration in 753 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 754 . 756 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 757 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 758 DOI 10.17487/RFC5389, October 2008, 759 . 761 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 762 Relays around NAT (TURN): Relay Extensions to Session 763 Traversal Utilities for NAT (STUN)", RFC 5766, 764 DOI 10.17487/RFC5766, April 2010, 765 . 767 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 768 DOI 10.17487/RFC6762, February 2013, 769 . 771 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 772 Connectivity Establishment (ICE): A Protocol for Network 773 Address Translator (NAT) Traversal", RFC 8445, 774 DOI 10.17487/RFC8445, July 2018, 775 . 777 8.2. Informative References 779 [HTMLSpec] 780 "HTML Living Standard", n.d., 781 . 783 [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ 784 Answer procedures for Interactive Connectivity 785 Establishment (ICE)", April 2018, 786 . 789 [IPHandling] 790 Shieh, G., "WebRTC IP Address Handling Requirements", 791 April 2018, . 794 [Overview] 795 Alvestrand, H., "Overview: Real Time Protocols for 796 Browser-based Applications", November 2017, 797 . 799 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 800 and E. Lear, "Address Allocation for Private Internets", 801 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 802 . 804 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 805 NAT64: Network Address and Protocol Translation from IPv6 806 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 807 April 2011, . 809 [RTCWebSecurity] 810 Rescorla, E., "Security Considerations for WebRTC", 811 January 2018, 812 . 814 [WebRTCSpec] 815 Bruaroey, J., "The WebRTC specification", n.d., 816 . 818 Authors' Addresses 820 Youenn Fablet 821 Apple Inc. 823 Email: youenn@apple.com 825 Jeroen de Borst 826 Google 828 Email: jeroendb@google.com 830 Justin Uberti 831 Google 833 Email: juberti@google.com 835 Qingsi Wang 836 Google 838 Email: qingsi@google.com