draft-ietf-rtcweb-mdns-ice-candidates-00.txt   draft-ietf-rtcweb-mdns-ice-candidates-01.txt 
RTCWEB Y. Fablet RTCWEB Y. Fablet
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational J. De Borst Intended status: Informational J. de Borst
Expires: March 16, 2019 J. Uberti Expires: April 25, 2019 J. Uberti
Q. Wang Q. Wang
Google Google
September 12, 2018 October 22, 2018
Using Multicast DNS to protect privacy when exposing ICE candidates Using Multicast DNS to protect privacy when exposing ICE candidates
draft-ietf-rtcweb-mdns-ice-candidates-00 draft-ietf-rtcweb-mdns-ice-candidates-01
Abstract Abstract
WebRTC applications rely on ICE candidates to enable peer-to-peer WebRTC applications collect ICE candidates as part of the process of
connections between clients in as many network configurations as creating peer-to-peer connections. To maximize the probability of a
possible. To maximize the probability to create a direct peer-to- direct peer-to-peer connection, client private IP addresses are
peer connection, client private IP addresses are often exposed included in this candidate collection. However, disclosure of these
without user consent. This is currently used as a way to track addresses has privacy implications. This document describes a way to
users. This document describes a way to share IP addresses with share local IP addresses with other clients while preserving client
other clients while preserving client privacy. This is achieved by privacy. This is achieved by obfuscating IP addresses with
obfuscating IP addresses using dynamically generated names resolvable dynamically generated Multicast DNS (mDNS) [RFC6762] names.
through Multicast DNS [RFC6763].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 3 2. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3
3.1. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 3 2.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 4
3.2. ICE Candidate Processing . . . . . . . . . . . . . . . . 4 2.2.1. Handling of Peer-Reflexive Remote Candidate . . . . . 4
4. Privacy Guidelines . . . . . . . . . . . . . . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. APIs leaking IP addresses . . . . . . . . . . . . . . . . 4 4. Privacy Guidelines . . . . . . . . . . . . . . . . . . . . . 6
4.2. Generated names reuse . . . . . . . . . . . . . . . . . . 5 4.1. APIs Leaking IP Addresses . . . . . . . . . . . . . . . . 6
4.3. Specific execution contexts . . . . . . . . . . . . . . . 5 4.2. Interactions With TURN Servers . . . . . . . . . . . . . 6
5. Specification Requirements . . . . . . . . . . . . . . . . . 5 4.3. Generated Names Reuse . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . 5 4.4. Specific Browsing Contexts . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5.1. mDNS Message Flooding . . . . . . . . . . . . . . . . . . 7
5.2. Malicious Responses to Deny Name Registration . . . . . . 8
5.3. Monitoring of Sessions . . . . . . . . . . . . . . . . . 9
6. Specification Requirements . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
As detailed in [IPHandling], exposing client private IP addresses As detailed in [IPHandling], exposing client private IP addresses by
allows maximizing the probability to successfully create a connection default maximizes the probability of successfully creating direct
between two clients. This information is also used by many web sites peer-to-peer connection between two clients, but creates a
as a way to fingerprint and identify users without their consent. 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 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.
The first approach exposes client private IP addresses by default, as This document proposes an overall solution to this problem by
can be seen from websites such as [IPLeak]. The second approach registering ephemeral mDNS names for each local private IP address,
implemented in the WebKit engine enforces the following policy: and then providing those names, rather than the IP addresses, to the
web application when it gathers ICE candidates. WebRTC
implementations resolve these names to IP addresses and perform ICE
processing as usual, but the actual IP addresses are not exposed to
the web application.
1. By default, use mode 3 as defined in [IPHandling]: any host ICE 2. Principle
candidate is filtered out.
2. Use mode 2 as defined in [IPHandling] if there is an explicit This section uses the concept of ICE agent as defined in [RFC8445].
user action to trust the web site: host ICE candidates are In the remainder of the document, it is assumed that each browsing
exposed to the web site based on the use of context (as defined in Section 7.1 of [HTMLSpec]) has its own ICE
navigator.mediaDevices.getUserMedia, which typically prompts the agent.
user to grant or deny access to cameras/microphones.
The second approach supports most common audio/video conference 2.1. ICE Candidate Gathering
applications but leads to failing or suboptimal connections for
applications relying solely on data channel. This is particularly an
issue on unmanaged networks, typically home or small offices where
NAT loopback might not be supported.
To overcome the shortcomings of the above two approaches, this For any host candidate gathered by an ICE agent as part of [RFC8445]
document proposes to register dynamically generated names using section 5.1.1, the candidate is processed as follows:
Multicast DNS when gathering ICE candidates. These dynamically
generated names are used to replace private IP addresses in host ICE
candidates. Only clients that can resolve these dynamically
generated names using Multicast DNS will get access to the actual
client IP address.
2. Privacy Concerns 1. Check whether the ICE agent has a usable registered mDNS hostname
resolving to the ICE candidate's IP address. If one exists, skip
ahead to Step 6.
The gathering of ICE candidates without user consent is a well-known 2. Generate a unique mDNS hostname. The unique name MUST consist of
fingerprinting technique to track users. This is particularly a a version 4 UUID as defined in [RFC4122], followed by ".local".
concern when users are connected through a NAT which is a usual
configuration. In such a case, knowing both the private IP address
and the public IP address will usually identify uniquely the user
device. Additionally, Internet web sites can more easily attack
intranet web sites when knowing the intranet IP address range.
A successful WebRTC connection between two peers is also a potential 3. Register the candidate's mDNS hostname as defined in [RFC6762].
thread to user privacy. When a WebRTC connection latency is close to
zero, the probability is high that the two peers are running on the
same device. Browsers often isolate contexts one from the other.
Private browsing mode contexts usually do not share any information
with regular browsing contexts. The WebKit engine isolates third-
party iframes in various ways (cookies, ITP) to prevent user
tracking. Enabling a web application to determine that two contexts
run in the same device would defeat some of the protections provided
by modern browsers.
3. Principle 4. If registering of the mDNS hostname fails, abort these steps.
The candidate is not exposed.
This section uses the concept of ICE agent as define in [RFC5245]. 5. Store the mDNS hostname and its related IP address in the ICE
In the remainder of the document, it is assumed that each browser agent for future reuse.
execution context has its own ICE agent.
3.1. ICE Candidate Gathering 6. Replace the IP address of the ICE candidate with its mDNS
hostname, and expose the candidate as usual.
For any host ICE candidate gathered by a browsing context as part of An ICE agent can implement this procedure in any way so long as it
[RFC5245] section 4.1.1, obfuscation of the candidate is done as produces equivalent results to this procedure.
follows:
1. Check whether the context ICE agent registered a name resolving An implementation may for instance pre-register mDNS hostnames by
to the ICE host candidate IP address. 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.
2. If the ICE agent registered the name, replace the IP address of An implementation may also detect that mDNS is not supported by the
the ICE host candidate with the name with ".local" appended to available network interfaces. The ICE agent may skip steps 2 and 3
it. Expose the candidate and abort these steps. and directly decide to not expose the host candidate.
3. Generate a random unique name, typically a version 4 UUID as This procedure ensures that a mDNS name is used to replace only one
defined in [RFC4122]. IP address. Specifically, an ICE agent using an interface with both
IPv4 and IPv6 addresses MUST expose a different mDNS name for each
address.
4. Register the unique name using Multicast DNS. 2.2. ICE Candidate Processing
5. If registering of the unique name fails, abort these steps. The For any remote ICE candidate received by the ICE agent, the following
candidate is not exposed. procedure is used:
6. Store the name and its related IP address in the ICE agent for 1. If the connection-address field value of the ICE candidate does
future reuse. not end with ".local" or if the value contains more than one ".",
then process the candidate as defined in [RFC8445].
7. Replace the IP address of the ICE host candidate with the name 2. Otherwise, resolve the candidate using mDNS.
with ".local" appended to it. Expose the candidate.
3.2. ICE Candidate Processing 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.
For any remote host ICE candidate received by the ICE agent, the 4. Otherwise, ignore the candidate.
following procedure is used:
1. If the connection-address field value of the ICE candidate does An ICE agent may use a hostname resolver that transparently supports
not finish by ".local", process the candidate as defined in both Multicast and Unicast DNS. In this case the resolution of a
[RFC5245]. ".local" name may happen through Unicast DNS, see [RFC6762] section
3.
2. Otherwise, remove the ".local" suffix to the value and resolve it An ICE agent that supports mDNS candidates MUST support the situation
using Multicast DNS. where the hostname resolution results in more than one IP address.
In this case, the ICE agent MUST take exactly one of the resolved IP
addresses and ignore the others. The ICE agent SHOULD, if available,
use the first IPv6 address resolved, otherwise the first IPv4
address.
3. If it resolves to an IP address, replace the value of the ICE 2.2.1. Handling of Peer-Reflexive Remote Candidate
host candidate by the resolved IP address and continue processing
of the candidate.
4. Otherwise, ignore the candidate. A peer-reflexive remote candidate could be learned and constructed
from the source transport address of the STUN Binding request as an
ICE connectivity check. The peer-reflexive candidate could share the
same address as a remote mDNS candidate that is in the process of
being signaled or name resolution.
Multicast DNS resolution might end up retrieving both an IPv4 and In addition to the elimination procedure of redundant candidates
IPv6 address. In that case, the IPv6 address may be used preferably defined in Section 5.1.3 of [RFC8445], which could remove constructed
to the IPv4 address. peer-reflexive remote candidates, the address of any existing peer-
reflexive remote candidate should not be exposed to Web applications
by ICE agents that implement this proposal, as detailed in Section 4.
3. Examples
In this example, mDNS candidates are exchanged between peers and
resolved to obtain the corresponding IP addresses.
ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2)
<Register | |
mDNS name N1 | |
for 1.1.1.1> | |
|----------- mDNS Candidate N1 ---------->|
| | <Register
| | mDNS name N2
| | for 2.2.2.2>
|<---------- mDNS Candidate N2 -----------|
<Resolve | | <Resolve
mDNS name N2> | | mDNS name N1>
|<======== STUN check to 1.1.1.1 =========|
|========= STUN check to 2.2.2.2 ========>|
| |
The following two examples indicate how peer-reflexive candidates for
host IP addresses can be created due to timing differences.
In this example, a peer-reflexive candidate is generated because the
mDNS candidate is signaled after the STUN checks begin.
ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2)
<Register | |
mDNS name N1 | |
for 1.1.1.1> | |
|----------- mDNS Candidate N1 ---------->|
| | <Resolve
| | mDNS name N1>
|<======== STUN check to 1.1.1.1 =========|
prflx candidate | | <Register
2.2.2.2 created | | mDNS name N2
| | for 2.2.2.2>
|<---------- mDNS Candidate N2 -----------|
| |
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.
ICE Agent 1 (1.1.1.1) ICE Agent 2 (2.2.2.2)
<Register | | <Register
mDNS name N1 | | mDNS name N2
for 1.1.1.1> | | for 2.2.2.2>
|----------- mDNS Candidate N1 ---------->|
|<---------- mDNS Candidate N2 -----------|
<Resolve | | <Resolve
... | | mDNS name N1>
mDNS |<======== STUN check to 1.1.1.1 =========|
... prflx candidate | |
name 2.2.2.2 created | |
... | |
N2> | |
4. Privacy Guidelines 4. Privacy Guidelines
4.1. APIs leaking IP addresses 4.1. APIs Leaking IP Addresses
When there is no user consent, the following filtering should be done When there is no user consent, the following filtering should be done
to prevent private IP address leakage: to prevent private IP address leakage:
1. host ICE candidates with an IP address are not exposed as ICE 1. ICE candidates with an IP address are not exposed as ICE
candidate events. candidate events.
2. Server reflexive ICE candidate raddr field is set to 0.0.0.0 and 2. Server reflexive ICE candidate raddr field is set to 0.0.0.0 and
rport to 0. rport to 0.
3. SDP does not expose any a=candidate line corresponding to a host 3. SDP does not expose any a=candidate line corresponding to an ICE
ICE candidate which contains an IP address. candidate which contains an IP address.
4. RTCIceCandidateStats dictionaries exposed to web pages do not 4. Statistics related to ICE candidates MUST NOT contain the
contain any 'ip' member if related to a host ICE candidate. resolved IP address of a remote mDNS candidate or the IP address
of a peer-reflexive candidate, unless that IP address has already
been learned through other means, e.g., receiving it in a
separate server-reflexive remote candidate.
4.2. Generated names reuse 4.2. Interactions With TURN Servers
Dynamically generated names can be used to track users if used too When sending data to a TURN [RFC5766] server, the sending client
often. Conversely, registering too many names will also generate tells the server the destination IP and port for the data. This
useless processing. The proposed rule is to create and register a means that if the client uses TURN to send to an IP that was obtained
new generated name for a given IP address on a per execution context. 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.
4.3. Specific execution contexts 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. Note 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.
Privacy might also be breached if two execution contexts can identify This restriction has no effect on connectivity; in the cases where
whether they are run in the same device based on a successful peer- host IP addresses are private and need to be wrapped with mDNS names,
to-peer connection. The proposed rule is to not register any name they will be unreachable from the TURN server, and as noted above,
using Multicast DNS for any ICE agent belonging to: the reverse path will continue to work normally.
1. A third-party browser execution context, i.e. a context that is 4.3. Generated Names Reuse
not same origin as the top level execution context.
2. A private browsing execution context. 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. The use of registered mDNS hostnames SHOULD be
scoped by origin, and SHOULD have the lifetime of the page.
5. Specification Requirements 4.4. Specific Browsing Contexts
The proposal relies on identifying and resolving any Multicast DNS As noted in [IPHandling], privacy may be breached if a web
based ICE candidates as part of adding/processing a remote candidate. application running in two browsing contexts can determine whether it
[ICESDP] section 4.1 could be updated to explicitly allow Multicast is running on the same device. While the approach in this document
DNS names in the connection-address field. 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.
The proposal relies on adding the ability to register Multicast DNS To avoid this issue, browsers SHOULD NOT register mDNS names for
names at ICE gathering time. This could be described in [ICESDP] WebRTC applications running in a third-party browsing context (i.e.,
and/or [WebRTCSpec]. a context that has a different origin than the top-level browsing
context), or a private browsing context.
5. Security Considerations
5.1. mDNS Message Flooding
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,
o the registration of name requires optional probing queries and
mandatory announcing responses ([RFC6762], Section 8), and this is
performed at the beginning of ICE gathering;
o the addition of remote ICE host candidates with mDNS names
generates mDNS queries for names of each candidate;
o 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 ([RFC6762], Section 10.1).
A malicious Web application could flood the local network with mDNS
messages by:
o creating browsing contexts that create ICE agents and start
gathering of local ICE host candidates;
o destroying these local candidates soon after the name registration
is done;
o adding fictitious remote ICE host candidates with mDNS names.
[RFC6762] defines a per-record multicast rate limiting rule, in which
a given 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
records, are constantly created and sent. A browser-wide mDNS
message rate limit MUST be provided for all messages that can be
indirectly dispatched by a web application, namely the probing
queries, announcement responses, resolution queries, and goodbye
responses associated with mDNS.
5.2. Malicious Responses to Deny Name Registration
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 Section 2.1.
The above attack can be mitigated by skipping the probing when
registering a name, which also conforms to Section 8 in [RFC6762],
given that the name is randomly generated for the probabilistic
uniqueness (e.g. a version 4 UUID) in Step 3 in Section 2.1.
However, a similar attack can be performed by exploiting the negative
responses (defined in [RFC6762], 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.
5.3. Monitoring of Sessions
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.
As above, mitigation of this threat is beyond the scope of this
proposal.
6. Specification Requirements
The proposal relies on identifying and resolving any mDNS-based ICE
candidates as part of adding/processing a remote candidate. [ICESDP]
section 4.1 could be updated to explicitly allow mDNS names in the
connection-address field.
The proposal relies on adding the ability to register mDNS names at
ICE gathering time. This could be described in [ICESDP] and/or
[WebRTCSpec].
The proposal allows updating [IPHandling] so that mode 2 is not the The proposal allows updating [IPHandling] so that mode 2 is not the
mode used by default when user consent is not required. Instead, the mode used by default when user consent is not required. Instead, the
default mode could be defined as mode 3 with Multicast DNS based ICE default mode could be defined as mode 3 with mDNS-based ICE
candidates. candidates.
6. Informative References 7. Informative References
[HTMLSpec]
"HTML Living Standard", n.d.,
<https://html.spec.whatwg.org>.
[ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/ [ICESDP] Keranen, A., "Session Description Protocol (SDP) Offer/
Answer procedures for Interactive Connectivity Answer procedures for Interactive Connectivity
Establishment (ICE)", April 2018, Establishment (ICE)", April 2018,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-mmusic-ice-sip-sdp>. draft-ietf-mmusic-ice-sip-sdp>.
[IPHandling] [IPHandling]
Shieh, G., "WebRTC IP Address Handling Requirements", Shieh, G., "WebRTC IP Address Handling Requirements",
April 2018, <https://tools.ietf.org/html/ April 2018, <https://tools.ietf.org/html/
draft-ietf-rtcweb-ip-handling>. draft-ietf-rtcweb-ip-handling>.
[IPLeak] "IP/DNS Detect", n.d., <https://ipleak.net>. [IPLeak] "IP/DNS Detect", n.d., <https://ipleak.net>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
(ICE): A Protocol for Network Address Translator (NAT) Relays around NAT (TURN): Relay Extensions to Session
Traversal for Offer/Answer Protocols", RFC 5245, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5245>. <https://www.rfc-editor.org/info/rfc5766>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[WebRTCSpec] [WebRTCSpec]
Bruaroey, J., "The WebRTC specification", n.d., Bruaroey, J., "The WebRTC specification", n.d.,
<https://w3c.github.io/webrtc-pc/>. <https://w3c.github.io/webrtc-pc/>.
Authors' Addresses Authors' Addresses
Youenn Fablet Youenn Fablet
Apple Inc. Apple Inc.
Email: youenn@apple.com Email: youenn@apple.com
Jeroen De Borst Jeroen de Borst
Google Google
Email: jeroendb@google.com Email: jeroendb@google.com
Justin Uberti Justin Uberti
Google Google
Email: juberti@google.com Email: juberti@google.com
Qingsi Wang Qingsi Wang
Google Google
 End of changes. 51 change blocks. 
144 lines changed or deleted 325 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/