The mdns-ice-candidates from rtcweb-wg

Consider breaking up Privacy Considerations section

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.

Add example with RFC1918 IPv4s and RFC 4941 IPv6

This would be a fully realistic example and show the STUN process as well.

Examples don't fit into the RFC char limit

Note in https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-01#section-3 that the examples extend beyond the right margin.

Pick a single term for the mDNS behavior

Does it obfuscate, conceal, or obscure local IP addresses?

My vote is for conceal.

Missing required section - IANA considerations

IANA Considerations

A. Must specify if IANA has to create a new registry or modify rules for an existing registry.

B. Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication.

C. See "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) and in some cases also "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780] (Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers,” March 2000.) [RFC5237] (Arkko, J. and S. Bradner, “IANA Allocation Guidelines for the Protocol Field,” February 2008.). In some case "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] (Narten, T., “Assigning Experimental and Testing Numbers Considered Useful,” January 2004.) may help as well.

D. If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA."

Should we move examples 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.

Should we mention DNS SD work to extend MDNS resolution outside the local link

https://tools.ietf.org/html/draft-ietf-dnssd-mdns-relay and related https://tools.ietf.org/html/draft-ietf-dnssd-hybrid define a way to query mDNS outside the local link.
We might want to refer to these techniques in the draft as a way to improve ICE connectivity.

Autogenerate latest HTML and remove .html file from repo

Similar to the CI Bot for JSEP: rtcweb-wg/jsep@5be5220

