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

In the case of Burningman/town-hall intranet meeting - the side _sending_ the media would presumably have GUM permissions,
so be advertising it's 'private' IPv4s - I guess we might get a direct connection set up via peer-reflexives discovered that way.

T.

> On 14 Jun 2018, at 18:14, Justin Uberti <juberti=40google.com@dmarc.ietf.org> wrote:
> 
> This is a valid concern, but keep in mind that this only applies to:
> - apps without gUM permission (or else they can use Mode 1)
> - on networks that don't support IPv6 (or else they can use the RFC 4941 v6 address)
> - on networks where mDNS is turned off or constrained
> 
> I tend to think this is still a pretty good tradeoff. 
> 
> One other option could be to add a new Mode 1.5 that did hand out the private IP which could be selected by domain admins, but given how subtle this area is, I tend to think that it would rarely, if ever, be enabled.
> 
> On Wed, Jun 13, 2018 at 1:28 PM Cullen Jennings <fluffy@iii.ca <mailto:fluffy@iii.ca>> wrote:
> 
> 
> With my individual hat on …
> 
> I have a bunch of concerns about this but the biggest is that mDNS does not work on a large percentage of medium and large corporate WiFI Networks. The problem is the large multicast domains trash the WiFi performance so many APs turn off mDNS or limit it’s range to much less than the scope of where just testing the address with ICE would be routable. It’s exactly theses environment where using the local IP vs a TURN IP provides lots of benefit.  I like the idea of trying to use mDNS but I’d want tot see strong evidence it worked in theses environments before putting it in at the last minute. 
> 
> 
> 
>> On Jun 11, 2018, at 6:40 PM, Justin Uberti <juberti=40google.com@dmarc.ietf.org <mailto:juberti=40google.com@dmarc.ietf.org>> 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:
>> Register a random UUID-based mDNS name when ICE gathering starts
>> 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)
>> 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
>> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb