idnits 2.17.1 draft-ietf-mmusic-mdns-ice-candidates-01.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. -- The draft header indicates that this document updates RFC8839, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2021) is 1143 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'WebRTCSpec' is defined on line 848, 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Y. Fablet 3 Internet-Draft Apple Inc. 4 Updates: 8839 (if approved) J. de Borst 5 Intended status: Informational J. Uberti 6 Expires: September 10, 2021 Q. Wang 7 Google 8 March 09, 2021 10 Using Multicast DNS to protect privacy when exposing ICE candidates 11 draft-ietf-mmusic-mdns-ice-candidates-01 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 September 10, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 . . . . . . . . . . . 8 70 3.3.3. Generated Name Reuse . . . . . . . . . . . . . . . . 8 71 3.3.4. Specific Browsing Contexts . . . . . . . . . . . . . 8 72 3.3.5. Network Interface Enumeration . . . . . . . . . . . . 9 73 3.3.6. Monitoring of Sessions . . . . . . . . . . . . . . . 9 74 4. Update to RFC 8839 . . . . . . . . . . . . . . . . . . . . . 9 75 5. Potential Limitations . . . . . . . . . . . . . . . . . . . . 10 76 5.1. Reduced Connectivity . . . . . . . . . . . . . . . . . . 10 77 5.2. Connection Setup Latency . . . . . . . . . . . . . . . . 10 78 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 11 79 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 6.1. Normal Handling . . . . . . . . . . . . . . . . . . . . . 11 81 6.2. Peer-reflexive Candidate From Slow Signaling . . . . . . 12 82 6.3. Peer-reflexive Candidate From Slow Resolution . . . . . . 13 83 6.4. IPv4, IPv6, and STUN handling . . . . . . . . . . . . . . 13 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 7.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 15 86 7.2. Malicious Responses to Deny Name Registration . . . . . . 16 87 7.3. Unsolicited ICE Communications . . . . . . . . . . . . . 17 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 9.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 As detailed in [IPHandling], exposing client private IP addresses by 97 default to web applications maximizes the probability of successfully 98 creating direct peer-to-peer connections between clients, but creates 99 a significant surface for user fingerprinting. [IPHandling] 100 recognizes this issue, but also admits that there is no current 101 solution to this problem; implementations that choose to use Mode 3 102 to address the privacy concerns often suffer from failing or 103 suboptimal connections in WebRTC applications. This is particularly 104 an issue on unmanaged networks, typically homes or small offices, 105 where NAT loopback may not be supported. 107 This document proposes an overall solution to this problem by 108 extending [ICESDP] to allow ICE implementations to register ephemeral 109 mDNS [RFC6762] names for local private IP addresses, and then provide 110 those names, rather than the IP addresses, in their ICE candidates. 111 While this technique is intended to benefit WebRTC implementations in 112 web browsers, by preventing collection of private IP addresses by 113 arbitrary web pages, it can also be used by any endpoint that wants 114 to avoid disclosing information about its local network to remote 115 peers on other networks. 117 WebRTC and WebRTC-compatible endpoints [Overview] that receive ICE 118 candidates with mDNS names will resolve these names to IP addresses 119 and perform ICE processing as usual. In the case where the endpoint 120 is a web application, the WebRTC implementation will manage this 121 resolution internally and will not disclose the actual IP addresses 122 to the application. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Description 132 This section uses the concept of ICE agent as defined in [RFC8445]. 133 In the remainder of the document, it is assumed that each browsing 134 context (as defined in Section 7.1 of [HTMLSpec]) has its own ICE 135 agent. 137 3.1. ICE Candidate Gathering 139 This section outlines how mDNS should be used by ICE agents to 140 conceal local IP addresses. 142 3.1.1. Procedure 144 For each host candidate gathered by an ICE agent as part of the 145 gathering process described in [RFC8445], Section 5.1.1, the 146 candidate is handled as described below. 148 1. Check whether this IP address satisfies the ICE agent's policy 149 regarding whether an address is safe to expose. If so, expose 150 the candidate and abort this process. 152 2. Check whether the ICE agent has previously generated, registered, 153 and stored an mDNS hostname for this IP address as per steps 3 to 154 5. If it has, skip ahead to step 6. 156 3. Generate a unique mDNS hostname. The unique name MUST consist of 157 a version 4 UUID as defined in [RFC4122], followed by ".local". 159 4. Register the candidate's mDNS hostname as defined in [RFC6762]. 160 The ICE agent SHOULD send an mDNS announcement for the hostname, 161 but as the hostname is expected to be unique, the ICE agent 162 SHOULD skip probing of the hostname. 164 5. Store the mDNS hostname and its related IP address in the ICE 165 agent for future reuse. 167 6. Replace the IP address of the ICE candidate with its mDNS 168 hostname and provide the candidate to the web application. 170 ICE agents can implement this procedure in any way as long as it 171 produces equivalent results. An implementation may for instance pre- 172 register mDNS hostnames by executing steps 3 to 5 and prepopulate an 173 ICE agent accordingly. By doing so, only step 6 of the above 174 procedure will be executed at the time of gathering candidates. 176 In order to prevent web applications from using this mechanism to 177 query for mDNS support in the local network, the ICE agent SHOULD 178 still provide mDNS candidates in step 6 even if the local network 179 does not support mDNS or mDNS registration fails in step 4. 181 This procedure ensures that an mDNS name is used to replace only one 182 IP address. Specifically, an ICE agent using an interface with both 183 IPv4 and IPv6 addresses MUST expose a different mDNS name for each 184 address. 186 3.1.2. Implementation Guidance 188 3.1.2.1. Registration 190 Sending the mDNS announcement to the network can be delayed, for 191 instance due to rate limits. An ICE agent SHOULD provide the 192 candidate to the web application as soon as its mDNS name is 193 generated, regardless of whether the announcement has been sent on 194 the network. 196 3.1.2.2. Determining Address Privacy and Server-Reflexive Candidates 198 Naturally, an address that is already exposed to the Internet does 199 not need to be protected by mDNS, as it can be trivially observed by 200 the web server or remote endpoint. However, determining this ahead 201 of time is not straightforward; while the fact that an IPv4 address 202 is private can sometimes be inferred by its value, e.g., whether it 203 is an [RFC1918] address, the reverse is not necessarily true. IPv6 204 addresses present their own complications, e.g., private IPv6 205 addresses as a result of NAT64 [RFC6146]. 207 Instead, the determination of whether an address is public can be 208 reliably made as part of the ICE gathering process. For each mDNS 209 host candidate generated according the guidance above, the usual STUN 210 [RFC5389] request is sent to a STUN server. This can be done for 211 both IPv4 and IPv6 local addresses, provided that the application has 212 configured both IPv4 and IPv6 STUN servers. If the STUN response 213 returns the same value as the local IP address, this indicates the 214 address is in fact public. 216 Regardless of the result, a server-reflexive candidate will be 217 generated; the transport address of this candidate is an IP address 218 and therefore distinct from the hostname transport address of the 219 associated mDNS candidate, and as such MUST NOT be considered 220 redundant per the guidance in [RFC8445], Section 5.1.3. To avoid 221 accidental IP address disclosure, this server-reflexive candidate 222 MUST have its raddr field set to "0.0.0.0"/"::" and its rport field 223 set to "9", as discussed in [ICESDP], Section 9.1. 225 Once an address has been identified as public, the ICE agent MAY 226 cache this information and omit mDNS protection for that address in 227 future ICE gathering phases. 229 3.1.2.3. Special Handling for IPv6 Addresses 231 As noted in [IPHandling], private IPv4 addresses are especially 232 problematic because of their unbounded lifetime. However, the 233 [RFC4941] IPv6 addresses recommended for WebRTC have inherent privacy 234 protections, namely a short lifetime and the lack of any stateful 235 information. Accordingly, implementations MAY choose to not conceal 236 [RFC4941] addresses with mDNS names as a tradeoff for improved peer- 237 to-peer connectivity. 239 3.1.2.4. mDNS Candidate Encoding 241 The mDNS name of an mDNS candidate MUST be used in the connection- 242 address field of its candidate attribute. However, when an mDNS 243 candidate would be the default candidate, typically because there are 244 no other candidates, its mDNS name MUST NOT be used in the 245 connection-address field of the SDP "c=" line, as experimental 246 deployment has indicated that many remote endpoints will fail to 247 handle such a SDP. In this situation, the IP address values 248 "0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and 249 m= lines, similar to how the no-candidates case is handled in 250 [ICESDP], Section 4.3.1. 252 Any candidates exposed to the application via local descriptions MUST 253 be identical to those provided during candidate gathering (i.e., MUST 254 NOT contain private host IP addresses). 256 3.2. ICE Candidate Processing 258 This section outlines how received ICE candidates with mDNS names are 259 processed by ICE agents, and is relevant to all endpoints. 261 3.2.1. Procedure 263 For any remote ICE candidate received by the ICE agent, the following 264 procedure is used: 266 1. If the connection-address field value of the ICE candidate does 267 not end with ".local" or if the value contains more than one ".", 268 then process the candidate as defined in [RFC8445]. 270 2. If the ICE candidate policy is "relay", as defined in [JSEP], 271 ignore the candidate. 273 3. Otherwise, resolve the candidate using mDNS. The ICE agent 274 SHOULD set the unicast-response bit of the corresponding mDNS 275 query message; this minimizes multicast traffic, as the response 276 is probably only useful to the querying node. 278 4. If it resolves to an IP address, replace the mDNS hostname of the 279 ICE candidate with the resolved IP address and continue 280 processing of the candidate as defined in [RFC8445]. 282 5. Otherwise, ignore the candidate. 284 3.2.2. Implementation Guidance 286 An ICE agent may use a hostname resolver that transparently supports 287 both Multicast and Unicast DNS. In this case the resolution of a 288 ".local" name may happen through Unicast DNS as noted in [RFC6762], 289 Section 3. 291 An ICE agent SHOULD ignore candidates where the hostname resolution 292 returns more than one IP address. 294 An ICE agent MAY add additional restrictions regarding the ICE 295 candidates it will resolve using mDNS, as this mechanism allows 296 attackers to send ICE traffic to devices with well-known mDNS names. 297 In particular, ICE agents SHOULD NOT resolve mDNS names if they are 298 not in the format defined by Section 3.1. 300 3.3. Additional Privacy Considerations 302 The goal of this mechanism is to keep knowledge of private host IP 303 addresses within the ICE agent while continuing to allow the 304 application to transmit ICE candidates. Besides keeping private host 305 IP addresses out of ICE candidates, implementations must take steps 306 to prevent these IP addresses from being exposed to web applications 307 through other means. 309 3.3.1. Statistics 311 Statistics related to ICE candidates that are accessible to the web 312 application MUST NOT contain the IP address of a local or remote mDNS 313 candidate; the mDNS name SHOULD be used instead. 315 Statistics SHOULD NOT leak whether the mDNS resolution succeeds or 316 fails. For that reason, RTCIceCandidateStats objects as defined in 317 [WebRTCStats] SHOULD be generated for any remote mDNS candidate 318 submitted to the ICE agent, even if the mDNS candidate is ignored as 319 part of Section 3.2. An implementation strategy to obfuscate the 320 address of an mDNS candidate in the statistics, regardless if it is 321 resolved or not, is to replace the mDNS hostname of the ICE candidate 322 with IP values "0.0.0.0" or "::". 324 In addition, a peer-reflexive remote candidate may be constructed 325 from a remote host IP address as a result of an ICE connectivity 326 check, as described in Section 7.3.1.3 of [RFC8445]. This check may 327 arrive before the candidate due to signaling or mDNS resolution 328 delays, as shown in the examples above. 330 To prevent disclosure of the host IP address to the application in 331 this scenario, statistics related to ICE candidates MUST NOT contain 332 the IP address of any peer-reflexive candidate, unless that IP has 333 already been learned through signaling of a candidate with the same 334 address and either the same or a different port; this includes cases 335 where the signaled candidate is discarded as redundant according to 336 Section 5.1.3 of [RFC8445]. 338 3.3.2. Interactions With TURN Servers 340 When sending data to a TURN [RFC5766] server, the sending client 341 tells the server the destination IP and port for the data. This 342 means that if the client uses TURN to send to an IP that was obtained 343 by mDNS resolution, the TURN server will learn the underlying host IP 344 and port, and this information can then be relayed to the web 345 application, defeating the value of the mDNS wrapping. 347 To prevent disclosure of the host IP address to a TURN server, the 348 ICE agent MUST NOT form candidate pairs between its own relay 349 candidates and remote mDNS candidates. This restriction applies to 350 all remote mDNS candidate types, not just host candidates; mDNS 351 candidates can be clearly identified from their connection-address 352 fields. Note also that the converse is not an issue; the ICE agent 353 MAY form candidate pairs between its own mDNS candidates and remote 354 relay candidates, as in this situation host IPs will not be sent 355 directly to the TURN server. 357 This restriction has no effect on connectivity; in the cases where 358 host IP addresses are private and need to be wrapped with mDNS names, 359 they will be unreachable from the TURN server, and as noted above, 360 the reverse path will continue to work normally. 362 3.3.3. Generated Name Reuse 364 It is important that use of registered mDNS hostnames is limited in 365 time and/or scope. Indefinitely reusing the same mDNS hostname 366 candidate would provide applications an even more reliable tracking 367 mechanism than the private IP addresses that this specification is 368 designed to hide. In the case of a web application, the use of 369 registered mDNS hostnames SHOULD be scoped by the web application 370 origin, and SHOULD have the lifetime of the page executing the web 371 application. 373 3.3.4. Specific Browsing Contexts 375 As noted in [IPHandling], privacy may be breached if a web 376 application running in two browsing contexts can determine whether it 377 is running on the same device. While the approach in this document 378 prevents the application from directly comparing local private IP 379 addresses, a successful local WebRTC connection can also present a 380 threat to user privacy. Specifically, when the latency of a WebRTC 381 connection latency is close to zero, the probability is high that the 382 two peers are running on the same device. 384 To avoid this issue, browsers SHOULD NOT register mDNS names for 385 WebRTC applications running in a third-party browsing context (i.e., 386 a context that has a different origin than the top-level browsing 387 context), or a private browsing context. 389 3.3.5. Network Interface Enumeration 391 Even when local IP addresses are not exposed, the number of mDNS 392 hostname candidates can still provide a fingerprinting dimension. 393 This is in particular the case for network interfaces with limited 394 connectivity that will not generate server-reflexive or relay 395 candidates. 397 The more mDNS names an endpoint exposes through mDNS hostname 398 candidates, the higher the fingerprinting risk. One countermeasure 399 is to limit this number to a small value. 401 Note that no additional fingerprinting risk is introduced when 402 restricting mDNS hostname candidates to default route only. 404 3.3.6. Monitoring of Sessions 406 A malicious endpoint in the local network may also record other 407 endpoints who are registering, unregistering, and resolving mDNS 408 names. By doing so, they can create a session log that shows which 409 endpoints are communicating, and for how long. If both endpoints in 410 the session are on the same network, the fact they are communicating 411 can be discovered. 413 Mitigation of this threat is beyond the scope of this proposal. 415 4. Update to RFC 8839 417 Section 5.1 of [ICESDP] states: 419 An agent generating local candidates MUST NOT use FQDN addresses. 420 An agent processing remote candidates MUST ignore candidate lines 421 that include candidates with FQDN or IP address versions that are 422 not supported or recognized. 424 This document extends [ICESDP] to specifically allow the generation 425 and processing of ICE candidates with the ".local" FQDNs defined in 426 {gathering}. The restrictions on other FQDNs are unaffected. 428 5. Potential Limitations 430 5.1. Reduced Connectivity 432 With typical ICE, endpoints on the same network will usually be able 433 to establish a direct connection between their local IP addresses. 434 When using the mDNS technique, a direct connection is still possible, 435 but only if at least one side can properly resolve the provided mDNS 436 candidates. This may not be possible in all scenarios. 438 First, some networks may entirely disable mDNS. Second, mDNS queries 439 have limited scope. On large networks, this may mean that an mDNS 440 name cannot be resolved if the remote endpoint is too many segments 441 away. 443 When mDNS fails, ICE will attempt to fall back to either NAT hairpin, 444 if supported, or TURN relay if not. This may result in reduced 445 connectivity, reduced throughput and increased latency, as well as 446 increased cost in case of TURN relay. 448 During experimental testing of the mDNS technique across a set of 449 known mDNS-aware endpoints that had configured a STUN server but not 450 a TURN server, the observed impact to ICE connection rate was 2% 451 (relative) when mDNS was enabled on both sides, compared to when mDNS 452 was only enabled on one side. In this testing, the percentage of 453 connections that required STUN (i.e., went through a NAT) increased 454 from 94% to 97%, indicating that mDNS succeeded about half the time, 455 and fell back to NAT hairpin for the remainder. The most likely 456 explanation for the overall connection rate drop is that hairpinning 457 failed in some cases. 459 5.2. Connection Setup Latency 461 As noted in Section 3, ICE agents using the mDNS technique are 462 responsible for registering and resolving mDNS names as part of the 463 ICE process. These steps may delay establishment of a direct peer- 464 to-peer connection, compared to when raw local IP addresses are used. 466 Given that these mDNS registrations and queries are typically 467 occurring on a local network, any associated delays should be small. 468 Also, as noted in Section 3.1, pre-registration can be employed to 469 eliminate gathering delays entirely. 471 5.3. Backward Compatibility 473 For the most part, backward compatibility does not present a 474 significant issue for the mDNS technique. When an endpoint that 475 supports mDNS communicates with an endpoint that does not, the legacy 476 endpoint will still provide its local IP addresses, and accordingly a 477 direct connection can still be attempted, even though the legacy 478 endpoint cannot resolve the mDNS names provided by the new endpoint. 479 In the event the legacy endpoint attempts to resolve mDNS names using 480 Unicast DNS, this may cause ICE to take somewhat longer to fully 481 complete, but should not have any effect on connectivity or 482 connection setup time. 484 However, some legacy endpoints are not fully spec-compliant and can 485 behave unpredictably in the presence of ICE candidates that contain a 486 hostname, potentially leading to ICE failure. Some endpoints may 487 also fail to handle a connectivity check from an address that they 488 have not received in signaling. During the aforementioned 489 experimental testing, the connection rate when interacting with 490 endpoints that provided raw IP addresses (and therefore should be 491 unaffected) decreased by 3% (relative), presumably for these reasons. 493 6. Examples 495 The examples below show how the mDNS technique is used during ICE 496 processing. The first example shows a simple case, the next two 497 examples demonstrate how peer-reflexive candidates for local IP 498 addresses can be created due to timing differences, and the final 499 example shows a real-world case with IPv4, IPv6, and STUN. 501 6.1. Normal Handling 503 In this example, mDNS candidates are exchanged between peers and 504 resolved normally to obtain the corresponding IP addresses. 506 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 507 | | 510 |------- mDNS Candidate N1 ------>| 511 | | 514 |<------ mDNS Candidate N2 -------| 515 | | mDNS name N1> 517 |<=== STUN check to 192.0.2.1 ====| 518 |==== STUN check to 192.0.2.2 ===>| 519 | | 521 The exchange of ICE candidates relies on out-of-band signaling, for 522 example, the SDP Offer/Answer procedure defined in [ICESDP]. In the 523 above example, the candidate attributes in the SDP messages to 524 exchange the mDNS candidates between ICE Agent 1 and 2 are as 525 follows: 527 ICE Agent 1: 529 a=candidate:1 1 udp 2122262783 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 530 54596 typ host 532 ICE Agent 2: 534 a=candidate:1 1 udp 2122262783 2579ef4b-50ae-4bfe-95af-70b3376ecb9c.local 535 61606 typ host 537 6.2. Peer-reflexive Candidate From Slow Signaling 539 In this example, a peer-reflexive candidate is generated because the 540 mDNS candidate is signaled after the STUN checks begin. 542 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 543 | | 546 |------- mDNS Candidate N1 ------>| 547 | | 549 |<=== STUN check to 192.0.2.1 ====| 550 prflx candidate | | 553 |<------ mDNS Candidate N2 -------| 554 | | 556 6.3. Peer-reflexive Candidate From Slow Resolution 558 In this example, a peer-reflexive candidate is generated because the 559 mDNS resolution for name N2 does not complete until after the STUN 560 checks are received. 562 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 563 | | 192.0.2.2> 566 |------- mDNS Candidate N1 ------>| 567 |<------ mDNS Candidate N2 -------| 568 570 . |<=== STUN check to 192.0.2.1 ====| 571 . prflx candidate | | 572 . 192.0.2.2 created | | 573 name | | 574 N2> | | 576 6.4. IPv4, IPv6, and STUN handling 578 This last example demonstrates the overall ICE gathering process for 579 two endpoints, each with a private IPv4 address and a public IPv6 580 address. They preregister their mDNS names to speed up ICE 581 gathering. 583 ICE Agent 1 ICE Agent 2 584 192.168.1.1 STUN 192.168.1.2 585 2001:db8::1 Server 2001:db8::2 586 ---------------------------------------------------------------------- 587 Pre-registration of mDNS names 588 | | | 589 | | | 192.168.1.2> 592 | | | 2001:db8::2> 595 | | | 596 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 597 ICE Agent 1 sends mDNS candidates 598 | | | 599 |------- mDNS Candidate C1.1 ----->| 600 |------- mDNS Candidate C1.2 ----->| 601 | | | 604 | | | 607 | | | 608 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 609 ICE Agent 1 sends server-reflexive candidates 610 | | | 611 <192.168.1.1 |--Binding Req-->| | 612 is 192.0.2.1> |<-Binding Resp--| | 613 <192.0.2.1> |------ srflx Candidate C1.3 ----->| 614 <2001:db8::1 |--Binding Req-->| | 615 is 2001:db8::1> |<-Binding Resp--| | 616 <2001:db8::1> |------ srflx Candidate C1.4 ----->| 618 | | | 619 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 620 ICE Agent 2 sends mDNS candidates, resolution is slow 621 | | | 622 |<------ mDNS Candidate C2.1 ------| 623 |<------ mDNS Candidate C2.2 ------| 624 | | | 626 | | | 628 | | | 629 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 630 ICE Agent 2 sends server-reflexive candidates, resolution completes 631 | | | 632 | |<--Binding Req---| <192.168.1.2 633 | |---Binding Resp->| is 192.0.2.2> 634 |<----- srflx Candidate C2.3 ------| <192.0.2.2> 635 | |<--Binding Req---| <2001:db8::2 636 | |---Binding Resp->| is 2001:db8::2> 637 |<----- srflx Candidate C2.4 ------| <2001:db8::2> 638 | | | 639 <... N2.1 is | | | 640 192.168.1.2> | | | 641 <... N2.2 is | | | 642 2001:db8::2, | | | 643 discard C2.4> | | | 644 | | | 645 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 646 ICE connectivity checks 647 | | | 648 2001:db8::1 |<============= STUN ==============| 2001:db8::2 649 2001:db8::1 |============== STUN =============>| 2001:db8::2 650 192.168.1.1 |<============= STUN ==============| 192.168.1.2 651 192.168.1.1 |============== STUN =============>| 192.168.1.2 652 192.0.2.1 | Failed <-- STUN --------------| 192.168.1.2 653 192.168.1.1 |---------------STUN --> Failed | 192.0.2.2 654 2001:db8::1 |====== STUN(USE-CANDIDATE) ======>| 2001:db8::2 656 Ice Agent 1 candidates: 658 C1.1: candidate:1 1 udp 2122262783 9b36eaac-bb2e-49bb-bb78- 659 21c41c499900.local 10004 typ host 660 C1.2: candidate:2 1 udp 2122262527 76c82649-02d6-4030-8aef- 661 a2ba3a9019d5.local 10006 typ host 662 C1.3: candidate:1 1 udp 1686055167 192.0.2.1 663 30004 typ srflx raddr 0.0.0.0 rport 0 664 C1.4: candidate:2 1 udp 1686054911 2001:db8::1 665 10006 typ srflx raddr 0.0.0.0 rport 0 667 Ice Agent 2 candidates: 669 C2.1: candidate:1 1 udp 2122262783 b977f597-260c-4f70-9ac4- 670 26e69b55f966.local 20004 typ host 671 C2.2: candidate:2 1 udp 2122262527 ac4595a7-7e42-4e85-85e6- 672 c292abe0e681.local 20006 typ host 673 C2.3: candidate:1 1 udp 1686055167 192.0.2.2 674 40004 typ srflx raddr 0.0.0.0 rport 0 675 C2.4: candidate:2 1 udp 1686054911 2001:db8::2 676 20006 typ srflx raddr 0.0.0.0 rport 0 678 7. Security Considerations 680 7.1. mDNS Message Flooding 682 The implementation of this proposal requires the mDNS querying 683 capability of the browser for registering mDNS names or adding remote 684 ICE host candidates with such names. It also requires the mDNS 685 responding capability of either the browser or the operating platform 686 of the browser for registering, removing or resolving mDNS names. In 687 particular, 689 o the registration of name requires optional probing queries and 690 mandatory announcing responses ([RFC6762], Section 8), and this is 691 performed at the beginning of ICE gathering; 693 o the addition of remote ICE host candidates with mDNS names 694 generates mDNS queries for names of each candidate; 696 o the removal of names could happen when the browsing context of the 697 ICE agent is destroyed in an implementation, and goodbye responses 698 should be sent to invalidate records generated by the ICE agent in 699 the local network ([RFC6762], Section 10.1). 701 A malicious Web application could flood the local network with mDNS 702 messages by: 704 o creating browsing contexts that create ICE agents and start 705 gathering of local ICE host candidates; 707 o destroying these local candidates soon after the name registration 708 is done; 710 o adding fictitious remote ICE host candidates with mDNS names. 712 [RFC6762] defines a general per-question and per-record multicast 713 rate limiting rule, in which a given question or record on a given 714 interface cannot be sent less than one second since its last 715 transmission. This rate limiting rule however does not mitigate the 716 above attacks, in which new names, hence new questions or records, 717 are constantly created and sent. Therefore, a browser-wide mDNS 718 message rate limit MUST be provided for all mDNS queries and 719 responses that are dispatched during the ICE candidate gathering and 720 processing described in Section 3. A browser MAY implement more 721 specific rate limits, e.g., to ensure a single origin does not 722 prevent other origins from registering, unregistering, or resolving 723 mDNS names. 725 7.2. Malicious Responses to Deny Name Registration 727 If the optional probing queries are implemented for the name 728 registration, a malicious endpoint in the local network, which is 729 capable of responding mDNS queries, could send responses to block the 730 use of the generated names. This would lead to the discarding of 731 this ICE host candidate as in Step 5 in Section 3.1. 733 The above attack can be mitigated by skipping the probing when 734 registering a name, which also conforms to Section 8 in [RFC6762], 735 given that the name is randomly generated for the probabilistic 736 uniqueness (e.g. a version 4 UUID) in Step 3 in Section 3.1. 737 However, a similar attack can be performed by exploiting the negative 738 responses (defined in [RFC6762], Section 8.1), in which NSEC resource 739 records are sent to claim the nonexistence of records related to the 740 gathered ICE host candidates. 742 The existence of malicious endpoints in the local network poses a 743 generic threat, and requires dedicated protocol suites to mitigate, 744 which is beyond the scope of this proposal. 746 7.3. Unsolicited ICE Communications 748 As noted in Section 4.2 of [RTCWebSecurity], an attacker may use ICE 749 as a way to send unsolicited network traffic to specific endpoints. 750 While this is not specific to mDNS hostname candidates, this 751 technique makes it easier to target devices with well-known mDNS 752 names. 754 Also, the same technique can be used as an oracle to determine 755 whether some local services are reachable in the local network. This 756 knowledge can be used for fingerprinting purposes or as a basis for 757 attacking local networks. 759 As noted in Section 3.2, ICE agents are discouraged to resolve mDNS 760 names that are not in the format defined by Section 3.1 and may 761 further constrain the mDNS names they will actually try to resolve. 763 8. IANA Considerations 765 This document requires no actions from IANA. 767 9. References 769 9.1. Normative References 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, 773 DOI 10.17487/RFC2119, March 1997, 774 . 776 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 777 Unique IDentifier (UUID) URN Namespace", RFC 4122, 778 DOI 10.17487/RFC4122, July 2005, 779 . 781 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 782 Extensions for Stateless Address Autoconfiguration in 783 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 784 . 786 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 787 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 788 DOI 10.17487/RFC5389, October 2008, 789 . 791 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 792 Relays around NAT (TURN): Relay Extensions to Session 793 Traversal Utilities for NAT (STUN)", RFC 5766, 794 DOI 10.17487/RFC5766, April 2010, 795 . 797 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 798 DOI 10.17487/RFC6762, February 2013, 799 . 801 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 802 Connectivity Establishment (ICE): A Protocol for Network 803 Address Translator (NAT) Traversal", RFC 8445, 804 DOI 10.17487/RFC8445, July 2018, 805 . 807 9.2. Informative References 809 [HTMLSpec] 810 "HTML Living Standard", n.d., 811 . 813 [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ 814 Answer procedures for Interactive Connectivity 815 Establishment (ICE)", April 2018, 816 . 819 [IPHandling] 820 Shieh, G., "WebRTC IP Address Handling Requirements", 821 April 2018, . 824 [JSEP] Rescorla, Ed, E., "JavaScript Session Establishment 825 Protocol", February 2019, 826 . 828 [Overview] 829 Alvestrand, H., "Overview: Real Time Protocols for 830 Browser-based Applications", November 2017, 831 . 833 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 834 and E. Lear, "Address Allocation for Private Internets", 835 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 836 . 838 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 839 NAT64: Network Address and Protocol Translation from IPv6 840 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 841 April 2011, . 843 [RTCWebSecurity] 844 Rescorla, E., "Security Considerations for WebRTC", 845 January 2018, 846 . 848 [WebRTCSpec] 849 Bruaroey, J., "The WebRTC specification", n.d., 850 . 852 [WebRTCStats] 853 Bostroem, H., "Identifiers for WebRTC's Statistics API", 854 n.d., . 856 Authors' Addresses 858 Youenn Fablet 859 Apple Inc. 861 Email: youenn@apple.com 863 Jeroen de Borst 864 Google 866 Email: jeroendb@google.com 868 Justin Uberti 869 Google 871 Email: juberti@google.com 872 Qingsi Wang 873 Google 875 Email: qingsi@google.com