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

[Matthew Kaufman <[e-mail]>]

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