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

[Lennart Grahl <[e-mail]>]

On 12.06.2018 17:39, Justin Uberti wrote:
> 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

Mode 2 with mDNS hostnames exclusively would only work when the devices
are in the same network segment. Anything that stops multicast would
require the use of a STUN server. That makes mode 2 a lot less powerful.

Whereas mode 2 as of today and with my suggestion does work without a
STUN server, even if you are not in the same network segment. Think of
IPv6 global addresses or corporate networks with several private
networks. And exposing an IP is still useful for establishing a
connection with an implementation that doesn't support mDNS (not even
resolving).

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

Fair enough.

Cheers
Lennart