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

[Eric Rescorla <[e-mail]>]

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=40google.com@dmarc.
> ietf.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
>
>