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

Commentary: Nils reviewed the document at There are a number of clarification points that could be made from the draft Makes sense to me . Right , I would tend to go with private IP addresses given RFC1918 . We could refer to section 3.1.2.2 and refer to IP handling modes as well . We might want to further clarify that generating mDNS candidates ahead of time is an optimization . Makes sense to me .
Mailing list commentary: Hello , I was asked to review Here are my comment and questions : Abstract : “ To maximize the probability of a direct peer - to - peer connection , client private IP addresses are included in this candidate collection . ” I think it would make sense to replace “ client ” with ICE agent here , as client and server in the pure ICE context does n’t make too much sense . I would suggest to change it to “ ... , private IP addresses of the ICE agent are included … ” . In the abstract the terms “ private IP addresses ” and “ local IP addresses ” are used . I would suggest sticking to just one term for consistency . Section 1 . “ Introduction ” has the same mix of local vs private in it . Section 3.1.1 point 1 I think it would be helpful if this draft at least offers the suggestion to replace all RFC1918 addresses , or put a reference to section 3.1.2.2 as a recommendation on how to determine which addresses to replace . Section 3.1.2.2 3rd paragraph “ Regardless of results , … ” confuses me . The last sentence in the paragraph before talks about the case of a public candidate . If I ’ m not mistaken in the case of a public address there should n’t be a server reflexive candidate generated . Section 3.1.2.2 4th paragraph While I agree that caching the result might be useful it can become dangerous in case the set of STUN servers changes . As the new STUN servers might return different results , cached results should be invalidated . Would it be worth adding a warning about this ? Section 6.4 I ’ m confused by the diagram showing that both agents send over their mDNS candidates before having checked with the STUN server if the interface IP addresses need to be filtered or not . I understand that section 3.1.2.2 recommends to first wait for the STUN binding response from the STUN server before deciding which addresses should be filtered and which not . Why is this example showing it differently ? Best regards
Paragraph (version A):
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 B):
Check whether this IP address satisfies the ICE agent's policy
regarding whether an address is safe to expose (typically,
following the advice from address-privacy below).  If so, expose
the candidate and abort this process.
Paragraph (version A):
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 A):
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 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 ICESDP, Section 9.1.
Paragraph (version A):
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):
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, although processing will continue as
described below.
Paragraph (version B):
Regardless of whether the address turns out to be public or private,
a server-reflexive candidate will be generated; the transport address
of this candidate will be 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 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
ICESDP, Section 9.1.
Paragraph (version B):
Because a new candidate is always generated by the STUN query, the
ICE agent SHOULD initially provide mDNS-wrapped candidates to the
application and then follow with server-reflexive candidates once
they are obtained, unless it has a priori knowledge that a given
address is public and does not require mDNS wrapping.
Paragraph (version B):
To that end, once an address has been identified as public, the ICE
agent MAY cache this information and skip mDNS protection for that
address in future ICE gathering phases.  Note that if the set of STUN
servers changes, any cached information SHOULD be discarded, as the
new set may return different results.