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

Commentary: Attacks by message flooding and name registration blocking are detailed . 
 This PR is doing some renaming . Maybe it should be done in a separate commit PR . Also , the mention of a mdns name per browsing context might conflict with another PR . 
 LGTM with change to make limit browser - wide . 
 LGTM
Paragraph (version A):
Check whether the context ICE agent registered a name resolving to
the ICE host candidate IP address.
Paragraph (version A):
If the ICE agent registered the name, replace the IP address of
the ICE host candidate with the name with ".local" appended to it.
Expose the candidate and abort these steps.
Paragraph (version A):
Generate a random unique name, typically a version 4 UUID as
defined in RFC4122.
Paragraph (version A):
Register the unique name using Multicast DNS.
Paragraph (version A):
If registering of the unique name fails, abort these steps.  The
candidate is not exposed.
Paragraph (version A):
Store the name and its related IP address in the ICE agent for
future reuse.
Paragraph (version A):
Replace the IP address of the ICE host candidate with the name
with ".local" appended to it.  Expose the candidate.
Paragraph (version A):
Otherwise, remove the ".local" suffix to the value and resolve it
using Multicast DNS.
Paragraph (version B):
Generate a unique mDNS hostname.  The unique name MUST consist of
a version 4 UUID as defined in RFC4122, followed by ".local".
Paragraph (version B):
Register the candidate's mDNS hostname as defined in RFC6762.
Paragraph (version B):
Store the mDNS hostname and its related IP address in the ICE
agent for future reuse.
Paragraph (version B):
This procedure ensures that a mDNS name is used to replace only one
IP address.  Specifically, an ICE agent using an interface with both
IPv4 and IPv6 addresses MUST expose a different mDNS name for each
address.
Paragraph (version B):
If the connection-address field value of the ICE candidate does
not end with ".local" or if the value contains more than one ".",
then process the candidate as defined in RFC8445.
Paragraph (version B):
Otherwise, resolve the candidate using mDNS.
Paragraph (version A):
Multicast DNS resolution might end up retrieving both an IPv4 and
IPv6 address.  In that case, the IPv6 address may be used preferably
to the IPv4 address.
Paragraph (version A):
RTCIceCandidateStats dictionaries exposed to web pages do not
contain any 'ip' member if related to a host ICE candidate.
Paragraph (version A):
Dynamically generated names can be used to track users if used too
often.  Conversely, registering too many names will also generate
useless processing.  The proposed rule is to create and register a
new generated name for a given IP address on a per execution context.
Paragraph (version A):
The proposal relies on identifying and resolving any Multicast DNS
based ICE candidates as part of adding/processing a remote candidate.
ICESDP section 4.1 could be updated to explicitly allow Multicast DNS
names in the connection-address field.
Paragraph (version A):
The proposal relies on adding the ability to register Multicast DNS
names at ICE gathering time.  This could be described in ICESDP and/
or WebRTCSpec.
Paragraph (version B):
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,
Paragraph (version B):
the removal of names could happen when the execution 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).
Paragraph (version B):
adding fictitious remote ICE host candidates with mDNS names.
Paragraph (version B):
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.
Paragraph (version B):
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 #gathering.
Paragraph (version B):
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 #gathering.
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.
Paragraph (version B):
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.
Paragraph (version B):
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.