idnits 2.17.1 draft-ietf-rtcweb-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: ---------------------------------------------------------------------------- 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 (March 25, 2019) is 1852 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'WebRTCSpec' is defined on line 785, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB Y. Fablet 3 Internet-Draft Apple Inc. 4 Intended status: Informational J. de Borst 5 Expires: September 26, 2019 J. Uberti 6 Q. Wang 7 Google 8 March 25, 2019 10 Using Multicast DNS to protect privacy when exposing ICE candidates 11 draft-ietf-rtcweb-mdns-ice-candidates-03 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 26, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3 62 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1.2. Implementation Guidance . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . 8 74 4. Potential Limitations . . . . . . . . . . . . . . . . . . . . 9 75 4.1. Reduced Connectivity . . . . . . . . . . . . . . . . . . 9 76 4.2. Connection Setup Latency . . . . . . . . . . . . . . . . 9 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 . . . . . . 11 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 . . . . . . . . . . . . . 15 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 8.2. Informative References . . . . . . . . . . . . . . . . . 17 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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, this server-reflexive candidate MUST have its 211 raddr field set to 0.0.0.0 and its rport field set to 0. 213 Once an address has been identified as public, the ICE agent MAY 214 cache this information and omit mDNS protection for that address in 215 future ICE gathering phases. 217 3.1.2.2. Special Handling for IPv6 Addresses 219 As noted in [IPHandling], private IPv4 addresses are especially 220 problematic because of their unbounded lifetime. However, the 221 [RFC4941] IPv6 addresses recommended for WebRTC have inherent privacy 222 protections, namely a short lifetime and the lack of any stateful 223 information. Accordingly, implementations MAY choose to not conceal 224 [RFC4941] addresses with mDNS names as a tradeoff for improved peer- 225 to-peer connectivity. 227 3.1.2.3. mDNS Candidate Encoding 229 The mDNS name of an mDNS candidate MUST be used in the connection- 230 address field of its candidate attribute. When an mDNS candidate is 231 the default candidate, its mDNS name MUST be used in the connection- 232 address field of the SDP "c=" line. Since an mDNS candidate also 233 conceals its address family, the "c=" line SHOULD use "IP4" in the 234 address-type field. 236 Any candidates exposed to the application via local descriptions MUST 237 be identical to those provided during candidate gathering (i.e., MUST 238 NOT contain private host IP addresses). 240 3.2. ICE Candidate Processing 242 This section outlines how received ICE candidates with mDNS names are 243 processed by ICE agents, and is relevant to all endpoints. 245 3.2.1. Procedure 247 For any remote ICE candidate received by the ICE agent, the following 248 procedure is used: 250 1. If the connection-address field value of the ICE candidate does 251 not end with ".local" or if the value contains more than one ".", 252 then process the candidate as defined in [RFC8445]. 254 2. Otherwise, resolve the candidate using mDNS. 256 3. If it resolves to an IP address, replace the mDNS hostname of the 257 ICE candidate with the resolved IP address and continue 258 processing of the candidate as defined in [RFC8445]. 260 4. Otherwise, ignore the candidate. 262 3.2.2. Implementation Guidance 264 An ICE agent may use a hostname resolver that transparently supports 265 both Multicast and Unicast DNS. In this case the resolution of a 266 ".local" name may happen through Unicast DNS as noted in [RFC6762], 267 Section 3. 269 An ICE agent SHOULD ignore candidates where the hostname resolution 270 returns more than one IP address. 272 An ICE agent MAY add additional restrictions regarding the ICE 273 candidates it will resolve using mDNS, as this mechanism allows 274 attackers to send ICE traffic to devices with well-known mDNS names. 276 3.3. Additional Privacy Considerations 278 The goal of this mechanism is to keep knowledge of private host IP 279 addresses within the ICE agent while continuing to allow the 280 application to transmit ICE candidates. Besides keeping private host 281 IP addresses out of ICE candidates, implementations must take steps 282 to prevent these IP addresses from being exposed to web applications 283 through other means. 285 3.3.1. Statistics 287 Statistics related to ICE candidates that are accessible to the web 288 application MUST NOT contain the IP address of a local or remote mDNS 289 candidate; the mDNS name SHOULD be used instead. 291 In addition, a peer-reflexive remote candidate may be constructed 292 from a remote host IP address as a result of an ICE connectivity 293 check, as described in Section 7.3.1.3 of [RFC8445]. This check may 294 arrive before the candidate due to signaling or mDNS resolution 295 delays, as shown in the examples above. 297 To prevent disclosure of the host IP address to the application in 298 this scenario, statistics related to ICE candidates MUST NOT contain 299 the IP address of any peer-reflexive candidate, unless that IP has 300 already been learned through signaling of a candidate with the same 301 address and either the same or a different port; this includes cases 302 where the signaled candidate is discarded as redundant according to 303 Section 5.1.3 of [RFC8445]. 305 3.3.2. Interactions With TURN Servers 307 When sending data to a TURN [RFC5766] server, the sending client 308 tells the server the destination IP and port for the data. This 309 means that if the client uses TURN to send to an IP that was obtained 310 by mDNS resolution, the TURN server will learn the underlying host IP 311 and port, and this information can then be relayed to the web 312 application, defeating the value of the mDNS wrapping. 314 To prevent disclosure of the host IP address to a TURN server, the 315 ICE agent MUST NOT form candidate pairs between its own relay 316 candidates and remote mDNS candidates. Note that the converse is not 317 an issue; the ICE agent MAY form candidate pairs between its own mDNS 318 candidates and remote relay candidates, as in this situation host IPs 319 will not be sent directly to the TURN server. 321 This restriction has no effect on connectivity; in the cases where 322 host IP addresses are private and need to be wrapped with mDNS names, 323 they will be unreachable from the TURN server, and as noted above, 324 the reverse path will continue to work normally. 326 3.3.3. Generated Name Reuse 328 It is important that use of registered mDNS hostnames is limited in 329 time and/or scope. Indefinitely reusing the same mDNS hostname 330 candidate would provide applications an even more reliable tracking 331 mechanism than the private IP addresses that this specification is 332 designed to hide. In the case of a web application, the use of 333 registered mDNS hostnames SHOULD be scoped by the web application 334 origin, and SHOULD have the lifetime of the page executing the web 335 application. 337 3.3.4. Specific Browsing Contexts 339 As noted in [IPHandling], privacy may be breached if a web 340 application running in two browsing contexts can determine whether it 341 is running on the same device. While the approach in this document 342 prevents the application from directly comparing local private IP 343 addresses, a successful local WebRTC connection can also present a 344 threat to user privacy. Specifically, when the latency of a WebRTC 345 connection latency is close to zero, the probability is high that the 346 two peers are running on the same device. 348 To avoid this issue, browsers SHOULD NOT register mDNS names for 349 WebRTC applications running in a third-party browsing context (i.e., 350 a context that has a different origin than the top-level browsing 351 context), or a private browsing context. 353 3.3.5. Network Interface Enumeration 355 Even when local IP addresses are not exposed, the number of mDNS 356 hostname candidates can still provide a fingerprinting dimension. 357 This is in particular the case for network interfaces with limited 358 connectivity that will not generate server-reflexive or relay 359 candidates. 361 The more mDNS names an endpoint exposes through mDNS hostname 362 candidates, the higher the fingerprinting risk. One countermeasure 363 is to limit this number to a small value. 365 Note that no additional fingerprinting risk is introduced when 366 restricting mDNS hostname candidates to default route only. 368 3.3.6. Monitoring of Sessions 370 A malicious endpoint in the local network may also record other 371 endpoints who are registering, unregistering, and resolving mDNS 372 names. By doing so, they can create a session log that shows which 373 endpoints are communicating, and for how long. If both endpoints in 374 the session are on the same network, the fact they are communicating 375 can be discovered. 377 Mitigation of this threat is beyond the scope of this proposal. 379 4. Potential Limitations 381 4.1. Reduced Connectivity 383 With typical ICE, endpoints on the same network will usually be able 384 to establish a direct connection between their local IP addresses. 385 When using the mDNS technique, a direct connection is still possible, 386 but only if at least one side can properly resolve the provided mDNS 387 candidates. This may not be possible in all scenarios. 389 First, some networks may entirely disable mDNS. Second, mDNS queries 390 have limited scope. On large networks, this may mean that an mDNS 391 name cannot be resolved if the remote endpoint is too many segments 392 away. 394 When mDNS fails, ICE will attempt to fall back to either NAT hairpin, 395 if supported, or TURN relay if not. This may result in reduced 396 connectivity, reduced throughput and increased latency, as well as 397 increased cost in case of TURN relay. 399 One potential mitigation, as discussed in Section 3.3, is to not 400 conceal candidates created from [RFC4941] IPv6 addresses. This 401 permits connectivity even in large internal networks or where mDNS is 402 disabled. 404 The exact impact of the mDNS technique is being researched 405 experimentally and will be provided before publication of this 406 document. 408 4.2. Connection Setup Latency 410 As noted in Section 3, ICE agents using the mDNS technique are 411 responsible for registering and resolving mDNS names as part of the 412 ICE process. These steps may delay establishment of a direct peer- 413 to-peer connection, compared to when raw local IP addresses are used. 415 Given that these mDNS registrations and queries are typically 416 occurring on a local network, any associated delays should be small. 417 Also, as noted in Section 3.1, pre-registration can be employed to 418 eliminate gathering delays entirely. 420 4.3. Backward Compatibility 422 For the most part, backward compatibility does not present a 423 significant issue for the mDNS technique. When an endpoint that 424 supports mDNS communicates with an endpoint that does not, the legacy 425 endpoint will still provide its local IP addresses, and accordingly a 426 direct connection can still be attempted, even though the legacy 427 endpoint cannot resolve the mDNS names provided by the new endpoint. 428 In the event the legacy endpoint attempts to resolve mDNS names using 429 Unicast DNS, this may cause ICE to take somewhat longer to fully 430 complete, but should not have any effect on connectivity or 431 connection setup time. 433 However, some legacy endpoints are not fully spec-compliant and can 434 behave unpredictably in the presence of ICE candidates that contain a 435 hostname, potentially leading to ICE failure. Such endpoints have 436 been identified during testing of this technique, but appear to be 437 rare. 439 5. Examples 441 The examples below show how the mDNS technique is used during ICE 442 processing. The first example shows a simple case, the next two 443 examples demonstrate how peer-reflexive candidates for local IP 444 addresses can be created due to timing differences, and the final 445 example shows a real-world case with IPv4, IPv6, and STUN. 447 5.1. Normal Handling 449 In this example, mDNS candidates are exchanged between peers and 450 resolved normally to obtain the corresponding IP addresses. 452 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 453 | | 456 |------- mDNS Candidate N1 ------>| 457 | | 460 |<------ mDNS Candidate N2 -------| 461 | | mDNS name N1> 463 |<=== STUN check to 192.0.2.1 ====| 464 |==== STUN check to 192.0.2.2 ===>| 465 | | 467 The exchange of ICE candidates relies on out-of-band signaling, for 468 example, the SDP Offer/Answer procedure defined in [ICESDP]. In the 469 above example, the candidate attributes in the SDP messages to 470 exchange the mDNS candidates between ICE Agent 1 and 2 are as 471 follows: 473 ICE Agent 1: 475 a=candidate:1 1 udp 2122262783 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 476 54596 typ host 478 ICE Agent 2: 480 a=candidate:1 1 udp 2122262783 2579ef4b-50ae-4bfe-95af-70b3376ecb9c.local 481 61606 typ host 483 5.2. Peer-reflexive Candidate From Slow Signaling 485 In this example, a peer-reflexive candidate is generated because the 486 mDNS candidate is signaled after the STUN checks begin. 488 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 489 | | 492 |------- mDNS Candidate N1 ------>| 493 | | 495 |<=== STUN check to 192.0.2.1 ====| 496 prflx candidate | | 499 |<------ mDNS Candidate N2 -------| 500 | | 502 5.3. Peer-reflexive Candidate From Slow Resolution 504 In this example, a peer-reflexive candidate is generated because the 505 mDNS resolution for name N2 does not complete until after the STUN 506 checks are received. 508 ICE Agent 1 (192.0.2.1) ICE Agent 2 (192.0.2.2) 509 | | 192.0.2.2> 512 |------- mDNS Candidate N1 ------>| 513 |<------ mDNS Candidate N2 -------| 514 516 . |<=== STUN check to 192.0.2.1 ====| 517 . prflx candidate | | 518 . 192.0.2.2 created | | 519 name | | 520 N2> | | 522 5.4. IPv4, IPv6, and STUN handling 524 This last example demonstrates the overall ICE gathering process for 525 two endpoints, each with a private IPv4 address and a public IPv6 526 address. They preregister their mDNS names to speed up ICE 527 gathering. 529 ICE Agent 1 ICE Agent 2 530 192.168.1.1 STUN 192.168.1.2 531 2001:db8::1 Server 2001:db8::2 532 ---------------------------------------------------------------------- 533 Pre-registration of mDNS names 534 | | | 535 | | | 192.168.1.2> 538 | | | 2001:db8::2> 541 | | | 542 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 543 ICE Agent 1 sends mDNS candidates 544 | | | 545 |------- mDNS Candidate C1.1 ----->| 546 |------- mDNS Candidate C1.2 ----->| 547 | | | 550 | | | 553 | | | 554 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 555 ICE Agent 1 sends server-reflexive candidates 556 | | | 557 <192.168.1.1 |--Binding Req-->| | 558 is 192.0.2.1> |<-Binding Resp--| | 559 <192.0.2.1> |------ srflx Candidate C1.3 ----->| 560 <2001:db8::1 |--Binding Req-->| | 561 is 2001:db8::1> |<-Binding Resp--| | 562 <2001:db8::1> |------ srflx Candidate C1.4 ----->| 564 | | | 565 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 566 ICE Agent 2 sends mDNS candidates, resolution is slow 567 | | | 568 |<------ mDNS Candidate C2.1 ------| 569 |<------ mDNS Candidate C2.2 ------| 570 | | | 572 | | | 574 | | | 575 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 576 ICE Agent 2 sends server-reflexive candidates, resolution completes 577 | | | 578 | |<--Binding Req---| <192.168.1.2 579 | |---Binding Resp->| is 192.0.2.2> 580 |<----- srflx Candidate C2.3 ------| <192.0.2.2> 581 | |<--Binding Req---| <2001:db8::2 582 | |---Binding Resp->| is 2001:db8::2> 583 |<----- srflx Candidate C2.4 ------| <2001:db8::2> 584 | | | 585 <... N2.1 is | | | 586 192.168.1.2> | | | 587 <... N2.2 is | | | 588 2001:db8::2, | | | 589 discard C2.4> | | | 590 | | | 591 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 592 ICE connectivity checks 593 | | | 594 2001:db8::1 |<============= STUN ==============| 2001:db8::2 595 2001:db8::1 |============== STUN =============>| 2001:db8::2 596 192.168.1.1 |<============= STUN ==============| 192.168.1.2 597 192.168.1.1 |============== STUN =============>| 192.168.1.2 598 192.0.2.1 | Failed <-- STUN --------------| 192.168.1.2 599 192.168.1.1 |---------------STUN --> Failed | 192.0.2.2 600 2001:db8::1 |====== STUN(USE-CANDIDATE) ======>| 2001:db8::2 602 Ice Agent 1 candidates: 604 C1.1: candidate:1 1 udp 2122262783 9b36eaac-bb2e-49bb-bb78- 605 21c41c499900.local 10004 typ host 606 C1.2: candidate:2 1 udp 2122262527 76c82649-02d6-4030-8aef- 607 a2ba3a9019d5.local 10006 typ host 608 C1.3: candidate:1 1 udp 1686055167 192.0.2.1 609 30004 typ srflx raddr 0.0.0.0 rport 0 610 C1.4: candidate:2 1 udp 1686054911 2001:db8::1 611 10006 typ srflx raddr 0.0.0.0 rport 0 613 Ice Agent 2 candidates: 615 C2.1: candidate:1 1 udp 2122262783 b977f597-260c-4f70-9ac4- 616 26e69b55f966.local 20004 typ host 617 C2.2: candidate:2 1 udp 2122262527 ac4595a7-7e42-4e85-85e6- 618 c292abe0e681.local 20006 typ host 619 C2.3: candidate:1 1 udp 1686055167 192.0.2.2 620 40004 typ srflx raddr 0.0.0.0 rport 0 621 C2.4: candidate:2 1 udp 1686054911 2001:db8::2 622 20006 typ srflx raddr 0.0.0.0 rport 0 624 6. Security Considerations 626 6.1. mDNS Message Flooding 628 The implementation of this proposal requires the mDNS querying 629 capability of the browser for registering mDNS names or adding remote 630 ICE host candidates with such names. It also requires the mDNS 631 responding capability of either the browser or the operating platform 632 of the browser for registering, removing or resolving mDNS names. In 633 particular, 635 o the registration of name requires optional probing queries and 636 mandatory announcing responses ([RFC6762], Section 8), and this is 637 performed at the beginning of ICE gathering; 639 o the addition of remote ICE host candidates with mDNS names 640 generates mDNS queries for names of each candidate; 642 o the removal of names could happen when the browsing context of the 643 ICE agent is destroyed in an implementation, and goodbye responses 644 should be sent to invalidate records generated by the ICE agent in 645 the local network ([RFC6762], Section 10.1). 647 A malicious Web application could flood the local network with mDNS 648 messages by: 650 o creating browsing contexts that create ICE agents and start 651 gathering of local ICE host candidates; 653 o destroying these local candidates soon after the name registration 654 is done; 656 o adding fictitious remote ICE host candidates with mDNS names. 658 [RFC6762] defines a general per-question and per-record multicast 659 rate limiting rule, in which a given question or record on a given 660 interface cannot be sent less than one second since its last 661 transmission. This rate limiting rule however does not mitigate the 662 above attacks, in which new names, hence new questions or records, 663 are constantly created and sent. Therefore, a browser-wide mDNS 664 message rate limit MUST be provided for all mDNS queries and 665 responses that are dispatched during the ICE candidate gathering and 666 processing described in Section 3. A browser MAY implement more 667 specific rate limits, e.g., to ensure a single origin does not 668 prevent other origins from registering, unregistering, or resolving 669 mDNS names. 671 6.2. Malicious Responses to Deny Name Registration 673 If the optional probing queries are implemented for the name 674 registration, a malicious endpoint in the local network, which is 675 capable of responding mDNS queries, could send responses to block the 676 use of the generated names. This would lead to the discarding of 677 this ICE host candidate as in Step 5 in Section 3.1. 679 The above attack can be mitigated by skipping the probing when 680 registering a name, which also conforms to Section 8 in [RFC6762], 681 given that the name is randomly generated for the probabilistic 682 uniqueness (e.g. a version 4 UUID) in Step 3 in Section 3.1. 683 However, a similar attack can be performed by exploiting the negative 684 responses (defined in [RFC6762], Section 8.1), in which NSEC resource 685 records are sent to claim the nonexistence of records related to the 686 gathered ICE host candidates. 688 The existence of malicious endpoints in the local network poses a 689 generic threat, and requires dedicated protocol suites to mitigate, 690 which is beyond the scope of this proposal. 692 6.3. Unsolicited ICE Communications 694 As noted in Section 4.2 of [RTCWebSecurity], an attacker may use ICE 695 as a way to send unsolicited network traffic to specific endpoints. 696 While this is not specific to mDNS hostname candidates, this 697 technique makes it easier to target devices with well-known mDNS 698 names. 700 As noted in Section 3.2, ICE agents may decide to not resolve mDNS 701 names, for example, if these names are not in the format defined by 702 Section 3.1. 704 7. IANA Considerations 706 This document requires no actions from IANA. 708 8. References 710 8.1. Normative References 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, 714 DOI 10.17487/RFC2119, March 1997, 715 . 717 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 718 Unique IDentifier (UUID) URN Namespace", RFC 4122, 719 DOI 10.17487/RFC4122, July 2005, 720 . 722 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 723 Extensions for Stateless Address Autoconfiguration in 724 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 725 . 727 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 728 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 729 DOI 10.17487/RFC5389, October 2008, 730 . 732 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 733 Relays around NAT (TURN): Relay Extensions to Session 734 Traversal Utilities for NAT (STUN)", RFC 5766, 735 DOI 10.17487/RFC5766, April 2010, 736 . 738 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 739 DOI 10.17487/RFC6762, February 2013, 740 . 742 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 743 Connectivity Establishment (ICE): A Protocol for Network 744 Address Translator (NAT) Traversal", RFC 8445, 745 DOI 10.17487/RFC8445, July 2018, 746 . 748 8.2. Informative References 750 [HTMLSpec] 751 "HTML Living Standard", n.d., 752 . 754 [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ 755 Answer procedures for Interactive Connectivity 756 Establishment (ICE)", April 2018, 757 . 760 [IPHandling] 761 Shieh, G., "WebRTC IP Address Handling Requirements", 762 April 2018, . 765 [Overview] 766 Alvestrand, H., "Overview: Real Time Protocols for 767 Browser-based Applications", November 2017, 768 . 770 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 771 and E. Lear, "Address Allocation for Private Internets", 772 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 773 . 775 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 776 NAT64: Network Address and Protocol Translation from IPv6 777 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 778 April 2011, . 780 [RTCWebSecurity] 781 Rescorla, E., "Security Considerations for WebRTC", 782 January 2018, 783 . 785 [WebRTCSpec] 786 Bruaroey, J., "The WebRTC specification", n.d., 787 . 789 Authors' Addresses 791 Youenn Fablet 792 Apple Inc. 794 Email: youenn@apple.com 795 Jeroen de Borst 796 Google 798 Email: jeroendb@google.com 800 Justin Uberti 801 Google 803 Email: juberti@google.com 805 Qingsi Wang 806 Google 808 Email: qingsi@google.com