Re: [rtcweb] Fwd: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames

[Justin Uberti <[e-mail]>]

On Wed, Aug 14, 2019 at 10:32 AM Roman Shpount <[e-mail]> wrote:

> Hi Justin,
>
> In the statistics that you are providing, does this mean 2% of total
> connections attempts are affected or 2% of web sites which do data channel
> connections are affected? If this is the former, then a few applications
> that are responsible for large number of data channel connections that were
> updated to support mDNS will drown out things which are affected.
>

2% of total connection attempts. We separately considered Chrome->Chrome
and Chrome->non-Chrome so we have some understanding of the impact on
non-updated applications, and it seems to be modest.

>
> Also, have you tested this on mobile platforms or is this just on desktop?
> I am really curios how well this will work on large dual stack mobile
> network..
>

At present we are only rolling this on desktop. Are you aware of a specific
problem regarding mobile networks?

>
> Have you looked separately on the connection failure rate when STUN
> servers are not used? Such applications would be affected by this change at
> a much higher degree. The PSA mentions STUN vs no-STUN but it is hard to
> decipher the actual failure rate in each of the cases.
>

Yes, but these cases are ~0.01% of the total. The impact is greater here,
as expected; we are checking the exact numbers and can report more detail
once we have vetted the data.


> Have you collected any statistics on receive only media connections, such
> as web conferencing applications that allow the user to continue in listen
> only mode when user does not have or denies microphone access? In our case,
> this was the scenario which was most affected and deployments of fixes to
> work around this are still in progress with our customers.
>

These applications, being c2s, should be compatible with the mDNS
technique, but we are aware that some upgrades to ICE stacks are necessary.
If you are aware of large migrations that have not yet completed this would
be useful for us to know so we can factor that in to our plans.

>
> Has the interop with Firefox ESR ever been addressed? What is the proposed
> solution here?
>

Yes. Chrome 76 will use 0.0.0.0 in the c= line, and we will be able to
measure the impact of this change as 76 rolls out.

>
> On the specification note, I would still consider
> rtcweb-mdns-ice-candidates to be fairly raw and not ready for production
> implementations. I would hope it would at least be ready for WGLC before
> something that implements it goes into production. At this point, there is
> high probability that the final version of this draft will require
> something somewhat different from what is currently implemented in Chrome
> now.
>

Waiting has its own costs, so in the absence of specific issues I don't
think it makes sense to delay. If you are aware of significant problems
with this technique, please raise them here or at
https://github.com/rtcweb-wg/mdns-ice-candidates/issues.

