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

[Justin Uberti <[e-mail]>]

I believe such data will be forthcoming from the Safari team. We are also
working on this.

On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <[e-mail]> wrote:

> It seems like this is something one could A/B test and measure connection
> rates. Has someone done so?
>
> -Ekr
>
>
>
> On Fri, Jun 15, 2018 at 10:48 AM, Matthew Kaufman <[e-mail]>
> wrote:
>
>> Opposed because we shouldn't waste any more time on IPv4, and IPv6 has no
>> analog that we can implement for IPv6 and then implement for IPv4 largely
>> for free.
>>
>> Matthew Kaufman
>>
>>
>> On Thu, Jun 14, 2018 at 2:32 PM Justin Uberti <juberti=
>> [e-mail] <[e-mail]..org>> wrote:
>>
>>> On Thu, Jun 14, 2018 at 2:15 PM Harald Alvestrand <[e-mail]>
>>> wrote:
>>>
>>>> I have some worries about this proposal. It seems neat, and solves a
>>>> specific problem for a specific use case, but it's not a written-up
>>>> proposal, rather a sketch for one - and I'm afraid of devils in the
>>>> details.
>>>>
>>>> For instance:
>>>>
>>>> - If this technique is used for a computer directly connected to the
>>>> Internet, with a public IP address, it won't communicate - unless it is
>>>> only used on private addresses - because "uuid.local" doesn't resolve,
>>>> whereas a public IP address is globally reachable.
>>>
>>>
>>>> - The above means that the proposal needs a definition of "private
>>>> address". Do we mean "private" in the RFC 1918 sense? If so, which IPv6
>>>> range is covered by the proposal?
>>>>
>>>> - It will only work if the private address usage is the same scope as
>>>> mDNS resolution. On an unmanaged LAN it works, and on a network with
>>>> explicit mDNS forwarding it works. But on any other deployment, it
>>>> forces traffic to go via public IP addresses learned by STUN.
>>>>
>>>> I think this is worth adding. Perhaps as a new "mode 2m"?
>>>>
>>>> But I'd like a commitment to not adding it until we have a full
>>>> proposal.
>>>>
>>>
>>> I have sketched out the proposal in
>>> https://github.com/juberti/draughts/pull/103, which while not complete,
>>> does address most of your questions.
>>>
>>>>
>>>> Den 12. juni 2018 02:40, skrev Justin Uberti:
>>>> > 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.
>>>> >   * 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.
>>>> >
>>>> > 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?
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > rtcweb mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>>> >
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>