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

[Lennart Grahl <[e-mail]>]

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.

>    - 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.

> 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).

Cheers
Lennart