idnits 2.17.1 draft-ietf-mmusic-mdns-ice-candidates-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 : ---------------------------------------------------------------------------- ** 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 19, 2020) is 1284 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'WebRTCSpec' is defined on line 801, 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 MMUSIC Y. Fablet 3 Internet-Draft Apple Inc. 4 Intended status: Informational J. de Borst 5 Expires: April 22, 2021 J. Uberti 6 Q. Wang 7 Google 8 October 19, 2020 10 Using Multicast DNS to protect privacy when exposing ICE candidates 11 draft-ietf-mmusic-mdns-ice-candidates-00 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 22, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 . . . . . . . . . . . . . . . 4 64 3.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 6 65 3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2.2. Implementation Guidance . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.1. Normal Handling . . . . . . . . . . . . . . . . . . . . . 10 80 5.2. Peer-reflexive Candidate From Slow Signaling . . . . . . 11 81 5.3. Peer-reflexive Candidate From Slow Resolution . . . . . . 12 82 5.4. IPv4, IPv6, and STUN handling . . . . . . . . . . . . . . 12 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 6.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 14 85 6.2. Malicious Responses to Deny Name Registration . . . . . . 15 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, 153 4, and 6. If it has, skip ahead to Step 7. 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]. 160 5. If registering of the mDNS hostname fails, abort these steps. 161 The candidate is not exposed. 163 6. Store the mDNS hostname and its related IP address in the ICE 164 agent for future reuse. 166 7. 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 6 and prepopulate an 172 ICE agent accordingly. By doing so, only step 7 of the above 173 procedure will be executed at the time of gathering candidates. 175 An implementation may also detect that mDNS is not supported by the 176 available network interfaces. The ICE agent may skip steps 3 and 4 177 and directly decide to not expose the host candidate. 179 This procedure ensures that an mDNS name is used to replace only one 180 IP address. Specifically, an ICE agent using an interface with both 181 IPv4 and IPv6 addresses MUST expose a different mDNS name for each 182 address. 184 3.1.2. Implementation Guidance 185 3.1.2.1. Determining Address Privacy and Server-Reflexive Candidates 187 Naturally, an address that is already exposed to the Internet does 188 not need to be protected by mDNS, as it can be trivially observed by 189 the web server or remote endpoint. However, determining this ahead 190 of time is not straightforward; while the fact that an IPv4 address 191 is private can sometimes be inferred by its value, e.g., whether it 192 is an [RFC1918] address, the reverse is not necessarily true. IPv6 193 addresses present their own complications, e.g., private IPv6 194 addresses as a result of NAT64 [RFC6146]. 196 Instead, the determination of whether an address is public can be 197 reliably made as part of the ICE gathering process. For each mDNS 198 host candidate generated according the guidance above, the usual STUN 199 [RFC5389] request is sent to a STUN server. This can be done for 200 both IPv4 and IPv6 local addresses, provided that the application has 201 configured both IPv4 and IPv6 STUN servers. If the STUN response 202 returns the same value as the local IP address, this indicates the 203 address is in fact public. 205 Regardless of the result, a server-reflexive candidate will be 206 generated; the transport address of this candidate is an IP address 207 and therefore distinct from the hostname transport address of the 208 associated mDNS candidate, and as such MUST NOT be considered 209 redundant per the guidance in [RFC8445], Section 5.1.3. To avoid 210 accidental IP address disclosure, this server-reflexive candidate 211 MUST have its raddr field set to "0.0.0.0"/"::" and its rport field 212 set to "9", as discussed in [ICESDP], Section 9.1. 214 Once an address has been identified as public, the ICE agent MAY 215 cache this information and omit mDNS protection for that address in 216 future ICE gathering phases. 218 3.1.2.2. Special Handling for IPv6 Addresses 220 As noted in [IPHandling], private IPv4 addresses are especially 221 problematic because of their unbounded lifetime. However, the 222 [RFC4941] IPv6 addresses recommended for WebRTC have inherent privacy 223 protections, namely a short lifetime and the lack of any stateful 224 information. Accordingly, implementations MAY choose to not conceal 225 [RFC4941] addresses with mDNS names as a tradeoff for improved peer- 226 to-peer connectivity. 228 3.1.2.3. mDNS Candidate Encoding 230 The mDNS name of an mDNS candidate MUST be used in the connection- 231 address field of its candidate attribute. However, when an mDNS 232 candidate would be the default candidate, typically because there are 233 no other candidates, its mDNS name MUST NOT be used in the 234 connection-address field of the SDP "c=" line, as experimental 235 deployment has indicated that many remote endpoints will fail to 236 handle such a SDP. In this situation, the IP address values 237 "0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and 238 m= lines, similar to how the no-candidates case is handled in 239 [ICESDP], Section 4.3.1. 241 Any candidates exposed to the application via local descriptions MUST 242 be identical to those provided during candidate gathering (i.e., MUST 243 NOT contain private host IP addresses). 245 3.2. ICE Candidate Processing 247 This section outlines how received ICE candidates with mDNS names are 248 processed by ICE agents, and is relevant to all endpoints. 250 3.2.1. Procedure 252 For any remote ICE candidate received by the ICE agent, the following 253 procedure is used: 255 1. If the connection-address field value of the ICE candidate does 256 not end with ".local" or if the value contains more than one ".", 257 then process the candidate as defined in [RFC8445]. 259 2. Otherwise, resolve the candidate using mDNS. 261 3. If it resolves to an IP address, replace the mDNS hostname of the 262 ICE candidate with the resolved IP address and continue 263 processing of the candidate as defined in [RFC8445]. 265 4. Otherwise, ignore the candidate. 267 3.2.2. Implementation Guidance 269 An ICE agent may use a hostname resolver that transparently supports 270 both Multicast and Unicast DNS. In this case the resolution of a 271 ".local" name may happen through Unicast DNS as noted in [RFC6762], 272 Section 3. 274 An ICE agent SHOULD ignore candidates where the hostname resolution 275 returns more than one IP address. 277 An ICE agent MAY add additional restrictions regarding the ICE 278 candidates it will resolve using mDNS, as this mechanism allows 279 attackers to send ICE traffic to devices with well-known mDNS names. 281 3.3. Additional Privacy Considerations 283 The goal of this mechanism is to keep knowledge of private host IP 284 addresses within the ICE agent while continuing to allow the 285 application to transmit ICE candidates. Besides keeping private host 286 IP addresses out of ICE candidates, implementations must take steps 287 to prevent these IP addresses from being exposed to web applications 288 through other means. 290 3.3.1. Statistics 292 Statistics related to ICE candidates that are accessible to the web 293 application MUST NOT contain the IP address of a local or remote mDNS 294 candidate; the mDNS name SHOULD be used instead. 296 In addition, a peer-reflexive remote candidate may be constructed 297 from a remote host IP address as a result of an ICE connectivity 298 check, as described in Section 7.3.1.3 of [RFC8445]. This check may 299 arrive before the candidate due to signaling or mDNS resolution 300 delays, as shown in the examples above. 302 To prevent disclosure of the host IP address to the application in 303 this scenario, statistics related to ICE candidates MUST NOT contain 304 the IP address of any peer-reflexive candidate, unless that IP has 305 already been learned through signaling of a candidate with the same 306 address and either the same or a different port; this includes cases 307 where the signaled candidate is discarded as redundant according to 308 Section 5.1.3 of [RFC8445]. 310 3.3.2. Interactions With TURN Servers 312 When sending data to a TURN [RFC5766] server, the sending client 313 tells the server the destination IP and port for the data. This 314 means that if the client uses TURN to send to an IP that was obtained 315 by mDNS resolution, the TURN server will learn the underlying host IP 316 and port, and this information can then be relayed to the web 317 application, defeating the value of the mDNS wrapping. 319 To prevent disclosure of the host IP address to a TURN server, the 320 ICE agent MUST NOT form candidate pairs between its own relay 321 candidates and remote mDNS candidates. Note that the converse is not 322 an issue; the ICE agent MAY form candidate pairs between its own mDNS 323 candidates and remote relay candidates, as in this situation host IPs 324 will not be sent directly to the TURN server. 326 This restriction has no effect on connectivity; in the cases where 327 host IP addresses are private and need to be wrapped with mDNS names, 328 they will be unreachable from the TURN server, and as noted above, 329 the reverse path will continue to work normally. 331 3.3.3. Generated Name Reuse 333 It is important that use of registered mDNS hostnames is limited in 334 time and/or scope. Indefinitely reusing the same mDNS hostname 335 candidate would provide applications an even more reliable tracking 336 mechanism than the private IP addresses that this specification is 337 designed to hide. In the case of a web application, the use of 338 registered mDNS hostnames SHOULD be scoped by the web application 339 origin, and SHOULD have the lifetime of the page executing the web 340 application. 342 3.3.4. Specific Browsing Contexts 344 As noted in [IPHandling], privacy may be breached if a web 345 application running in two browsing contexts can determine whether it 346 is running on the same device. While the approach in this document 347 prevents the application from directly comparing local private IP 348 addresses, a successful local WebRTC connection can also present a 349 threat to user privacy. Specifically, when the latency of a WebRTC 350 connection latency is close to zero, the probability is high that the 351 two peers are running on the same device. 353 To avoid this issue, browsers SHOULD NOT register mDNS names for 354 WebRTC applications running in a third-party browsing context (i.e., 355 a context that has a different origin than the top-level browsing 356 context), or a private browsing context. 358 3.3.5. Network Interface Enumeration 360 Even when local IP addresses are not exposed, the number of mDNS 361 hostname candidates can still provide a fingerprinting dimension. 362 This is in particular the case for network interfaces with limited 363 connectivity that will not generate server-reflexive or relay 364 candidates. 366 The more mDNS names an endpoint exposes through mDNS hostname 367 candidates, the higher the fingerprinting risk. One countermeasure 368 is to limit this number to a small value. 370 Note that no additional fingerprinting risk is introduced when 371 restricting mDNS hostname candidates to default route only. 373 3.3.6. Monitoring of Sessions 375 A malicious endpoint in the local network may also record other 376 endpoints who are registering, unregistering, and resolving mDNS 377 names. By doing so, they can create a session log that shows which 378 endpoints are communicating, and for how long. If both endpoints in 379 the session are on the same network, the fact they are communicating 380 can be discovered. 382 Mitigation of this threat is beyond the scope of this proposal. 384 4. Potential Limitations 386 4.1. Reduced Connectivity 388 With typical ICE, endpoints on the same network will usually be able 389 to establish a direct connection between their local IP addresses. 390 When using the mDNS technique, a direct connection is still possible, 391 but only if at least one side can properly resolve the provided mDNS 392 candidates. This may not be possible in all scenarios. 394 First, some networks may entirely disable mDNS. Second, mDNS queries 395 have limited scope. On large networks, this may mean that an mDNS 396 name cannot be resolved if the remote endpoint is too many segments 397 away. 399 When mDNS fails, ICE will attempt to fall back to either NAT hairpin, 400 if supported, or TURN relay if not. This may result in reduced 401 connectivity, reduced throughput and increased latency, as well as 402 increased cost in case of TURN relay. 404 During experimental testing of the mDNS technique across a set of 405 known mDNS-aware endpoints that had configured a STUN server but not 406 a TURN server, the observed impact to ICE connection rate was 2% 407 (relative) when mDNS was enabled on both sides, compared to when mDNS 408 was only enabled on one side. In this testing, the percentage of 409 connections that required STUN (i.e., went through a NAT) increased 410 from 94% to 97%, indicating that mDNS succeeded about half the time, 411 and fell back to NAT hairpin for the remainder. The most likely 412 explanation for the overall connection rate drop is that hairpinning 413 failed in some cases. 415 One potential mitigation, as discussed in Section 3.3, is to not 416 conceal candidates created from [RFC4941] IPv6 addresses. This 417 permits connectivity even in large internal networks or where mDNS is 418 disabled. Future versions of this document will include experimental 419 data regarding this option. 421 4.2. Connection Setup Latency 423 As noted in Section 3, ICE agents using the mDNS technique are 424 responsible for registering and resolving mDNS names as part of the 425 ICE process. These steps may delay establishment of a direct peer- 426 to-peer connection, compared to when raw local IP addresses are used. 428 Given that these mDNS registrations and queries are typically 429 occurring on a local network, any associated delays should be small. 430 Also, as noted in Section 3.1, pre-registration can be employed to 431 eliminate gathering delays entirely. 433 4.3. Backward Compatibility 435 For the most part, backward compatibility does not present a 436 significant issue for the mDNS technique. When an endpoint that 437 supports mDNS communicates with an endpoint that does not, the legacy 438 endpoint will still provide its local IP addresses, and accordingly a 439 direct connection can still be attempted, even though the legacy 440 endpoint cannot resolve the mDNS names provided by the new endpoint. 441 In the event the legacy endpoint attempts to resolve mDNS names using 442 Unicast DNS, this may cause ICE to take somewhat longer to fully 443 complete, but should not have any effect on connectivity or 444 connection setup time. 446 However, some legacy endpoints are not fully spec-compliant and can 447 behave unpredictably in the presence of ICE candidates that contain a 448 hostname, potentially leading to ICE failure. Some endpoints may 449 also fail to handle a connectivity check from an address that they 450 have not received in signaling. During the aforementioned 451 experimental testing, the connection rate when interacting with 452 endpoints that provided raw IP addresses (and therefore should be 453 unaffected) decreased by 3% (relative), presumably for these reasons. 455 5. Examples 457 The examples below show how the mDNS technique is used during ICE 458 processing. The first example shows a simple case, the next two 459 examples demonstrate how peer-reflexive candidates for local IP 460 addresses can be created due to timing differences, and the final 461 example shows a real-world case with IPv4, IPv6, and STUN. 463 5.1. Normal Handling 465 In this example, mDNS candidates are exchanged between peers and 466 resolved normally to obtain the corresponding IP addresses. 468 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 469 | | 472 |------- mDNS Candidate N1 ------>| 473 | | 476 |<------ mDNS Candidate N2 -------| 477 | | mDNS name N1> 479 |<=== STUN check to 192.0.2.1 ====| 480 |==== STUN check to 192.0.2.2 ===>| 481 | | 483 The exchange of ICE candidates relies on out-of-band signaling, for 484 example, the SDP Offer/Answer procedure defined in [ICESDP]. In the 485 above example, the candidate attributes in the SDP messages to 486 exchange the mDNS candidates between ICE Agent 1 and 2 are as 487 follows: 489 ICE Agent 1: 491 a=candidate:1 1 udp 2122262783 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 492 54596 typ host 494 ICE Agent 2: 496 a=candidate:1 1 udp 2122262783 2579ef4b-50ae-4bfe-95af-70b3376ecb9c.local 497 61606 typ host 499 5.2. Peer-reflexive Candidate From Slow Signaling 501 In this example, a peer-reflexive candidate is generated because the 502 mDNS candidate is signaled after the STUN checks begin. 504 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 505 | | 508 |------- mDNS Candidate N1 ------>| 509 | | 511 |<=== STUN check to 192.0.2.1 ====| 512 prflx candidate | | 515 |<------ mDNS Candidate N2 -------| 516 | | 518 5.3. Peer-reflexive Candidate From Slow Resolution 520 In this example, a peer-reflexive candidate is generated because the 521 mDNS resolution for name N2 does not complete until after the STUN 522 checks are received. 524 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 525 | | 192.0.2.2> 528 |------- mDNS Candidate N1 ------>| 529 |<------ mDNS Candidate N2 -------| 530 532 . |<=== STUN check to 192.0.2.1 ====| 533 . prflx candidate | | 534 . 192.0.2.2 created | | 535 name | | 536 N2> | | 538 5.4. IPv4, IPv6, and STUN handling 540 This last example demonstrates the overall ICE gathering process for 541 two endpoints, each with a private IPv4 address and a public IPv6 542 address. They preregister their mDNS names to speed up ICE 543 gathering. 545 ICE Agent 1 ICE Agent 2 546 192.168.1.1 STUN 192.168.1.2 547 2001:db8::1 Server 2001:db8::2 548 ---------------------------------------------------------------------- 549 Pre-registration of mDNS names 550 | | | 551 | | | 192.168.1.2> 554 | | | 2001:db8::2> 557 | | | 558 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 559 ICE Agent 1 sends mDNS candidates 560 | | | 561 |------- mDNS Candidate C1.1 ----->| 562 |------- mDNS Candidate C1.2 ----->| 563 | | | 566 | | | 569 | | | 570 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 571 ICE Agent 1 sends server-reflexive candidates 572 | | | 573 <192.168.1.1 |--Binding Req-->| | 574 is 192.0.2.1> |<-Binding Resp--| | 575 <192.0.2.1> |------ srflx Candidate C1.3 ----->| 576 <2001:db8::1 |--Binding Req-->| | 577 is 2001:db8::1> |<-Binding Resp--| | 578 <2001:db8::1> |------ srflx Candidate C1.4 ----->| 580 | | | 581 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 582 ICE Agent 2 sends mDNS candidates, resolution is slow 583 | | | 584 |<------ mDNS Candidate C2.1 ------| 585 |<------ mDNS Candidate C2.2 ------| 586 | | | 588 | | | 590 | | | 591 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 592 ICE Agent 2 sends server-reflexive candidates, resolution completes 593 | | | 594 | |<--Binding Req---| <192.168.1.2 595 | |---Binding Resp->| is 192.0.2.2> 596 |<----- srflx Candidate C2.3 ------| <192.0.2.2> 597 | |<--Binding Req---| <2001:db8::2 598 | |---Binding Resp->| is 2001:db8::2> 599 |<----- srflx Candidate C2.4 ------| <2001:db8::2> 600 | | | 601 <... N2.1 is | | | 602 192.168.1.2> | | | 603 <... N2.2 is | | | 604 2001:db8::2, | | | 605 discard C2.4> | | | 606 | | | 607 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 608 ICE connectivity checks 609 | | | 610 2001:db8::1 |<============= STUN ==============| 2001:db8::2 611 2001:db8::1 |============== STUN =============>| 2001:db8::2 612 192.168.1.1 |<============= STUN ==============| 192.168.1.2 613 192.168.1.1 |============== STUN =============>| 192.168.1.2 614 192.0.2.1 | Failed <-- STUN --------------| 192.168.1.2 615 192.168.1.1 |---------------STUN --> Failed | 192.0.2.2 616 2001:db8::1 |====== STUN(USE-CANDIDATE) ======>| 2001:db8::2 618 Ice Agent 1 candidates: 620 C1.1: candidate:1 1 udp 2122262783 9b36eaac-bb2e-49bb-bb78- 621 21c41c499900.local 10004 typ host 622 C1.2: candidate:2 1 udp 2122262527 76c82649-02d6-4030-8aef- 623 a2ba3a9019d5.local 10006 typ host 624 C1.3: candidate:1 1 udp 1686055167 192.0.2.1 625 30004 typ srflx raddr 0.0.0.0 rport 0 626 C1.4: candidate:2 1 udp 1686054911 2001:db8::1 627 10006 typ srflx raddr 0.0.0.0 rport 0 629 Ice Agent 2 candidates: 631 C2.1: candidate:1 1 udp 2122262783 b977f597-260c-4f70-9ac4- 632 26e69b55f966.local 20004 typ host 633 C2.2: candidate:2 1 udp 2122262527 ac4595a7-7e42-4e85-85e6- 634 c292abe0e681.local 20006 typ host 635 C2.3: candidate:1 1 udp 1686055167 192.0.2.2 636 40004 typ srflx raddr 0.0.0.0 rport 0 637 C2.4: candidate:2 1 udp 1686054911 2001:db8::2 638 20006 typ srflx raddr 0.0.0.0 rport 0 640 6. Security Considerations 642 6.1. mDNS Message Flooding 644 The implementation of this proposal requires the mDNS querying 645 capability of the browser for registering mDNS names or adding remote 646 ICE host candidates with such names. It also requires the mDNS 647 responding capability of either the browser or the operating platform 648 of the browser for registering, removing or resolving mDNS names. In 649 particular, 651 o the registration of name requires optional probing queries and 652 mandatory announcing responses ([RFC6762], Section 8), and this is 653 performed at the beginning of ICE gathering; 655 o the addition of remote ICE host candidates with mDNS names 656 generates mDNS queries for names of each candidate; 658 o the removal of names could happen when the browsing context of the 659 ICE agent is destroyed in an implementation, and goodbye responses 660 should be sent to invalidate records generated by the ICE agent in 661 the local network ([RFC6762], Section 10.1). 663 A malicious Web application could flood the local network with mDNS 664 messages by: 666 o creating browsing contexts that create ICE agents and start 667 gathering of local ICE host candidates; 669 o destroying these local candidates soon after the name registration 670 is done; 672 o adding fictitious remote ICE host candidates with mDNS names. 674 [RFC6762] defines a general per-question and per-record multicast 675 rate limiting rule, in which a given question or record on a given 676 interface cannot be sent less than one second since its last 677 transmission. This rate limiting rule however does not mitigate the 678 above attacks, in which new names, hence new questions or records, 679 are constantly created and sent. Therefore, a browser-wide mDNS 680 message rate limit MUST be provided for all mDNS queries and 681 responses that are dispatched during the ICE candidate gathering and 682 processing described in Section 3. A browser MAY implement more 683 specific rate limits, e.g., to ensure a single origin does not 684 prevent other origins from registering, unregistering, or resolving 685 mDNS names. 687 6.2. Malicious Responses to Deny Name Registration 689 If the optional probing queries are implemented for the name 690 registration, a malicious endpoint in the local network, which is 691 capable of responding mDNS queries, could send responses to block the 692 use of the generated names. This would lead to the discarding of 693 this ICE host candidate as in Step 5 in Section 3.1. 695 The above attack can be mitigated by skipping the probing when 696 registering a name, which also conforms to Section 8 in [RFC6762], 697 given that the name is randomly generated for the probabilistic 698 uniqueness (e.g. a version 4 UUID) in Step 3 in Section 3.1. 699 However, a similar attack can be performed by exploiting the negative 700 responses (defined in [RFC6762], Section 8.1), in which NSEC resource 701 records are sent to claim the nonexistence of records related to the 702 gathered ICE host candidates. 704 The existence of malicious endpoints in the local network poses a 705 generic threat, and requires dedicated protocol suites to mitigate, 706 which is beyond the scope of this proposal. 708 6.3. Unsolicited ICE Communications 710 As noted in Section 4.2 of [RTCWebSecurity], an attacker may use ICE 711 as a way to send unsolicited network traffic to specific endpoints. 712 While this is not specific to mDNS hostname candidates, this 713 technique makes it easier to target devices with well-known mDNS 714 names. 716 As noted in Section 3.2, ICE agents may decide to not resolve mDNS 717 names, for example, if these names are not in the format defined by 718 Section 3.1. 720 7. IANA Considerations 722 This document requires no actions from IANA. 724 8. References 726 8.1. Normative References 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, 730 DOI 10.17487/RFC2119, March 1997, 731 . 733 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 734 Unique IDentifier (UUID) URN Namespace", RFC 4122, 735 DOI 10.17487/RFC4122, July 2005, 736 . 738 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 739 Extensions for Stateless Address Autoconfiguration in 740 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 741 . 743 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 744 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 745 DOI 10.17487/RFC5389, October 2008, 746 . 748 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 749 Relays around NAT (TURN): Relay Extensions to Session 750 Traversal Utilities for NAT (STUN)", RFC 5766, 751 DOI 10.17487/RFC5766, April 2010, 752 . 754 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 755 DOI 10.17487/RFC6762, February 2013, 756 . 758 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 759 Connectivity Establishment (ICE): A Protocol for Network 760 Address Translator (NAT) Traversal", RFC 8445, 761 DOI 10.17487/RFC8445, July 2018, 762 . 764 8.2. Informative References 766 [HTMLSpec] 767 "HTML Living Standard", n.d., 768 . 770 [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ 771 Answer procedures for Interactive Connectivity 772 Establishment (ICE)", April 2018, 773 . 776 [IPHandling] 777 Shieh, G., "WebRTC IP Address Handling Requirements", 778 April 2018, . 781 [Overview] 782 Alvestrand, H., "Overview: Real Time Protocols for 783 Browser-based Applications", November 2017, 784 . 786 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 787 and E. Lear, "Address Allocation for Private Internets", 788 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 789 . 791 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 792 NAT64: Network Address and Protocol Translation from IPv6 793 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 794 April 2011, . 796 [RTCWebSecurity] 797 Rescorla, E., "Security Considerations for WebRTC", 798 January 2018, 799 . 801 [WebRTCSpec] 802 Bruaroey, J., "The WebRTC specification", n.d., 803 . 805 Authors' Addresses 807 Youenn Fablet 808 Apple Inc. 810 Email: youenn@apple.com 812 Jeroen de Borst 813 Google 815 Email: jeroendb@google.com 817 Justin Uberti 818 Google 820 Email: juberti@google.com 822 Qingsi Wang 823 Google 825 Email: qingsi@google.com