Draft: draft-ietf-rtcweb-mdns-ice-candidates

Commentary: Also wrap long lines for # processing section . 
 Comments addressed , PTAL . 
 Will wait for approval before merging . 
 LGTM , updated PR for line wrapping . 
 The changes to ICE candidate gathering are targeted to web browsers ; the changes to ICE candidate processing affect all WebRTC endpoints . 
 If we add this indication , do we also need to clarify the use case for lite ICE agents ? 
 What did you have in mind ? 
 { { # gathering } } starts with " For any host candidate gathered by an ICE agent as part of { { RFC8445 } } section 5.1.1 , " it seems the place we need to revise to resolve this issue . I was thinking of allowing ICE lite implementation to skip the mDNS wrapping , since lite agents only use host candidates ( 8445 , section 2.5 ) . The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section , but rather an alternative to simplify the implementation when possible . So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping ; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates , and automatically the intended use of lite ICE satisfies this condition . 
 Right , the public IPs exception probably covers this . also indicates that this is really for web browsers , which are not allowed to implement ICE Lite . 
 Started writing this up today , but realized it 's not totally clear how this should work . The idea would be to use STUN to figure out if an IP is public or not , but ... we wait to hand out the mDNS candidate until we determine if the IP is private ( i.e. , STUN finishes ) ? we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private ? we hand out the mDNS candidate and then get a srflx candidate that matches the local IP , should we make that a host candidate ? we learn an IP is not public , should we cache that for future ICE gathering sessions ( i.e. , not give out mDNS candidates ? ) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual , but allow implementations to skip mDNS for IPs it has learned are public . ( Except for RFC1918 addresses , which would always be treated as private . ) 
 Partially addressed in , will probably include some additional clarifying text once it lands 
 LGTM
Paragraph (version A):
As detailed in IPHandling, exposing client private IP addresses by
default maximizes the probability of successfully creating direct
peer-to-peer connection between two 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 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.
Paragraph (version B):
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 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.
Paragraph (version A):
This document proposes an overall solution to this problem by
registering ephemeral mDNS RFC6762 names for each local private IP
address, 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.
Paragraph (version B):
This document proposes an overall solution to this problem by
providing a mechanism for WebRTC implementations to register
ephemeral mDNS RFC6762 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.
Paragraph (version B):
WebRTC and WebRTC-compatible endpoints Overview 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.
Paragraph (version B):
This section outlines how mDNS should be used by ICE agents to
conceal local IP addresses.  Naturally, if the ICE agent does not
want to conceal its IPs, e.g., if it has a priori knowledge that its
addresses are in fact public, this processing is unnecessary.
Paragraph (version B):
This section outlines how received ICE candidates with mDNS names are
processed by ICE agents, and is relevant to all endpoints.
Paragraph (version A):
An ICE agent that supports mDNS candidates MUST support the situation
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.
Paragraph (version B):
An ICE agent that supports mDNS candidates MUST support the situation
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 use the first
IPv6 address resolved, if one exists, or the first IPv4 address, if
not.