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

Commentary: , 
 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 . 
 Currently it is between limitations and privacy . I would tend to put it either just after section 3 as a way to describe it or inside section 6.1 since currently the examples mostly show section 6.1 issue . Another approach would be to inline them where most appropriate . 
 Yeah , I feel it reads better if placed after the Privacy section where the prflx candidate issue is detailed , or at least that part needs to refer to the example . We may also add examples for scenarios of attacks later . If we do so , we could either 1 ) place them in the same section as the last one before IANA consideration , referred by corresponding sections or 2 ) if it grows too big , inline the examples where they immediately demonstrate the case . 
 It does not seem like a security concern but more like a privacy concern . 
 Agreed , although the privacy considerations section is starting to get kind of large , and perhaps should be decomposed into multiple top - level sections . 
 LGTM . Only a few small edits . LGTM . I am not sure we consistently use " application " vs. " web application " . There is also a pre - existing broken link that should get fixed .
Paragraph (version A):
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):
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
RFC5389 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.
Paragraph (version B):
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.
Paragraph (version A):
Note that any server-reflexive candidates generated from an mDNS host
candidate will have IP addresses as their transport addresses, rather
than mDNS hostnames.  Because their transport addresses are different
(i.e., not hostnames), they MUST NOT be considered redundant with
their host counterparts, per the guidance in RFC8445, Section 5.1.3.
To avoid accidental leakage, these candidates MUST have their raddr
field set to 0.0.0.0 and their rport field set to 0.
Paragraph (version A):
Any candidates exposed to the web application via local descriptions
MUST be identical to those provided during candidate gathering (i.e.,
MUST NOT contain private host IP addresses).
Paragraph (version B):
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).
Paragraph (version B):
Mitigation of this threat is beyond the scope of this proposal.
Paragraph (version A):
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):
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 A):
As noted in principle, 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.
Paragraph (version B):
As noted in description, 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.
Paragraph (version A):
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 A):
As above, mitigation of this threat is beyond the scope of this
proposal.