Capitalization of subsections in {#guideline} is inconsistent with the rest

Do we want to edit the proposal in an implementation-neutral approach?

The second approach implemented in the WebKit engine enforces the following policy

Not sure if it would be ideal to motivate the work in an implementation-neutral way, though I cannot think of a better approach at this moment. That said, should we also mention the current practice in Blink? I think the behavior is different but the same dilemma arises.

Private browsing mode contexts usually do not share any information with regular browsing contexts.

Is context a WebKit terminology? Do we want to also relate the definition of contexts to origins?

Multiple IP addresses in an mDNS response

It is conceivable that a server would implement ICE with mDNS candidates.

There should be nothing in the ICE candidate processing that prevents this from working. Therefore we should call out what should happen when an mDNS query returns multiple IP addresses. E.g. use the 'best' on (where IPv6 is better than IPv4)?

Unused ref for IPLeak

== Unused Reference: 'IPLeak' is defined on line 436, but no explicit
reference was found in the text

Move privacy concerns text from this document to ip-handling

As discussed at IETF 101, ip-handling should define the problems, and this document should present the mDNS solution.

Repeated sections on the interaction with TURN

I will upload a PR for this.

Separate references into normative and informative

Right now they are all informative.

See https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ for the difference.

Consistent term for local ICE candidates

Host ICE candidates, ICE host candidates, or something else?

Reference needed to RFC2119

The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords.

Don't pair mDNS candidates with relay candidates

If we resolve a name N1 to 1.1.1.1, should we pair it with relay candidates? If we do so, 1.1.1.1 will be sent to the TURN server, which seems like a leak (could be under the control of the web app).

Probably need to add a section in the privacy considerations saying any remote mdns candidates MUST NOT be paired with local relay candidates (although the reverse should be OK).

HTML generator adds "Section" to markdown section links

E.g. "Step 5 in Section {{gathering}}" in .md becomes "Step 5 in Section Section 2.1" in .html or "Step 5 in Section Section 2.1" in the raw html source.

STUN servers can be run inside the enterprise

During the rtcweb working group meeting, it was mentioned that a lot of enterprises run STUN servers inside their network.

A degenerate use case? Probably to enable mode 3 browsers / Safari to make calls within the enterprise, without hairpin NAT or TURN servers?

This would expose local addresses as candidates, by passing mDNS obfuscation.

Study the impact of exposing well-known mDNS services to STUN

As pointed by @alvestrand, one can stuff ICE candidates with mDNS names that are not UUID.
This may ease exposing some devices (MyPreferredTV.local) to some unsolicited mDNS/STUN traffic.

Require a global rate limit on mdns queries

Querying for mdns names could be used to flood the network with broadcast messages. We need to rate limit those globally. Maybe add a lower limit by origin so that we don't have origins deny service to other origins.

Purpose of document: extend ip-handling, or focus on defining the mDNS technique?

IOW, should this document define the new modes, or just how mDNS should be used to hide local IP addresses? If the latter, we would then also need to write a ip-handling v2 that defined the new modes, and pointed at this doc for details on how the technique should work.

Consider use of RFC7217 addresses instead of RFC4941

https://tools.ietf.org/html/rfc7217#section-1 sayeth:

   since temporary addresses [RFC4941] do not eliminate the use of
   fixed identifiers for server-like functions, they only partially
   mitigate host-tracking and activity correlation across networks
   (see [ADDR-GEN-PRIVACY] for some example attacks that are still
   possible with temporary addresses).

Pages should not be allowed to trigger massive amounts of MDNS traffic

This was pointed by Cullen in https://mailarchive.ietf.org/arch/msg/rtcweb/zGbK1yPaLY5ZBij6tzYykkDC_js

The spec should probably mention the risk and the possibility to throttle MDNS resolution queries.

Reduced Connectivity: Mention throughput

When mDNS fails, ICE will attempt to fall back to either NAT hairpin, if supported, or TURN relay, if not. As noted in {{IPHandling}}, this may result in increased media latency and reduced connectivity/increased cost (depending on whether the application chooses to use TURN).

Let's also consider data use cases here: Fallback to TURN has a severe effect on throughput in many cases.

Define c= attribute in the case of only mDNS candidates

Currently it contains:

c=IN IP4 address/ttl

Obviously, putting one of the candidate's IP address there would defeat the purpose of use mDNS.

Options:

Can this be omitted?
Should it have a fake IP address of the right address family?
Should it be allowed to have an mDNS name?

Authors in monospace or list

We probably have the similar incompatible issue between monospace and list in the author section.

Mention that IPv4 and IPv6 MAY be handled differently

Due to their different sensitivity and lifetime.

Rename execution context to browsing context

(browser) execution context -> browsing context

Using non-RFC6890 compliant IPv4 addresses in examples

There is a range of IP addresses set aside for documentation/example purposes

A. For IPv4 these are 192.0.2.0/24 (see [RFC3330] (IANA, “Special-Use IPv4 Addresses,” September 2002.)).
B. For IPv6 these are 2001:DB8::/32 (see [RFC3849] (Huston, G., Lord, A., and P. Smith, “IPv6 Address Prefix Reserved for Documentation,” July 2004.)).

.local name generation/registration

Register the unique name using Multicast DNS.

We found Microsoft recommended using “.local.” as a pseudo-TLD for small private networks with internal DNS servers (here is an article that is still accessible, https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-essentials-sbs/cc708159(v=ws.10), and the Wiki page https://en.wikipedia.org/wiki/.local covers some legacy recommendations made by Microsoft, though some I think have been removed). We also note that Apple provided guidance on how to configure OS X to look up “.local” hostnames using both mDNS and DNS (https://support.apple.com/en-us/HT201275, I am not sure if this is still the case for newer OS X). Hostnames containing only one level (label) in addition to “.local” are resolved using mDNS by default. Names containing two or more labels in addition to local will be resolved using DNS by default.

For this reason, our current implementation only generates names containing one additional label (also recommended by RFC 6762 I think).

If registering of the unique name fails, abort these steps. The candidate is not exposed.

I understand this section is more about the principle, but I am wondering how we/or if we should define failure here. Since we use the random UUID for hostnames, name conflicts are likely avoided with minimum retries.

Should "Monitoring of Sessions" be moved to Privacy section

It does not seem like a security concern but more like a privacy concern.

Consistently use mDNS instead of MDNS or Multicast DNS

Or alternatively consistently use mDNS, but mention in the intro that this refers to Multicast DNS {{RFC6762}}

De-duplication with prflx candidates and IP leak

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.

We found there is an issue with prflx candidates, and we may need to clarify the de-duplication logic in the proposal. Suppose the local ICE agent is in the resolution process of an mDNS remote candidate, the remote ICE agent starts to ping the local agent with connectivity checks from the remote candidate we are resolving, we may need to define a reliable way to identify that the prflx candidate is the same one as the mDNS candidate and not create a duplicate candidate.

Also, the identical and duplicate prflx candidate can be a source of IP leak (via stats).

Fix examples for HTML I-D

Not sure what needs to be done here, but would be nice to fix

Is the number of mDNS candidates a fingerprinting surface?

Original text:

The number of mDNS hostname candidates can provide a fingerprinting dimension. If so desired an ICE agent MAY expose additional mDNS hostname candidates that are not registered.

I'm not sure this provides an actual new fingerprinting surface - assuming the interface is in fact exposed to the outside world, a srflx candidate will also be generated for each mDNS candidate - and in the mode we are most concerned about, Mode 2, there will either be 1 or 2 mDNS candidates.

Include an actual candidate with {uuid}.local mDNS name in examples somehow

Make it super clear what's expected to be sent on the wire.

Indicate intended audience for this document

The changes to ICE candidate gathering are targeted to web browsers; the changes to ICE candidate processing affect all WebRTC endpoints.

Consider exposing MDNS ICE candidate with a specific service type

Currently, the spec uses MDNS to expose a name/IP address relationship.
It was suggested that alternatively, this could be exposed as a service of a given type (_webrtc._udp for instance).

The advantage I can think of is that we fix #37 more cleanly: any already existing MDNS service would not be reachable by mDNS ICE candidate except if opting in by registering this particular given type.

Scope to communication peer

For WebRTC, this should be scoped to the RTCPeerConnection instance.

Spec requirement for new modes

Specification Requirements

We may need to add a request for the definition of new modes in a different spec.

Abstract contains a reference

From the 'nits' link on top of the IETF submitted version.

** The abstract seems to contain references ([RFC6762]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.

Mention potential downsides of this approach on connectivity

Include experimental results, if we have them

Define the contingencies when mDNS protection should be enabled/disabled

In the draft, we currently have no clear definition on this aspect. One thought we have is to couple the IP revealing permission with the getUserMedia permission. This is in alignment with the existing practice of the network enumeration permission in browsers. A separate permission from the user for the IP revealing is the alternative that reduces the implications from a single permission.

rtcweb-wg / mdns-ice-candidates Goto Github PK

mdns-ice-candidates's Introduction

mdns-ice-candidates's People

Contributors

Stargazers

Watchers

Forkers

mdns-ice-candidates's Issues

Recommend Projects

Recommend Topics

Recommend Org