idnits 2.17.00 (12 Aug 2021) /tmp/idnits53902/draft-ietf-mmusic-mdns-ice-candidates-03.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (5 December 2021) is 160 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'WebRTCSpec' is defined on line 867, 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 (~~), 4 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. Uberti 5 Intended status: Informational Clubhouse 6 Expires: 8 June 2022 J. de Borst 7 Q. Wang 8 Google 9 5 December 2021 11 Using Multicast DNS to protect privacy when exposing ICE candidates 12 draft-ietf-mmusic-mdns-ice-candidates-03 14 Abstract 16 WebRTC applications collect ICE candidates as part of the process of 17 creating peer-to-peer connections. To maximize the probability of a 18 direct peer-to-peer connection, the endpoint's local IP addresses are 19 included in this candidate collection. However, these addresses are 20 typically private and, as such, their disclosure has privacy 21 implications. This document describes a privacy-preserving way to 22 share local IP addresses with other endpoints by concealing the 23 addresses with dynamically generated Multicast DNS (mDNS) names. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 8 June 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . 9 71 3.3.4. Specific Browsing Contexts . . . . . . . . . . . . . 9 72 3.3.5. Network Interface Enumeration . . . . . . . . . . . . 9 73 3.3.6. Monitoring of Sessions . . . . . . . . . . . . . . . 10 74 4. Update to RFC 8839 . . . . . . . . . . . . . . . . . . . . . 10 75 5. Potential Limitations . . . . . . . . . . . . . . . . . . . . 10 76 5.1. Reduced Connectivity . . . . . . . . . . . . . . . . . . 10 77 5.2. Connection Setup Latency . . . . . . . . . . . . . . . . 11 78 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 11 79 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.1. Normal Handling . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . 16 86 7.2. Malicious Responses to Deny Name Registration . . . . . . 17 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 local 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 IP addresses, and then provide those 110 names, rather than the IP addresses, in their ICE candidates. While 111 this technique is intended to benefit WebRTC implementations in web 112 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 While mDNS names are usually only valid within a local network, the 125 same is true for private IP addresses, and therefore this does not 126 limit the effectiveness of this technique. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Description 136 This section uses the concept of ICE agent as defined in [RFC8445]. 137 In the remainder of the document, it is assumed that each browsing 138 context (as defined in Section 7.1 of [HTMLSpec]) has its own ICE 139 agent. 141 3.1. ICE Candidate Gathering 143 This section outlines how mDNS should be used by ICE agents to 144 conceal local IP addresses. 146 3.1.1. Procedure 148 For each host candidate gathered by an ICE agent as part of the 149 gathering process described in [RFC8445], Section 5.1.1, the 150 candidate is handled as described below. 152 1. Check whether this IP address satisfies the ICE agent's policy 153 regarding whether an address is safe to expose (typically, 154 following the advice from Section 3.1.2.2 below). If so, expose 155 the candidate and abort this process. 157 2. Check whether the ICE agent has previously generated, registered, 158 and stored an mDNS hostname for this IP address as per steps 3 to 159 5. If it has, skip ahead to step 6. 161 3. Generate a unique mDNS hostname. The unique name MUST consist of 162 a version 4 UUID as defined in [RFC4122], followed by ".local". 164 4. Register the candidate's mDNS hostname as defined in [RFC6762]. 165 The ICE agent SHOULD send an mDNS announcement for the hostname, 166 but as the hostname is expected to be unique, the ICE agent 167 SHOULD skip probing of the hostname. 169 5. Store the mDNS hostname and its related IP address in the ICE 170 agent for future reuse. 172 6. Replace the IP address of the ICE candidate with its mDNS 173 hostname and provide the candidate to the web application. 175 ICE agents can implement this procedure in any way as long as it 176 produces equivalent results. An implementation may for instance pre- 177 register mDNS hostnames by executing steps 3 to 5 and prepopulate an 178 ICE agent accordingly. By doing so, only step 6 of the above 179 procedure will be executed at the time of gathering candidates. 181 In order to prevent web applications from using this mechanism to 182 query for mDNS support in the local network, the ICE agent SHOULD 183 still provide mDNS candidates in step 6 even if the local network 184 does not support mDNS or mDNS registration fails in step 4. 186 This procedure ensures that an mDNS name is used to replace only one 187 IP address. Specifically, an ICE agent using an interface with both 188 IPv4 and IPv6 addresses MUST expose a different mDNS name for each 189 address. 191 3.1.2. Implementation Guidance 193 3.1.2.1. Registration 195 Sending the mDNS announcement to the network can be delayed, for 196 instance due to rate limits. An ICE agent SHOULD provide the 197 candidate to the web application as soon as its mDNS name is 198 generated, regardless of whether the announcement has been sent on 199 the network. 201 3.1.2.2. Determining Address Privacy and Server-Reflexive Candidates 203 Naturally, an address that is already exposed to the Internet does 204 not need to be protected by mDNS, as it can be trivially observed by 205 the web server or remote endpoint. However, determining this ahead 206 of time is not straightforward; while the fact that an IPv4 address 207 is private can sometimes be inferred by its value, e.g., whether it 208 is an [RFC1918] address, the reverse is not necessarily true. IPv6 209 addresses present their own complications, e.g., private IPv6 210 addresses as a result of NAT64 [RFC6146]. 212 Instead, the determination of whether an address is public can be 213 reliably made as part of the ICE gathering process. For each mDNS 214 host candidate generated according the guidance above, the usual STUN 215 [RFC5389] request is sent to a STUN server. This can be done for 216 both IPv4 and IPv6 local addresses, provided that the application has 217 configured both IPv4 and IPv6 STUN servers. If the STUN response 218 returns the same value as the local IP address, this indicates the 219 address is in fact public, although processing will continue as 220 described below. 222 Regardless of whether the address turns out to be public or private, 223 a server-reflexive candidate will be generated; the transport address 224 of this candidate will be an IP address and therefore distinct from 225 the hostname transport address of the associated mDNS candidate, and 226 as such MUST NOT be considered redundant per the guidance in 227 [RFC8445], Section 5.1.3. To avoid accidental IP address disclosure, 228 this server-reflexive candidate MUST have its raddr field set to 229 "0.0.0.0"/"::" and its rport field set to "9", as discussed in 230 [ICESDP], Section 9.1. 232 Because a new candidate is always generated by the STUN query, the 233 ICE agent SHOULD initially provide mDNS-wrapped candidates to the 234 application and then follow with server-reflexive candidates once 235 they are obtained, unless it has a priori knowledge that a given 236 address is public and does not require mDNS wrapping. 238 To that end, once an address has been identified as public, the ICE 239 agent MAY cache this information and skip mDNS protection for that 240 address in future ICE gathering phases. Note that if the set of STUN 241 servers changes, any cached information SHOULD be discarded, as the 242 new set may return different results. 244 3.1.2.3. Special Handling for IPv6 Addresses 246 As noted in [IPHandling], private IPv4 addresses are especially 247 problematic because of their unbounded lifetime. However, the 248 [RFC4941] IPv6 addresses recommended for WebRTC have inherent privacy 249 protections, namely a short lifetime and the lack of any stateful 250 information. Accordingly, implementations MAY choose to not conceal 251 [RFC4941] addresses with mDNS names as a tradeoff for improved peer- 252 to-peer connectivity. 254 3.1.2.4. mDNS Candidate Encoding 256 The mDNS name of an mDNS candidate MUST be used in the connection- 257 address field of its candidate attribute. However, when an mDNS 258 candidate would be the default candidate, typically because there are 259 no other candidates, its mDNS name MUST NOT be used in the 260 connection-address field of the SDP "c=" line, as experimental 261 deployment has indicated that many remote endpoints will fail to 262 handle such a SDP. In this situation, the IP address values 263 "0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and 264 m= lines, similar to how the no-candidates case is handled in 265 [ICESDP], Section 4.3.1. 267 Any candidates exposed to the application via local descriptions MUST 268 be identical to those provided during candidate gathering (i.e., MUST 269 NOT contain private host IP addresses). 271 3.2. ICE Candidate Processing 273 This section outlines how received ICE candidates with mDNS names are 274 processed by ICE agents, and is relevant to all endpoints. 276 3.2.1. Procedure 278 For any remote ICE candidate received by the ICE agent, the following 279 procedure is used: 281 1. If the connection-address field value of the ICE candidate does 282 not end with ".local" or if the value contains more than one ".", 283 then process the candidate as defined in [RFC8445]. 285 2. If the ICE candidate policy is "relay", as defined in [JSEP], 286 ignore the candidate. 288 3. Otherwise, resolve the candidate using mDNS. The ICE agent 289 SHOULD set the unicast-response bit of the corresponding mDNS 290 query message; this minimizes multicast traffic, as the response 291 is probably only useful to the querying node. 293 4. If it resolves to an IP address, replace the mDNS hostname of the 294 ICE candidate with the resolved IP address and continue 295 processing of the candidate as defined in [RFC8445]. 297 5. Otherwise, ignore the candidate. 299 3.2.2. Implementation Guidance 301 An ICE agent may use a hostname resolver that transparently supports 302 both Multicast and Unicast DNS. In this case the resolution of a 303 ".local" name may happen through Unicast DNS as noted in [RFC6762], 304 Section 3. 306 An ICE agent SHOULD ignore candidates where the hostname resolution 307 returns more than one IP address. 309 An ICE agent MAY add additional restrictions regarding the ICE 310 candidates it will resolve using mDNS, as this mechanism allows 311 attackers to send ICE traffic to devices with well-known mDNS names. 312 In particular, ICE agents SHOULD NOT resolve mDNS names if they are 313 not in the format defined by Section 3.1. 315 3.3. Additional Privacy Considerations 317 The goal of this mechanism is to keep knowledge of private host IP 318 addresses within the ICE agent while continuing to allow the 319 application to transmit ICE candidates. Besides keeping private host 320 IP addresses out of ICE candidates, implementations must take steps 321 to prevent these IP addresses from being exposed to web applications 322 through other means. 324 3.3.1. Statistics 326 Statistics related to ICE candidates that are accessible to the web 327 application MUST NOT contain the IP address of a local or remote mDNS 328 candidate; the mDNS name SHOULD be used instead. 330 Statistics SHOULD NOT leak whether the mDNS resolution succeeds or 331 fails. For that reason, RTCIceCandidateStats objects as defined in 332 [WebRTCStats] SHOULD be generated for any remote mDNS candidate 333 submitted to the ICE agent, even if the mDNS candidate is ignored as 334 part of Section 3.2. An implementation strategy to obfuscate the 335 address of an mDNS candidate in the statistics, regardless if it is 336 resolved or not, is to replace the mDNS hostname of the ICE candidate 337 with IP values "0.0.0.0" or "::". 339 In addition, a peer-reflexive remote candidate may be constructed 340 from a remote host IP address as a result of an ICE connectivity 341 check, as described in Section 7.3.1.3 of [RFC8445]. This check may 342 arrive before the candidate due to signaling or mDNS resolution 343 delays, as shown in the examples above. 345 To prevent disclosure of the host IP address to the application in 346 this scenario, statistics related to ICE candidates MUST NOT contain 347 the IP address of any peer-reflexive candidate, unless that IP has 348 already been learned through signaling of a candidate with the same 349 address and either the same or a different port; this includes cases 350 where the signaled candidate is discarded as redundant according to 351 Section 5.1.3 of [RFC8445]. 353 3.3.2. Interactions With TURN Servers 355 When sending data to a TURN [RFC5766] server, the sending client 356 tells the server the destination IP and port for the data. This 357 means that if the client uses TURN to send to an IP that was obtained 358 by mDNS resolution, the TURN server will learn the underlying host IP 359 and port, and this information can then be relayed to the web 360 application, defeating the value of the mDNS wrapping. 362 To prevent disclosure of the host IP address to a TURN server, the 363 ICE agent MUST NOT form candidate pairs between its own relay 364 candidates and remote mDNS candidates. This restriction applies to 365 all remote mDNS candidate types, not just host candidates; mDNS 366 candidates can be clearly identified from their connection-address 367 fields. Note also that the converse is not an issue; the ICE agent 368 MAY form candidate pairs between its own mDNS candidates and remote 369 relay candidates, as in this situation host IPs will not be sent 370 directly to the TURN server. 372 This restriction has no effect on connectivity; in the cases where 373 host IP addresses are private and need to be wrapped with mDNS names, 374 they will be unreachable from the TURN server, and as noted above, 375 the reverse path will continue to work normally. 377 3.3.3. Generated Name Reuse 379 It is important that use of registered mDNS hostnames is limited in 380 time and/or scope. Indefinitely reusing the same mDNS hostname 381 candidate would provide applications an even more reliable tracking 382 mechanism than the private IP addresses that this specification is 383 designed to hide. In the case of a web application, the use of 384 registered mDNS hostnames SHOULD be scoped by the web application 385 origin, and SHOULD have the lifetime of the page executing the web 386 application. 388 3.3.4. Specific Browsing Contexts 390 As noted in [IPHandling], privacy may be breached if a web 391 application running in two browsing contexts can determine whether it 392 is running on the same device. While the approach in this document 393 prevents the application from directly comparing local private IP 394 addresses, a successful local WebRTC connection can also present a 395 threat to user privacy. Specifically, when the latency of a WebRTC 396 connection latency is close to zero, the probability is high that the 397 two peers are running on the same device. 399 To avoid this issue, browsers SHOULD NOT register mDNS names for 400 WebRTC applications running in a third-party browsing context (i.e., 401 a context that has a different origin than the top-level browsing 402 context), or a private browsing context. 404 3.3.5. Network Interface Enumeration 406 Even when local IP addresses are not exposed, the number of mDNS 407 hostname candidates can still provide a fingerprinting dimension. 408 This is in particular the case for network interfaces with limited 409 connectivity that will not generate server-reflexive or relay 410 candidates. 412 The more mDNS names an endpoint exposes through mDNS hostname 413 candidates, the higher the fingerprinting risk. One countermeasure 414 is to limit this number to a small value. 416 Note that no additional fingerprinting risk is introduced when 417 restricting mDNS hostname candidates to default route only. 419 3.3.6. Monitoring of Sessions 421 A malicious endpoint in the local network may also record other 422 endpoints who are registering, unregistering, and resolving mDNS 423 names. By doing so, they can create a session log that shows which 424 endpoints are communicating, and for how long. If both endpoints in 425 the session are on the same network, the fact they are communicating 426 can be discovered. 428 Mitigation of this threat is beyond the scope of this proposal. 430 4. Update to RFC 8839 432 Section 5.1 of [ICESDP] states: 434 An agent generating local candidates MUST NOT use FQDN addresses. 435 An agent processing remote candidates MUST ignore candidate lines 436 that include candidates with FQDN or IP address versions that are 437 not supported or recognized. 439 This document extends [ICESDP] to specifically allow the generation 440 and processing of ICE candidates with the ".local" FQDNs defined in 441 {gathering}. The restrictions on other FQDNs are unaffected. 443 5. Potential Limitations 445 5.1. Reduced Connectivity 447 With typical ICE, endpoints on the same network will usually be able 448 to establish a direct connection between their local IP addresses. 449 When using the mDNS technique, a direct connection is still possible, 450 but only if at least one side can properly resolve the provided mDNS 451 candidates. This may not be possible in all scenarios. 453 First, some networks may entirely disable mDNS. Second, mDNS queries 454 have limited scope. On large networks, this may mean that an mDNS 455 name cannot be resolved if the remote endpoint is too many segments 456 away. 458 When mDNS fails, ICE will attempt to fall back to either NAT hairpin, 459 if supported, or TURN relay if not. This may result in reduced 460 connectivity, reduced throughput and increased latency, as well as 461 increased cost in case of TURN relay. 463 During experimental testing of the mDNS technique across a set of 464 known mDNS-aware endpoints that had configured a STUN server but not 465 a TURN server, the observed impact to ICE connection rate was 2% 466 (relative) when mDNS was enabled on both sides, compared to when mDNS 467 was only enabled on one side. In this testing, the percentage of 468 connections that required STUN (i.e., went through a NAT) increased 469 from 94% to 97%, indicating that mDNS succeeded about half the time, 470 and fell back to NAT hairpin for the remainder. The most likely 471 explanation for the overall connection rate drop is that hairpinning 472 failed in some cases. 474 5.2. Connection Setup Latency 476 As noted in Section 3, ICE agents using the mDNS technique are 477 responsible for registering and resolving mDNS names as part of the 478 ICE process. These steps may delay establishment of a direct peer- 479 to-peer connection, compared to when raw local IP addresses are used. 481 Given that these mDNS registrations and queries are typically 482 occurring on a local network, any associated delays should be small. 483 Also, as noted in Section 3.1, pre-registration can be employed to 484 eliminate gathering delays entirely. 486 5.3. Backward Compatibility 488 For the most part, backward compatibility does not present a 489 significant issue for the mDNS technique. When an endpoint that 490 supports mDNS communicates with a legacy endpoint that does not, the 491 legacy endpoint will still provide its local IP addresses, allowing 492 the new endpoint to attempt direct connections to those addresses. 493 Through the process of learning peer-reflexive candidates described 494 in [RFC8445], the legacy endpoint will also learn the IP addresses of 495 the mDNS-aware endpoint, allowing ICE to succeed even though the 496 legacy endpoint cannot resolve the mDNS names. In the event the 497 legacy endpoint attempts to resolve the mDNS names using Unicast DNS, 498 this may cause ICE to take somewhat longer to fully complete, but 499 should not have any effect on connectivity or connection setup time. 501 However, some legacy endpoints are not fully spec-compliant and can 502 behave unpredictably in the presence of ICE candidates that contain a 503 hostname, potentially leading to ICE failure. Specifically, the SDP 504 parsers in these endpoints may raise a fatal error when receiving 505 such candidates, rather than simply ignoring them. 507 Some endpoints may also fail to handle a connectivity check from an 508 address that they have not received in signaling (i.e., they do not 509 support learning peer-reflexive candidates as described above), 510 leading to ICE failure. During the aforementioned experimental 511 testing, the connection rate when interacting with endpoints that 512 provided raw IP addresses (and therefore should be unaffected) 513 decreased by 3% (relative), presumably for these reasons. 515 6. Examples 517 The examples below show how the mDNS technique is used during ICE 518 processing. The first example shows a simple case, the next two 519 examples demonstrate how peer-reflexive candidates for local IP 520 addresses can be created due to timing differences, and the final 521 example shows a real-world case with IPv4, IPv6, and STUN. 523 6.1. Normal Handling 525 In this example, mDNS candidates are exchanged between peers and 526 resolved normally to obtain the corresponding IP addresses. 528 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 529 | | 532 |------- mDNS Candidate N1 ------>| 533 | | 536 |<------ mDNS Candidate N2 -------| 537 | | mDNS name N1> 539 |<=== STUN check to 192.0.2.1 ====| 540 |==== STUN check to 192.0.2.2 ===>| 541 | | 543 The exchange of ICE candidates relies on out-of-band signaling, for 544 example, the SDP Offer/Answer procedure defined in [ICESDP]. In the 545 above example, the candidate attributes in the SDP messages to 546 exchange the mDNS candidates between ICE Agent 1 and 2 are as 547 follows: 549 ICE Agent 1: 551 a=candidate:1 1 udp 2122262783 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 552 54596 typ host 554 ICE Agent 2: 556 a=candidate:1 1 udp 2122262783 2579ef4b-50ae-4bfe-95af-70b3376ecb9c.local 557 61606 typ host 559 6.2. Peer-reflexive Candidate From Slow Signaling 561 In this example, a peer-reflexive candidate is generated because the 562 mDNS candidate is signaled after the STUN checks begin. 564 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 565 | | 568 |------- mDNS Candidate N1 ------>| 569 | | 571 |<=== STUN check to 192.0.2.1 ====| 572 prflx candidate | | 575 |<------ mDNS Candidate N2 -------| 576 | | 578 6.3. Peer-reflexive Candidate From Slow Resolution 580 In this example, a peer-reflexive candidate is generated because the 581 mDNS resolution for name N2 does not complete until after the STUN 582 checks are received. 584 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 585 | | 192.0.2.2> 588 |------- mDNS Candidate N1 ------>| 589 |<------ mDNS Candidate N2 -------| 590 592 . |<=== STUN check to 192.0.2.1 ====| 593 . prflx candidate | | 594 . 192.0.2.2 created | | 595 name | | 596 N2> | | 598 6.4. IPv4, IPv6, and STUN handling 600 This last example demonstrates the overall ICE gathering process for 601 two endpoints, each with a private IPv4 address and a public IPv6 602 address. They preregister their mDNS names to speed up ICE 603 gathering. 605 ICE Agent 1 ICE Agent 2 606 192.168.1.1 STUN 192.168.1.2 607 2001:db8::1 Server 2001:db8::2 608 ---------------------------------------------------------------------- 609 Pre-registration of mDNS names 610 | | | 611 | | | 192.168.1.2> 614 | | | 2001:db8::2> 617 | | | 618 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 619 ICE Agent 1 sends mDNS candidates 620 | | | 621 |------- mDNS Candidate C1.1 ----->| 622 |------- mDNS Candidate C1.2 ----->| 623 | | | 626 | | | 629 | | | 630 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 631 ICE Agent 1 sends server-reflexive candidates 632 | | | 633 <192.168.1.1 |--Binding Req-->| | 634 is 192.0.2.1> |<-Binding Resp--| | 635 <192.0.2.1> |------ srflx Candidate C1.3 ----->| 636 <2001:db8::1 |--Binding Req-->| | 637 is 2001:db8::1> |<-Binding Resp--| | 638 <2001:db8::1> |------ srflx Candidate C1.4 ----->| 640 | | | 641 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 642 ICE Agent 2 sends mDNS candidates, resolution is slow 643 | | | 644 |<------ mDNS Candidate C2.1 ------| 645 |<------ mDNS Candidate C2.2 ------| 646 | | | 648 | | | 650 | | | 651 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 652 ICE Agent 2 sends server-reflexive candidates, resolution completes 653 | | | 654 | |<--Binding Req---| <192.168.1.2 655 | |---Binding Resp->| is 192.0.2.2> 656 |<----- srflx Candidate C2.3 ------| <192.0.2.2> 657 | |<--Binding Req---| <2001:db8::2 658 | |---Binding Resp->| is 2001:db8::2> 659 |<----- srflx Candidate C2.4 ------| <2001:db8::2> 660 | | | 661 <... N2.1 is | | | 662 192.168.1.2> | | | 663 <... N2.2 is | | | 664 2001:db8::2, | | | 665 discard C2.4> | | | 666 | | | 667 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 668 ICE connectivity checks 669 | | | 670 2001:db8::1 |<============= STUN ==============| 2001:db8::2 671 2001:db8::1 |============== STUN =============>| 2001:db8::2 672 192.168.1.1 |<============= STUN ==============| 192.168.1.2 673 192.168.1.1 |============== STUN =============>| 192.168.1.2 674 192.0.2.1 | Failed <-- STUN --------------| 192.168.1.2 675 192.168.1.1 |---------------STUN --> Failed | 192.0.2.2 676 2001:db8::1 |====== STUN(USE-CANDIDATE) ======>| 2001:db8::2 678 Ice Agent 1 candidates: 680 C1.1: candidate:1 1 udp 2122262783 9b36eaac-bb2e-49bb-bb78- 681 21c41c499900.local 10004 typ host 682 C1.2: candidate:2 1 udp 2122262527 76c82649-02d6-4030-8aef- 683 a2ba3a9019d5.local 10006 typ host 684 C1.3: candidate:1 1 udp 1686055167 192.0.2.1 685 30004 typ srflx raddr 0.0.0.0 rport 0 686 C1.4: candidate:2 1 udp 1686054911 2001:db8::1 687 10006 typ srflx raddr 0.0.0.0 rport 0 689 Ice Agent 2 candidates: 691 C2.1: candidate:1 1 udp 2122262783 b977f597-260c-4f70-9ac4- 692 26e69b55f966.local 20004 typ host 693 C2.2: candidate:2 1 udp 2122262527 ac4595a7-7e42-4e85-85e6- 694 c292abe0e681.local 20006 typ host 695 C2.3: candidate:1 1 udp 1686055167 192.0.2.2 696 40004 typ srflx raddr 0.0.0.0 rport 0 697 C2.4: candidate:2 1 udp 1686054911 2001:db8::2 698 20006 typ srflx raddr 0.0.0.0 rport 0 700 7. Security Considerations 701 7.1. mDNS Message Flooding 703 The implementation of this proposal requires the mDNS querying 704 capability of the browser for registering mDNS names or adding remote 705 ICE host candidates with such names. It also requires the mDNS 706 responding capability of either the browser or the operating platform 707 of the browser for registering, removing or resolving mDNS names. In 708 particular, 710 * the registration of name requires optional probing queries and 711 mandatory announcing responses ([RFC6762], Section 8), and this is 712 performed at the beginning of ICE gathering; 714 * the addition of remote ICE host candidates with mDNS names 715 generates mDNS queries for names of each candidate; 717 * the removal of names could happen when the browsing context of the 718 ICE agent is destroyed in an implementation, and goodbye responses 719 should be sent to invalidate records generated by the ICE agent in 720 the local network ([RFC6762], Section 10.1). 722 A malicious Web application could flood the local network with mDNS 723 messages by: 725 * creating browsing contexts that create ICE agents and start 726 gathering of local ICE host candidates; 728 * destroying these local candidates soon after the name registration 729 is done; 731 * adding fictitious remote ICE host candidates with mDNS names. 733 [RFC6762] defines a general per-question and per-record multicast 734 rate limiting rule, in which a given question or record on a given 735 interface cannot be sent less than one second since its last 736 transmission. This rate limiting rule however does not mitigate the 737 above attacks, in which new names, hence new questions or records, 738 are constantly created and sent. Therefore, a browser-wide mDNS 739 message rate limit MUST be provided for all mDNS queries and 740 responses that are dispatched during the ICE candidate gathering and 741 processing described in Section 3. A browser MAY implement more 742 specific rate limits, e.g., to ensure a single origin does not 743 prevent other origins from registering, unregistering, or resolving 744 mDNS names. 746 7.2. Malicious Responses to Deny Name Registration 748 If the optional probing queries are implemented for the name 749 registration, a malicious endpoint in the local network, which is 750 capable of responding mDNS queries, could send responses to block the 751 use of the generated names. This would lead to the discarding of 752 this ICE host candidate as in Step 5 in Section 3.1. 754 The above attack can be mitigated by skipping the probing when 755 registering a name, which also conforms to Section 8 in [RFC6762], 756 given that the name is randomly generated for the probabilistic 757 uniqueness (e.g. a version 4 UUID) in Step 3 in Section 3.1. 758 However, a similar attack can be performed by exploiting the negative 759 responses (defined in [RFC6762], Section 8.1), in which NSEC resource 760 records are sent to claim the nonexistence of records related to the 761 gathered ICE host candidates. 763 The existence of malicious endpoints in the local network poses a 764 generic threat, and requires dedicated protocol suites to mitigate, 765 which is beyond the scope of this proposal. 767 7.3. Unsolicited ICE Communications 769 As noted in Section 4.2 of [RTCWebSecurity], an attacker may use ICE 770 as a way to send unsolicited network traffic to specific endpoints. 771 While this is not specific to mDNS hostname candidates, this 772 technique makes it easier to target devices with well-known mDNS 773 names. 775 Also, the same technique can be used as an oracle to determine 776 whether some local services are reachable in the local network. This 777 knowledge can be used for fingerprinting purposes or as a basis for 778 attacking local networks. 780 As noted in Section 3.2, ICE agents are discouraged to resolve mDNS 781 names that are not in the format defined by Section 3.1 and may 782 further constrain the mDNS names they will actually try to resolve. 784 8. IANA Considerations 786 This document requires no actions from IANA. 788 9. References 790 9.1. Normative References 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, 794 DOI 10.17487/RFC2119, March 1997, 795 . 797 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 798 Unique IDentifier (UUID) URN Namespace", RFC 4122, 799 DOI 10.17487/RFC4122, July 2005, 800 . 802 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 803 Extensions for Stateless Address Autoconfiguration in 804 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 805 . 807 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 808 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 809 DOI 10.17487/RFC5389, October 2008, 810 . 812 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 813 Relays around NAT (TURN): Relay Extensions to Session 814 Traversal Utilities for NAT (STUN)", RFC 5766, 815 DOI 10.17487/RFC5766, April 2010, 816 . 818 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 819 DOI 10.17487/RFC6762, February 2013, 820 . 822 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 823 Connectivity Establishment (ICE): A Protocol for Network 824 Address Translator (NAT) Traversal", RFC 8445, 825 DOI 10.17487/RFC8445, July 2018, 826 . 828 9.2. Informative References 830 [HTMLSpec] "HTML Living Standard", n.d., 831 . 833 [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ 834 Answer procedures for Interactive Connectivity 835 Establishment (ICE)", 1 April 2018, 836 . 839 [IPHandling] 840 Shieh, G., "WebRTC IP Address Handling Requirements", 18 841 April 2018, . 844 [JSEP] Rescorla, Ed, E., "JavaScript Session Establishment 845 Protocol", 27 February 2019, 846 . 848 [Overview] Alvestrand, H., "Overview: Real Time Protocols for 849 Browser-based Applications", 12 November 2017, 850 . 852 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 853 J., and E. Lear, "Address Allocation for Private 854 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 855 February 1996, . 857 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 858 NAT64: Network Address and Protocol Translation from IPv6 859 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 860 April 2011, . 862 [RTCWebSecurity] 863 Rescorla, E., "Security Considerations for WebRTC", 22 864 January 2018, 865 . 867 [WebRTCSpec] 868 Bruaroey, J.I., "The WebRTC specification", n.d., 869 . 871 [WebRTCStats] 872 Boström, H., "Identifiers for WebRTC's Statistics API", 873 n.d., . 875 Authors' Addresses 877 Youenn Fablet 878 Apple Inc. 880 Email: youenn@apple.com 882 Justin Uberti 883 Clubhouse 885 Email: justin@uberti.name 886 Jeroen de Borst 887 Google 889 Email: jeroendb@google.com 891 Qingsi Wang 892 Google 894 Email: qingsi@google.com