Re: [rtcweb] IP handling: Using mDNS names for host candidates

[Justin Uberti <[e-mail]>]

On Tue, Jun 12, 2018 at 4:15 AM Lennart Grahl <[e-mail]>
wrote:

> On 12.06.2018 02:40, Justin Uberti wrote:
> > The Safari team has come up with a clever approach to avoid disclosing
> > private IP addresses for host candidates. As discussed in this WebKit bug
> > <https://bugs.webkit.org/show_bug.cgi?id=174500>, the technique works as
> > follows:
> >
> >    1. Register a random UUID-based mDNS name when ICE gathering starts
> >    2. Replace the private IP address by a "{UUID}.local" string in each
> >    host candidate (and set raddr to 0.0.0.0 for other candidates)
> >    3. The other party will do mDNS resolution on any candidate having a
> >    .local suffix, similar to how hostnames in candidates are handled in
> RFC
> >    5245, Section 15.1.
> >
> > This technique is relevant to the IP handling document, as it addresses
> one
> > of the lesser problems (private IP disclosure) from the overall problem
> > statement. While I don't think this will have a large impact on the
> > document, including the default mode selection, incorporating this
> > technique would result in some moderate changes:
> >
> >    - Section 5.1 would mention concealing private IPs in the default case
> >    as an explicit goal.
> >    - In Section 6, Mode 2 would change from handling out private IPs to
> >    handing out mDNS names.
>
> IMHO that would create a large gap between mode 1 and 2. Instead, I
> would suggest using mDNS *in addition* to mode 2 and 3. For mode 2 this
> would mean that only the default private IP is being transmitted but all
> other interfaces are hidden by UUID-based hostnames. For mode 3, all
> private IPs are hidden by UUID-based hostnames.
>

I don't see a clear benefit of doing that. If you have the mDNS hostnames,
you don't need the private IPs.

Or, looking at it a different way, if mode 3 is as you describe, why would
we ever use mode 2?

>
> >    - This document would have to describe the technique or point to
> another
> >    document that describes the technique. mmusic-ice-sip-sdp, Section 4.1
> >    <
> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1>
> > seems
> >    like a good option, as it already covers how to handle DNS names in
> ICE
> >    candidates.
>
> Since this will be useful for ORTC as well, I would not tie that to an
> SDP-specific document.
>

ORTC already depends on this document (it explains ICE restarts, amongst
other things), so I don't see this as an issue. The nice thing about this
document is that it's nearing last call, but we still have time to make
edits like the ones suggested.

>
> > This is a significant improvement and I think we will want to incorporate
> > this suggestion. Is this something we could do as part of this WGLC, or
> > should we look for another option?
> I haven't seen a better solution than mDNS so far to prevent IPs from
> leaking and I would appreciate having this to fix the following issues:
>
> - Allowing browsers to use stricter modes by default without significant
> drawbacks,
> - establishing direct connections even in case no "consent" has been
> given because the devices are in fact in the same network segment (with
> the exception of mode 4), and
> - use cases where gUM cannot be applied and no other way of expressing
> consent has been provided (which is the status quo).
>

Noted. Thanks.