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

[youenn fablet <[e-mail]>]

Hi all,

Would it make sense to reserve a time slot at next IETF 102 meeting to discuss this?
Apparently, the RTCWeb WG is not meeting there.
Maybe MMUSIC session would be a good place?

Thanks,
	Y

> Le 12 juin 2018 à 8:39 AM, Justin Uberti <[e-mail]> a écrit :
> 
> 
> 
> On Tue, Jun 12, 2018 at 4:15 AM Lennart Grahl <[e-mail] <mailto:[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 <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 <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.