Using Multicast DNS to protect privacy when exposing ICE candidatesApple Inc.youenn@apple.comGooglejeroendb@google.comGooglejuberti@google.comGoogleqingsi@google.com
General
MMUSICInternet-DraftWebRTC 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 dynamically generated Multicast DNS (mDNS) names.As detailed in , 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. 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 suboptimal
connections in WebRTC applications. This is particularly an issue on unmanaged
networks, typically homes or small offices, where NAT loopback may not be
supported.This document proposes an overall solution to this problem by extending
to allow ICE implementations to register ephemeral mDNS
names for local private IP addresses, and then provide those names, rather than
the IP addresses, in their ICE candidates. While this technique is intended
to benefit WebRTC implementations in web browsers, by preventing collection
of private IP addresses by arbitrary web pages, it can also be used by any
endpoint that wants to avoid disclosing information about its local network
to remote peers on other networks.WebRTC and WebRTC-compatible endpoints that receive ICE
candidates with mDNS names will resolve these names to IP addresses and
perform ICE processing as usual. In the case where the
endpoint is a web application, the WebRTC implementation will manage this
resolution internally and will not disclose the actual IP addresses to the
application.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in .This section uses the concept of ICE agent as defined in . In the
remainder of the document, it is assumed that each browsing context (as defined
in Section 7.1 of ) has its own ICE agent.This section outlines how mDNS should be used by ICE agents to conceal local
IP addresses.For each host candidate gathered by an ICE agent as part of the gathering
process described in , Section 5.1.1, the candidate is handled as
described below.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.Check whether the ICE agent has previously generated, registered, and stored
an mDNS hostname for this IP address as per steps 3 to 5. If it has, skip
ahead to step 6.Generate a unique mDNS hostname. The unique name MUST consist of a version 4
UUID as defined in , followed by “.local”.Register the candidate’s mDNS hostname as defined in . 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.Store the mDNS hostname and its related IP address in the ICE agent for
future reuse.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 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.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.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.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 address, the reverse is not
necessarily true. IPv6 addresses present their own complications, e.g.,
private IPv6 addresses as a result of NAT64 .Instead, the determination of whether an address is public can be reliably made
as part of the ICE gathering process. For each mDNS host candidate generated
according the guidance above, the usual STUN request is sent to
a STUN server. This can be done for 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 ,
Section 5.1.3. To avoid 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 , 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.As noted in , private IPv4 addresses are especially problematic
because of their unbounded lifetime. However, the 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 addresses with mDNS names
as a tradeoff for improved peer-to-peer connectivity.The mDNS name of an mDNS candidate MUST be used in the connection-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 , 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).This section outlines how received ICE candidates with mDNS names are
processed by ICE agents, and is relevant to all endpoints.For any remote ICE candidate received by the ICE agent, the following procedure
is used: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 .If the ICE candidate policy is “relay”, as defined in , ignore the candidate.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.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 .Otherwise, ignore the candidate.An ICE agent may use a hostname resolver that transparently supports both
Multicast and Unicast DNS. In this case the resolution of a “.local” name may
happen through Unicast DNS as noted in , Section 3.An ICE agent SHOULD ignore candidates where the hostname resolution returns
more than one IP address.An ICE agent MAY add additional restrictions regarding the ICE candidates it
will resolve using mDNS, as this mechanism allows attackers to send ICE traffic
to devices with well-known mDNS names. In particular, ICE agents SHOULD NOT
resolve mDNS names if they are not in the format defined by .The goal of this mechanism is to keep knowledge of private host IP
addresses within the ICE agent while continuing to allow the
application to transmit ICE candidates. Besides keeping private
host IP addresses out of ICE candidates, implementations must take
steps to prevent these IP addresses from being exposed to web
applications through other means.Statistics related to ICE candidates that are accessible to the web
application MUST NOT contain the IP address of a local or remote mDNS
candidate; the mDNS name SHOULD be used instead.Statistics SHOULD NOT leak whether the mDNS resolution succeeds or fails.
For that reason, RTCIceCandidateStats objects as defined in
SHOULD be generated for any remote mDNS candidate submitted to the ICE agent,
even if the mDNS candidate is ignored as part of .
An implementation strategy to obfuscate the address of an mDNS candidate in the statistics, regardless if it is resolved or not, is to replace
the mDNS hostname of the ICE candidate with IP values “0.0.0.0” or “::”.In addition, a peer-reflexive remote candidate may be constructed
from a remote host IP address as a result of an ICE connectivity
check, as described in Section 7.3.1.3 of . This check
may arrive before the candidate due to signaling or mDNS
resolution delays, as shown in the examples above.To prevent disclosure of the host IP address to the application in
this scenario, statistics related to ICE candidates MUST NOT
contain the IP address of any peer-reflexive candidate, unless that IP
has already been learned through signaling of a candidate with the
same address and either the same or a different port; this includes cases
where the signaled candidate is discarded as redundant according to
Section 5.1.3 of .When sending data to a TURN server, the sending client tells
the server the destination IP and port for the data. This means that
if the client uses TURN to send to an IP that was obtained by mDNS
resolution, the TURN server will learn the underlying host IP and port,
and this information can then be relayed to the web application,
defeating the value of the mDNS wrapping.To prevent disclosure of the host IP address to a TURN server, the ICE
agent MUST NOT form candidate pairs between its own relay candidates
and remote mDNS candidates. This restriction applies to all remote mDNS
candidate types, not just host candidates; mDNS candidates can be
clearly identified from their connection-address fields.
Note also that the converse is not an issue;
the ICE agent MAY form candidate pairs between its own mDNS candidates and
remote relay candidates, as in this situation host IPs will not be sent
directly to the TURN server.This restriction has no effect on connectivity; in the cases where
host IP addresses are private and need to be wrapped with mDNS names,
they will be unreachable from the TURN server, and as noted above,
the reverse path will continue to work normally.It is important that use of registered mDNS hostnames is limited in time
and/or scope. Indefinitely reusing the same mDNS hostname candidate would
provide applications an even more reliable tracking mechanism than the private
IP addresses that this specification is designed to hide. In the case of a web
application, the use of registered mDNS hostnames SHOULD be scoped by the web
application origin, and SHOULD have the lifetime of the page executing the web
application.As noted in , privacy may be breached if a web application running
in two browsing contexts can determine whether it is running on the same device.
While the approach in this document prevents the application from directly
comparing local private IP addresses, a successful local WebRTC connection
can also present a threat to user privacy. Specifically, when the latency of a
WebRTC connection latency is close to zero, the probability is high that the
two peers are running on the same device.To avoid this issue, browsers SHOULD NOT register mDNS names for WebRTC
applications running in a third-party browsing context (i.e., a context that
has a different origin than the top-level browsing context), or a private
browsing context.Even when local IP addresses are not exposed, the number of mDNS hostname
candidates can still provide a fingerprinting dimension. This is in particular
the case for network interfaces with limited connectivity that will not generate
server-reflexive or relay candidates.The more mDNS names an endpoint exposes through mDNS hostname candidates, the
higher the fingerprinting risk. One countermeasure is to limit this number to a
small value.Note that no additional fingerprinting risk is introduced when restricting mDNS
hostname candidates to default route only.A malicious endpoint in the local network may also record other endpoints who
are registering, unregistering, and resolving mDNS names. By doing so, they can
create a session log that shows which endpoints are communicating, and for how
long. If both endpoints in the session are on the same network, the fact they
are communicating can be discovered.Mitigation of this threat is beyond the scope of this proposal.Section 5.1 of states:An agent generating local candidates MUST NOT use FQDN addresses.
An agent processing remote candidates MUST ignore candidate lines that
include candidates with FQDN or IP address versions that are not supported
or recognized.This document extends to specifically allow the generation and
processing of ICE candidates with the “.local” FQDNs defined in {gathering}.
The restrictions on other FQDNs are unaffected.With typical ICE, endpoints on the same network will usually be able to
establish a direct connection between their local IP addresses. When using the
mDNS technique, a direct connection is still possible, but only if at least one
side can properly resolve the provided mDNS candidates. This may not be possible
in all scenarios.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.As noted in , 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. Also, as noted in
, pre-registration can be employed to eliminate gathering delays
entirely.For the most part, backward compatibility does not present a significant issue
for the mDNS technique. When an endpoint that supports mDNS communicates with
an endpoint that does not, the legacy 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. 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.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.In this example, mDNS candidates are exchanged between peers and resolved
normally to obtain the corresponding IP addresses.The exchange of ICE candidates relies on out-of-band signaling, for example,
the SDP Offer/Answer procedure defined in . In the above example,
the candidate attributes in the SDP messages to exchange the mDNS candidates
between ICE Agent 1 and 2 are as follows:ICE Agent 1:ICE Agent 2:In this example, a peer-reflexive candidate is generated because the
mDNS candidate is signaled after the STUN checks begin.In this example, a peer-reflexive candidate is generated because the
mDNS resolution for name N2 does not complete until after the STUN checks are
received.This last example demonstrates the overall ICE gathering process for two
endpoints, each with a private IPv4 address and a public IPv6 address. They
preregister their mDNS names to speed up ICE gathering.Ice Agent 1 candidates:Ice Agent 2 candidates:The implementation of this proposal requires the mDNS querying capability of the
browser for registering mDNS names or adding remote ICE host candidates with
such names. It also requires the mDNS responding capability of either the
browser or the operating platform of the browser for registering, removing or
resolving mDNS names. In particular,the registration of name requires optional probing queries and mandatory
announcing responses (, Section 8), and this is performed at the
beginning of ICE gathering;the addition of remote ICE host candidates with mDNS names generates mDNS
queries for names of each candidate;the removal of names could happen when the browsing context of the ICE agent
is destroyed in an implementation, and goodbye responses should be sent to
invalidate records generated by the ICE agent in the local network
(, Section 10.1).A malicious Web application could flood the local network with mDNS messages by:creating browsing contexts that create ICE agents and start gathering of
local ICE host candidates;destroying these local candidates soon after the name registration is done;adding fictitious remote ICE host candidates with mDNS names. defines a general per-question and per-record multicast rate
limiting rule, in which a given question or record on a given interface cannot be
sent less than one second since its last transmission. This rate limiting rule
however does not mitigate the above attacks, in which new names, hence new
questions or records, are constantly created and sent. Therefore, a browser-wide
mDNS message rate limit MUST be provided for all mDNS queries and responses that
are dispatched during the ICE candidate gathering and processing described in
. A browser MAY implement more specific rate limits, e.g., to
ensure a single origin does not prevent other origins from registering,
unregistering, or resolving mDNS names.If the optional probing queries are implemented for the name registration, a
malicious endpoint in the local network, which is capable of responding mDNS
queries, could send responses to block the use of the generated names. This
would lead to the discarding of this ICE host candidate as in Step 5 in
.The above attack can be mitigated by skipping the probing when registering a
name, which also conforms to Section 8 in , given that the name is
randomly generated for the probabilistic uniqueness (e.g. a version 4 UUID) in
Step 3 in . However, a similar attack can be performed by
exploiting the negative responses (defined in , Section 8.1), in
which NSEC resource records are sent to claim the nonexistence of records
related to the gathered ICE host candidates.The existence of malicious endpoints in the local network poses a generic
threat, and requires dedicated protocol suites to mitigate, which is beyond the
scope of this proposal.As noted in Section 4.2 of , an attacker may use ICE as a way
to send unsolicited network traffic to specific endpoints. While this is not
specific to mDNS hostname candidates, this technique makes it easier to
target devices with well-known mDNS names.Also, the same technique can be used as an oracle to determine whether some
local services are reachable in the local network. This knowledge can be used
for fingerprinting purposes or as a basis for attacking local networks.As noted in , ICE agents are discouraged to resolve mDNS names
that are not in the format defined by and may further constrain
the mDNS names they will actually try to resolve.This document requires no actions from IANA.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.A Universally Unique IDentifier (UUID) URN NamespaceThis specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]Privacy Extensions for Stateless Address Autoconfiguration in IPv6Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]Session Traversal Utilities for NAT (STUN)Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.This document obsoletes RFC 3489. [STANDARDS-TRACK]Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS-TRACK]Multicast DNSAs networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) TraversalThis document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).This document obsoletes RFC 5245.Address Allocation for Private InternetsThis document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 ServersSession Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)WebRTC IP Address Handling RequirementsOverview: Real Time Protocols for Browser-based ApplicationsThe WebRTC specificationIdentifiers for WebRTC's Statistics APIHTML Living StandardSecurity Considerations for WebRTCJavaScript Session Establishment Protocol