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

Commentary: I think this is good to go , will plan to land at EOD . 
 Does it obfuscate , conceal , or obscure local IP addresses ? My vote is for conceal . 
 Conceal / concealment sgtm . 
 As noted in , we do n't need to use the same term in every case , but the terms should have the same meaning . conceal and hide are fairly synonymous , but conceal and obfuscate have slightly different meanings . 
 This section is largely normative , so it might make more sense to put some parts from it immediately after Principle , namely the various adjustments to the technique that need to be considered ( TURN , IPv6 , stats ) Things where we merely provide discussion ( e.g. , session monitoring ) rather than normative guidance could remain in the privacy section . 
 Due to their different sensitivity and lifetime . 
 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 
 The rest LGTM
Paragraph (version B):
This section outlines how mDNS should be used by ICE agents to
conceal local IP addresses.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
An ICE agent can implement this procedure in any way so long as it
produces equivalent results to this procedure.
Paragraph (version A):
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.
Paragraph (version A):
An implementation may also detect that mDNS is not supported by the
available network interfaces.  The ICE agent may skip steps 2 and 3
and directly decide to not expose the host candidate.
Paragraph (version B):
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
procedure will be executed at the time of gathering candidates.
Paragraph (version B):
ICE agents may also decide that certain local IP addresses are safe
to expose.  This may be because the ICE agent has a priori knowledge
that the address is in fact public, or because the agent has made a
policy decision to not conceal certain types of IP addresses (e.g.,
those with built-in privacy protections) as a calculated choice to
improve connectivity.  This topic is discussed further in {#privacy}
below.
Paragraph (version B):
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.
Paragraph (version A):
The exact impact of this technique is being researched experimentally
and will be provided before publication of this document.
Paragraph (version B):
One potential mitigation, as discussed in {#privacy}, is to not
conceal candidates created from RFC4941 IPv6 addresses.  This permits
connectivity even in large internal networks or where mDNS is
disabled.
Paragraph (version B):
The exact impact of the mDNS technique is being researched
experimentally and will be provided before publication of this
document.
Paragraph (version B):
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.
Paragraph (version B):
Instead, the determination of whether an address is public can be
reliably made as part of the ICE gathering process, namely, if the
query to the STUN RFC5389 server returns the same value as the local
address.  This can be done for both IPv4 and IPv6 local addresses,
provided that the application has configured both IPv4 and IPv6 STUN
servers.  If this situation occurs, i.e., STUN returns the same IP
address value for an address that has already been communicated as an
mDNS candidate during the current ICE gathering phase, the ICE agent
MUST NOT eliminate the candidate as redundant and MUST send the IP
address as a server-reflexive candidate.  This allows the ICE agent
to send mDNS candidates immediately (i.e., without waiting for STUN),
even if the associated addresses may not be private.
Paragraph (version B):
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.
Paragraph (version B):
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.