--- 1/draft-ietf-rtcweb-mdns-ice-candidates-03.txt 2019-10-16 17:13:11.159941692 -0700 +++ 2/draft-ietf-rtcweb-mdns-ice-candidates-04.txt 2019-10-16 17:13:11.203942815 -0700 @@ -1,21 +1,21 @@ RTCWEB Y. Fablet Internet-Draft Apple Inc. Intended status: Informational J. de Borst -Expires: September 26, 2019 J. Uberti +Expires: April 18, 2020 J. Uberti Q. Wang Google - March 25, 2019 + October 16, 2019 Using Multicast DNS to protect privacy when exposing ICE candidates - draft-ietf-rtcweb-mdns-ice-candidates-03 + draft-ietf-rtcweb-mdns-ice-candidates-04 Abstract WebRTC applications collect ICE candidates as part of the process of creating peer-to-peer connections. To maximize the probability of a direct peer-to-peer connection, client private IP addresses are included in this candidate collection. However, disclosure of these addresses has privacy implications. This document describes a way to share local IP addresses with other clients while preserving client privacy. This is achieved by concealing IP addresses with @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 26, 2019. + This Internet-Draft will expire on April 18, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,49 +53,49 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1.2. Implementation Guidance . . . . . . . . . . . . . . . 4 + 3.1.2. Implementation Guidance . . . . . . . . . . . . . . . 5 3.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 6 3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2.2. Implementation Guidance . . . . . . . . . . . . . . . 6 - 3.3. Additional Privacy Considerations . . . . . . . . . . . . 6 + 3.2.2. Implementation Guidance . . . . . . . . . . . . . . . 7 + 3.3. Additional Privacy Considerations . . . . . . . . . . . . 7 3.3.1. Statistics . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Interactions With TURN Servers . . . . . . . . . . . 7 3.3.3. Generated Name Reuse . . . . . . . . . . . . . . . . 8 3.3.4. Specific Browsing Contexts . . . . . . . . . . . . . 8 3.3.5. Network Interface Enumeration . . . . . . . . . . . . 8 - 3.3.6. Monitoring of Sessions . . . . . . . . . . . . . . . 8 + 3.3.6. Monitoring of Sessions . . . . . . . . . . . . . . . 9 4. Potential Limitations . . . . . . . . . . . . . . . . . . . . 9 4.1. Reduced Connectivity . . . . . . . . . . . . . . . . . . 9 - 4.2. Connection Setup Latency . . . . . . . . . . . . . . . . 9 + 4.2. Connection Setup Latency . . . . . . . . . . . . . . . . 10 4.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10 - 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.1. Normal Handling . . . . . . . . . . . . . . . . . . . . . 10 - 5.2. Peer-reflexive Candidate From Slow Signaling . . . . . . 11 - 5.3. Peer-reflexive Candidate From Slow Resolution . . . . . . 11 + 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.1. Normal Handling . . . . . . . . . . . . . . . . . . . . . 11 + 5.2. Peer-reflexive Candidate From Slow Signaling . . . . . . 12 + 5.3. Peer-reflexive Candidate From Slow Resolution . . . . . . 12 5.4. IPv4, IPv6, and STUN handling . . . . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 6.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 14 - 6.2. Malicious Responses to Deny Name Registration . . . . . . 15 - 6.3. Unsolicited ICE Communications . . . . . . . . . . . . . 15 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 6.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 15 + 6.2. Malicious Responses to Deny Name Registration . . . . . . 16 + 6.3. Unsolicited ICE Communications . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction As detailed in [IPHandling], exposing client private IP addresses by default to web applications maximizes the probability of successfully creating direct peer-to-peer connections between clients, but creates a significant surface for user fingerprinting. [IPHandling] recognizes this issue, but also admits that there is no current solution to this problem; implementations that choose to use Mode 3 to address the privacy concerns often suffer from failing or @@ -142,54 +142,64 @@ For each host candidate gathered by an ICE agent as part of the gathering process described in [RFC8445], Section 5.1.1, the candidate is handled as described below. 1. Check whether this IP address satisfies the ICE agent's policy regarding whether an address is safe to expose. If so, expose the candidate and abort this process. 2. Check whether the ICE agent has previously generated, registered, - and stored an mDNS hostname for this IP address as per Steps 3, - 4, and 6. If it has, skip ahead to Step 7. + and stored an mDNS hostname for this IP address as per steps 3 to + 5. If it has, skip ahead to step 6. 3. Generate a unique mDNS hostname. The unique name MUST consist of a version 4 UUID as defined in [RFC4122], followed by ".local". 4. Register the candidate's mDNS hostname as defined in [RFC6762]. + The ICE agent SHOULD send an mDNS announcement for the hostname, + but as the hostname is expected to be unique, the ICE agent + SHOULD skip probing of the hostname. - 5. If registering of the mDNS hostname fails, abort these steps. - The candidate is not exposed. - - 6. Store the mDNS hostname and its related IP address in the ICE + 5. Store the mDNS hostname and its related IP address in the ICE agent for future reuse. - 7. Replace the IP address of the ICE candidate with its mDNS + 6. Replace the IP address of the ICE candidate with its mDNS hostname and provide the candidate to the web application. ICE agents can implement this procedure in any way as long as it produces equivalent results. An implementation may for instance pre- - register mDNS hostnames by executing steps 3 to 6 and prepopulate an - ICE agent accordingly. By doing so, only step 7 of the above + register mDNS hostnames by executing steps 3 to 5 and prepopulate an + ICE agent accordingly. By doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. - An implementation may also detect that mDNS is not supported by the - available network interfaces. The ICE agent may skip steps 3 and 4 - and directly decide to not expose the host candidate. + In order to prevent web applications from using this mechanism to + query for mDNS support in the local network, the ICE agent SHOULD + still provide mDNS candidates in step 6 even if the local network + does not support mDNS or mDNS registration fails in step 4. This procedure ensures that an mDNS name is used to replace only one IP address. Specifically, an ICE agent using an interface with both IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. 3.1.2. Implementation Guidance -3.1.2.1. Determining Address Privacy and Server-Reflexive Candidates + +3.1.2.1. Registration + + Sending the mDNS announcement to the network can be delayed, for + instance due to rate limits. An ICE agent SHOULD provide the + candidate to the web application as soon as its mDNS name is + generated, regardless of whether the announcement has been sent on + the network. + +3.1.2.2. Determining Address Privacy and Server-Reflexive Candidates Naturally, an address that is already exposed to the Internet does not need to be protected by mDNS, as it can be trivially observed by the web server or remote endpoint. However, determining this ahead of time is not straightforward; while the fact that an IPv4 address is private can sometimes be inferred by its value, e.g., whether it is an [RFC1918] address, the reverse is not necessarily true. IPv6 addresses present their own complications, e.g., private IPv6 addresses as a result of NAT64 [RFC6146]. @@ -200,65 +210,73 @@ both IPv4 and IPv6 local addresses, provided that the application has configured both IPv4 and IPv6 STUN servers. If the STUN response returns the same value as the local IP address, this indicates the address is in fact public. Regardless of the result, a server-reflexive candidate will be generated; the transport address of this candidate is an IP address and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in [RFC8445], Section 5.1.3. To avoid - accidental IP address, this server-reflexive candidate MUST have its - raddr field set to 0.0.0.0 and its rport field set to 0. + accidental IP address disclosure, this server-reflexive candidate + MUST have its raddr field set to "0.0.0.0"/"::" and its rport field + set to "9", as discussed in [ICESDP], Section 9.1. Once an address has been identified as public, the ICE agent MAY cache this information and omit mDNS protection for that address in future ICE gathering phases. -3.1.2.2. Special Handling for IPv6 Addresses +3.1.2.3. Special Handling for IPv6 Addresses As noted in [IPHandling], private IPv4 addresses are especially problematic because of their unbounded lifetime. However, the [RFC4941] IPv6 addresses recommended for WebRTC have inherent privacy protections, namely a short lifetime and the lack of any stateful information. Accordingly, implementations MAY choose to not conceal [RFC4941] addresses with mDNS names as a tradeoff for improved peer- to-peer connectivity. -3.1.2.3. mDNS Candidate Encoding +3.1.2.4. mDNS Candidate Encoding The mDNS name of an mDNS candidate MUST be used in the connection- - address field of its candidate attribute. When an mDNS candidate is - the default candidate, its mDNS name MUST be used in the connection- - address field of the SDP "c=" line. Since an mDNS candidate also - conceals its address family, the "c=" line SHOULD use "IP4" in the - address-type field. + address field of its candidate attribute. However, when an mDNS + candidate would be the default candidate, typically because there are + no other candidates, its mDNS name MUST NOT be used in the + connection-address field of the SDP "c=" line, as experimental + deployment has indicated that many remote endpoints will fail to + handle such a SDP. In this situation, the IP address values + "0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and + m= lines, similar to how the no-candidates case is handled in + [ICESDP], Section 4.3.1. Any candidates exposed to the application via local descriptions MUST be identical to those provided during candidate gathering (i.e., MUST NOT contain private host IP addresses). 3.2. ICE Candidate Processing This section outlines how received ICE candidates with mDNS names are processed by ICE agents, and is relevant to all endpoints. 3.2.1. Procedure For any remote ICE candidate received by the ICE agent, the following procedure is used: 1. If the connection-address field value of the ICE candidate does not end with ".local" or if the value contains more than one ".", then process the candidate as defined in [RFC8445]. - 2. Otherwise, resolve the candidate using mDNS. + 2. Otherwise, resolve the candidate using mDNS. The ICE agent + SHOULD set the unicast-response bit of the corresponding mDNS + query message; this minimizes multicast traffic, as the response + is probably only useful to the querying node. 3. If it resolves to an IP address, replace the mDNS hostname of the ICE candidate with the resolved IP address and continue processing of the candidate as defined in [RFC8445]. 4. Otherwise, ignore the candidate. 3.2.2. Implementation Guidance An ICE agent may use a hostname resolver that transparently supports @@ -389,28 +407,36 @@ First, some networks may entirely disable mDNS. Second, mDNS queries have limited scope. On large networks, this may mean that an mDNS name cannot be resolved if the remote endpoint is too many segments away. When mDNS fails, ICE will attempt to fall back to either NAT hairpin, if supported, or TURN relay if not. This may result in reduced connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay. + During experimental testing of the mDNS technique across a set of + known mDNS-aware endpoints that had configured a STUN server but not + a TURN server, the observed impact to ICE connection rate was 2% + (relative) when mDNS was enabled on both sides, compared to when mDNS + was only enabled on one side. In this testing, the percentage of + connections that required STUN (i.e., went through a NAT) increased + from 94% to 97%, indicating that mDNS succeeded about half the time, + and fell back to NAT hairpin for the remainder. The most likely + explanation for the overall connection rate drop is that hairpinning + failed in some cases. + One potential mitigation, as discussed in Section 3.3, is to not conceal candidates created from [RFC4941] IPv6 addresses. This permits connectivity even in large internal networks or where mDNS is - disabled. - - The exact impact of the mDNS technique is being researched - experimentally and will be provided before publication of this - document. + disabled. Future versions of this document will include experimental + data regarding this option. 4.2. Connection Setup Latency As noted in Section 3, ICE agents using the mDNS technique are responsible for registering and resolving mDNS names as part of the ICE process. These steps may delay establishment of a direct peer- to-peer connection, compared to when raw local IP addresses are used. Given that these mDNS registrations and queries are typically occurring on a local network, any associated delays should be small. @@ -425,23 +451,26 @@ endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint. In the event the legacy endpoint attempts to resolve mDNS names using Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a - hostname, potentially leading to ICE failure. Such endpoints have - been identified during testing of this technique, but appear to be - rare. + hostname, potentially leading to ICE failure. Some endpoints may + also fail to handle a connectivity check from an address that they + have not received in signaling. During the aforementioned + experimental testing, the connection rate when interacting with + endpoints that provided raw IP addresses (and therefore should be + unaffected) decreased by 3% (relative), presumably for these reasons. 5. Examples The examples below show how the mDNS technique is used during ICE processing. The first example shows a simple case, the next two examples demonstrate how peer-reflexive candidates for local IP addresses can be created due to timing differences, and the final example shows a real-world case with IPv4, IPv6, and STUN. 5.1. Normal Handling @@ -747,27 +776,27 @@ 8.2. Informative References [HTMLSpec] "HTML Living Standard", n.d., . [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ Answer procedures for Interactive Connectivity Establishment (ICE)", April 2018, - . + . [IPHandling] Shieh, G., "WebRTC IP Address Handling Requirements", - April 2018, . + April 2018, . [Overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", November 2017, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, .