>
> Best Regards,
> _____________
> Roman Shpount
>
>
> On Tue, Aug 13, 2019 at 6:54 PM Justin Uberti <juberti=
> [e-mail]> wrote:
>
>> FYI, empirical results of deploying mDNS at scale. TL;DR: downside is
>> low, ~2% impact to data channel connection rate between Chrome instances,
>> somewhat higher when connecting to non-Chrome, likely due to issues
>> handling mDNS candidates, which should be temporary.
>>
>> In the absence of any showstopper feedback, planning to roll this out
>> fully later this month.
>>
>> ---------- Forwarded message ---------
>> From: 'Qingsi Wang' via discuss-webrtc <[e-mail]>
>> Date: Tue, Aug 13, 2019 at 2:33 PM
>> Subject: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC
>> changing to mDNS hostnames
>> To: discuss-webrtc <[e-mail]>
>>
>>
>> Summary
>>
>> WebRTC currently lets web applications discover private IP addresses to
>> enable direct connectivity between hosts on a local network. While private
>> IP addresses do not uniquely identify browser users, they may still be used
>> for tracking purposes. To prevent this misuse, private IP addresses
>> returned by RTCPeerConnection will now be masked with mDNS hostnames in
>> certain situations. While this change should be transparent to most WebRTC
>> applications, some developers may need to update their client and backend
>> services.
>>
>> This change is currently enabled for 50% of Chrome users, and is expected
>> to fully roll out in August 2019 as part of the Chrome 76 release. WebRTC
>> services can verify whether their services are affected by setting the
>> following flag in Chrome 73 or later:
>> chrome://flags/#enable-webrtc-hide-local-ips-with-mdns
>>
>> Why are we doing this?
>>
>> We have observed a trend of web sites using WebRTC specifically to obtain
>> private IP addresses, presumably for tracking purposes. Accordingly, we
>> have collaborated with other browser vendors to address this problem by
>> using mDNS hostnames instead of private IP addresses in WebRTC, as
>> described in this pending IETF spec
>> <https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-03>.
>> We have also experimentally verified the efficacy of the mDNS technique,
>> following the initial announcement of this feature in January
>> <https://groups.google.com/forum/#!msg/discuss-webrtc/4Yggl6ZzqZk/nV24XkXXAQAJ>
>> .
>>
>> Impact on applications
>>
>> When the feature is active, private IP addresses in ICE host candidates
>> will be replaced by an mDNS hostname, e.g.,
>> 1f4712db-ea17-4bcf-a596-105139dfd8bf.local. Currently, this feature is
>> active for all sites except those that have getUserMedia permissions, which
>> are presumed to have a higher degree of user trust.
>>
>> WebRTC services that do not support addresses in the above format may be
>> impacted, causing sessions to fail or use a less direct connection path. WebRTC
>> services may be especially affected if they parse out addresses from
>> RTCSessionDescription or RTCIceCandidate objects and assume those addresses
>> are IP addresses, or have server components that do the same. In
>> particular, older versions of the libnice library, used by some
>> applications, do not parse such addresses properly..
>>
>> Impact on connectivity
>>
>> mDNS does not work in all situations; on some networks, mDNS may be
>> disabled, or an endpoint may be too many hops away to resolve an mDNS
>> hostname. In these cases, fallback to STUN will be required, and this may
>> sometimes fail; as such, some amount of impact on connection success rate
>> is to be expected.
>>
>>
>>
>> From a broad analysis of peer-to-peer connections in the experimental
>> deployment, the overall impact of mDNS on connectivity is modest, a 2%
>> (relative) reduction in connection rate when mDNS was used by Chrome on
>> both sides. In this population, the percentage of successful connections
>> that used STUN on one side or the other increased from 94% to 97%, with a
>> corresponding decrease in host-to-host connections. We believe the
>> connectivity impact stems primarily from connections that previously worked
>> host-to-host, but do not work with mDNS, and cannot fall back to STUN due
>> to lack of hairpin support in the NAT.
>>
>>
>>
>> Somewhat surprisingly, for connections between Chrome and non-mDNS
>> endpoints, we observed a larger impact, roughly 3% (relative) reduction in
>> connection rate when the remote side supplied private IPs and 7% (relative)
>> when the remote side supplied only public IPs. While mDNS should have zero
>> impact in these cases, we believe this is explained by problems triggered
>> by mDNS in third-party ICE stacks, including the aforementioned issues
>> regarding parsing mDNS candidates as well as issues discovering
>> peer-reflexive candidates from ICE connectivity checks.
>>
>>
>>
>> Given the success of the mDNS technique in combating tracking via private
>> IP addresses, we believe this small impact on connection rate is an
>> acceptable tradeoff. We will continue to investigate improvements to this
>> technique to further minimize the downsides.
>>
>> General recommendations
>>
>> Improvements in Chrome are frequently rolled out as experiments and
>> deploy first in Chrome Canary and the pre-stable Dev and Beta versions.
>> Important experiments are also announced via email at the start of the
>> rollout. We highly recommend WebRTC developers to:
>>
>>    -
>>
>>    Join blink-dev
>>    <https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev>
>>    and discuss-webrtc
>>    <https://groups.google.com/forum/#!forum/discuss-webrtc> to follow
>>    PSAs and other important announcements
>>    -
>>
>>    Systematically test in Chrome Canary
>>    <https://www.google.com/chrome/canary/> to see how your application
>>    behaves with upcoming Chrome changes
>>    -
>>
>>    Provide feedback on the relevant bugs/forum threads
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "discuss-webrtc" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [e-mail].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797%40googlegroups.com
>> <https://groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>