PSA: WebRTC host candidate obfuscation experiment in M73

[Jeroen de Borst]

An experiment to use mDNS to obfuscate host candidate IP addresses has started in Chrome Canary (M73).

With this feature, host IPs will no longer directly be exposed by the RTCPeerConnection API, increasing privacy. Host candidates will only indirectly be exposed through a randomly generated mDNS hostname.

Purpose and mechanisms used are described in this spec:

https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02

The expected effects on connectivity between 2 WebRTC agents are:

1. Two WebRTC agents using this feature, running in the same private network, may no longer be able to communicate directly if they are not in the same mDNS broadcast domain.
   
2. A WebRTC agent using this feature will still be able to communicate with other agents on the same private network when the other agent does not have this feature (implemented or enabled). In this case, the other agent would classify the obfuscated host candidates as peer-reflexive candidates.
   
3. Connectivity using server-reflexive or relay candidates will be unaffected.
   

No application code is affected by this feature, so there are no actions for developers with regard to this experiment.

This experiment affects Chrome on Windows, MacOS and Linux.

Regards,

Jeroen

[Andy Lee]

Is this controlled by a flag?

[Jeroen de Borst]

Yes,

On the command line you can supply --enable-webrtc-hide-local-ips-with-mdns.

Under chrome://flags it's called 'Anonymiza local IPs exported by WebRTC'

Regards

On Wed, Jan 30, 2019 at 2:49 PM Andy Lee <leeandy...@gmail.com> wrote:

Is this controlled by a flag?

--

---
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 discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2e70bed1-bd45-47fa-8552-087c91d45c10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roman Shpount]

Hi,

Are you aware that RFC 8445 only allows IP4 or IP6 addresses as candidate-address in ICE candidates? This most likely will not work with any existing ICE implementation.

Regards,

______________

Roman Shpount

[Alan Ford]

I can confirm this is indeed not working with an implementation based on libnice, which expects all candidates as IP addresses.

[Harald Alvestrand]

Of course. The specification for the experiment (draft-ietf-rtcweb-mdns-ice-candidates-02.txt) refers heavily to RFC 8445.

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7d0083ad-bc3a-4ad6-ae06-2a90d78c11bd%40googlegroups.com.

[Jeroen de Borst]

How exactly does libnice 'now work'? An ICE agent should ignore mDNS candidates if it doesn't understand them. This would result in peer-reflexive candidates on that agent's side, but connectivity remains.

RFC8445 does not describe how candidates are signaled (it's predecessor RFC5245 did, and it explicitly allowed FQDN candidates).

The signalling for ICE is now coverend in https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24, which now indeed says a candidate attribute should contain the candidate IP address, but it also says an ICE agent should ignore candidates it doesn't understand.

It is very common for new proposals to 'enhance' or 'extend' existing RFCs, this is how they evolve. This particular spec intends to increase privacy. As it moves through the IETF it may become a standard. This experiment is intended to determine the viability of the proposal.

Reagards,

Jeroen

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVHuh%3DDcasgC35vLvzoahbiRHAyWa8-5ME4ocUm0mYkKAQ%40mail.gmail.com.

[Roman Shpount]

Hi Jeroen,

RFC8445 only supports candidates that include IP addresses. It does not talk about how these IP addresses are encoded. For instance section 2.1:

In order to execute ICE, an ICE agent identifies and gathers one or more address candidates.  A candidate has a transport address -- a combination of IP address and port for a particular transport protocol (with only UDP specified here).  There are different types of candidates; some are derived from physical or logical network interfaces, and others are discoverable via STUN and TURN. 

RFC5245 did support FQDN addresses in candidates but the guidance given there for FQDN which resolves to multiple IP, including FQDN which resolves to a single IPv4 and a single IPv6 address is broken. This is why FQDN language was removed from mmusic-ice-sip-sdp.

The  mmusic-ice-sip-sdp specifies how IP addresses in candidates are encoded and it specifies ICE implementations should ignore candidates with IP address families they do not support. FQDN are currently completely prohibited by this draft. This was likely an over-reaction to realization that RFC5245 FQDN language was broken and luck of desire to fix this. There was a compromise discussed during RTCWEB session to allow FQDN which resolve to a single address (single IPv4 or single ipv6, not both). Currently both  mmusic-ice-sip-sdp and rtcweb-mdns-ice-candidates need updates to work. Furthermore, handling of default candidate in case when FQDN candidate is used needs to be specified.

As it stands right now, most ICE libraries will fail to parse a session description with FQDN in the candidate address and will fail to negotiate.

More importantly, current experiment does not work with anything except Chrome due to c= line population error. It would break on the basic session setup with Firefox. I would assume at least some testing should be attempted before releasing something as "experiment" to the public. I understand the purpose of this experiment, but since it was released without testing, all we got as a result are guaranteed failures whenever it is enabled. 

Regards,

_____________
Roman Shpount

[Justin Uberti]

If you don't understand FQDN addresses, just ignore them. The rationale here has been discussed at length and while there are bugs that will be fixed, arguing against the use of FQDNs (which were explicitly permitted by RFC5245) is not productive.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/043b2f7a-5e7f-4c23-b75a-fa5f2dd4a9a1%40googlegroups.com.

[Roman Shpount]

On Wednesday, February 6, 2019 at 1:40:23 PM UTC-5, Justin Uberti wrote:

If you don't understand FQDN addresses, just ignore them. The rationale here has been discussed at length and while there are bugs that will be fixed, arguing against the use of FQDNs (which were explicitly permitted by RFC5245) is not productive.

Can you point out a single existing ICE implementation which supports FQDN (except current Chrome experiment)? Did Chrome team test this with against any implementations?

I am not arguing against FQDN. I am arguing against how this experiment was released. It should have been released under a flag so that other people had a chance to test and fix their implementations to support FQDN in controlled environment. Randomly enabling FQDN without any previous testing simply creates a bunch of support tickets with no opportunity to prepare for this issue which is extremely counter productive.

Regards, 

_____________

Roman Shpount 

[Philipp Hancke]

this has been available since mid-november in canary, see https://twitter.com/juberti/status/1062850132507381763

First mention on this list is in the M72 release notes. This could have been communicated here earlier but I am starting to sound like a broken record on that topic.

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e9349b10-b9d5-43df-b945-91dd27ca7d8c%40googlegroups.com.

[Justin Uberti]

It was released under a flag, 3 months ago: https://twitter.com/juberti/status/1062850132507381763. 

We have now promoted it to an experiment in Chrome Canary, whose primary purpose is for early testing. Note also that this feature is now enabled in the latest Safari Technical Preview, and we have tested interoperability with Safari (as well as Chrome stable).

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e9349b10-b9d5-43df-b945-91dd27ca7d8c%40googlegroups.com.

[Lorenzo Miniero]

Well, it does work in Janus, which is based on libnice, but of course we had to handle the resolution of the msdn address ourselves in that case. You can check the code we added here to see if it can help you too: https://github.com/meetecho/janus-gateway/commit/0a5f379ad3bc521718cd0fb90e3008a09837baff

Lorenzo

[Harald Alvestrand]

Does libnice ignore the mdns candidates, does it reject the whole SDP when mdns candidates are present, or does it fail the "add candidate" function when new candidates come along in mdns form?

The first and last versions should result in a connection if TURN or STUN candidates are present; rejecting the whole SDP seems like it's not really SDP-compatible.

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/88a18d36-8fcb-4524-8eee-378d2d2d8312%40googlegroups.com.

[Alan Ford]

The problem for us is that our implementation expects at least one candidate at each end to do candidate pairing for connectivity checks. If all the FQDN candidates are stripped/ignored, then there are no candidates, thus no pairs, and no connectivity. I am trying to verify whether this is behaviour inherited from libnice or something specific to us.

[Lorenzo Miniero]

The way it works is that you pass the remote candidates you want added: it typically doesn't process the whole SDP, that's up to the application.

I can't remember how it rejected the mDNS candidates when I first tried, as I added the mDNS resolution in my own code when Safari first experimented with it. IIRC, though, the process would just fail if mDNS candidates were all there was (e.g., LAN-only test), as in that case the candidates would be rejected, there would be no remote candidate to test against, and the connectivity checks would never start (they're automatically started only the first time you invoke nice_agent_set_remote_candidates). It shouldn't be an issue if srflx and relay candidates are there too, because connectivity checks would be triggered in that case and it would either fallback on those, or on the prflx candidates obtained out of the previously ignored mDNS candidates.

As anticipated, though, resolving the mDNS address in the application and passing that to libnice works as expected.

Lorenzo

[Lorenzo Miniero]

As I explained, you can do the resolution for those *before* passing the candidate to libnice. Works nicely (pun intended!) for us.

Anyway, I made the libnice developers aware of the problem here: https://gitlab.freedesktop.org/libnice/libnice/issues/68

Lorenzo

[Harald Alvestrand]

OK. Failure when you a) don't have TURN or STUN candidates and b) don't understand MDNS is expected, I think (you can't start performing connectivity checks). Part of the point of the experiment is to see if the breakage caused by this situation is acceptable or unacceptable.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/954f9a2b-c477-4473-a0eb-a9e193289ee9%40googlegroups.com.

[Alan Ford]

Thanks for the confirmation on behaviour, Lorenzo. But this of course doesn't work if you're not in the same mDNS network segment, which is probably the vast majority of users! The problem still stands that if these FQDNs are not resolvable, and there are no other options (which would be default behaviour today), then there are no candidates available to do candidate pairing.

[Philipp Hancke]

which is a problem why? The server will announce non-mdns candidates and the client will attempt to connect to them, no?

(I typically don't even bother to send candidates to my servers, but they're ice-lite so...)

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/fa828a1c-ac59-487f-8c08-be95b906829b%40googlegroups.com.

[Lorenzo Miniero]

Il giorno giovedì 7 febbraio 2019 13:50:07 UTC+1, Philipp Hancke ha scritto:

which is a problem why? The server will announce non-mdns candidates and the client will attempt to connect to them, no?

(I typically don't even bother to send candidates to my servers, but they're ice-lite so...)

The problem is that libnice expects at least a valid remote candidate to start connectivity checks: this may not be needed/true in case it's configured to work in Lite mode, but I'm not sure (I'd have to check). So if mDNS candidates are the only candidates it receives (no srflx, no relay), and for a reason or another their address cannot be resolved (mDNS not supported, or as Alan pointed out maybe endpoints not in the same segment), then ICE will never start.

Lorenzo

[Lorenzo Miniero]

Small update on this (sorry for the noise! checking my notes makes me remember things I forgot :-) )

This is not really an issue in libnice either, as it's one I had to face in Janus myself some time ago and that I fixed with a workaround.

Basically, as I was saying, even when no candidates are explicitly added to libnice, libnice still answers to connectivity checks, meaning that prflx can be discovered and notified to the application. The fix I applied is to basically add these prflx candidates via nice_agent_set_remote_candidates() to kickstart the process. I confirmed this works in my setup, so I hope it helps those in the same situation (Alan included).

Lorenzo

[Roman Shpount]

Hi Lorenzo,

Thank you for the insight. 

Did you also update Janus to accept SDP with no destination address in c= line or do you expect client to always use STUN/TURN and put address in there?

Thank You,

[Lorenzo Miniero]

Hi Roman,

to be honest, in Janus I ignore the c= lines or ports in the m-line: all the connectivity information exchange is done via candidates, whether they're trickled or part of the SDP.

Lorenzo

[Roman Shpount]

On Thursday, February 7, 2019 at 7:13:42 AM UTC-5, Harald Alvestrand wrote:

OK. Failure when you a) don't have TURN or STUN candidates and b) don't understand MDNS is expected, I think (you can't start performing connectivity checks). Part of the point of the experiment is to see if the breakage caused by this situation is acceptable or unacceptable.

Does this mean RFC8445 needs to be updated to explain how ICE nomination process works without any candidates? If FQDN are allowed and ignored, ICE agent can end up with no candidates in the "waiting for connectivity checks" state, which is new. 

Also, based on your description, it looks like the experiment was to check how many applications operate without setting STUN/TURN servers and communicating outside of local segment. There were probably easier ways to find this out. As it stands right now, PSA should be "STUN/TURN server must be set if communicating outside of the local segment".

Regards,

______________

Roman Shpount

[Justin Uberti]

If you don't use STUN or TURN servers, your application probably didn't work very well before...

Regardless, even if one side doesn't understand mDNS, things will continue to work. The non-mDNS side will send an IP address candidate, the mDNS side will form a candidate pair with that address, and then the non-mDNS side will get an incoming connectivity check which will cause it to form a prflx candidate, and everything is good.

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6ae24db6-60e3-4a03-b480-a874a415809e%40googlegroups.com.

[Roman Shpount]

On Thu, Feb 7, 2019 at 11:32 AM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:

If you don't use STUN or TURN servers, your application probably didn't work very well before...

 

Why? If you have a server running on public IP with UDP and TCP candidates, it works extremely well without STUN or TURN. In fact, all STUN or TURN servers do in this case are slowing call setup down and, in case of TURN, add latency by introducing extra hop.

Regardless, even if one side doesn't understand mDNS, things will continue to work. The non-mDNS side will send an IP address candidate, the mDNS side will form a candidate pair with that address, and then the non-mDNS side will get an incoming connectivity check which will cause it to form a prflx candidate, and everything is good.

In the above described case, server ends up with no usable candidates. So, the ICE nomination process on the server stops before getting any prflx candidates.

Regards,

_____________
Roman Shpount

 

[Justin Uberti]

That doesn't happen with trickle ICE. But if you are using vanilla ICE and all you need is a candidate to prevent the ICE process for terminating, just make up a fake address, e.g. 0.0.0.1 or some such.

Regards,

_____________
Roman Shpount

 

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAD5OKxtr-B0gzAYSciCihcenSb4i3NN0ApVeoK%3DRhMB-szRoUA%40mail.gmail.com.

[Roman Shpount]

On Thu, Feb 7, 2019 at 12:07 PM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:

On Thu, Feb 7, 2019 at 8:42 AM Roman Shpount <rshp...@gmail.com> wrote:

On Thu, Feb 7, 2019 at 11:32 AM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:

If you don't use STUN or TURN servers, your application probably didn't work very well before...

 

Why? If you have a server running on public IP with UDP and TCP candidates, it works extremely well without STUN or TURN. In fact, all STUN or TURN servers do in this case are slowing call setup down and, in case of TURN, add latency by introducing extra hop. 

Regardless, even if one side doesn't understand mDNS, things will continue to work. The non-mDNS side will send an IP address candidate, the mDNS side will form a candidate pair with that address, and then the non-mDNS side will get an incoming connectivity check which will cause it to form a prflx candidate, and everything is good.

In the above described case, server ends up with no usable candidates. So, the ICE nomination process on the server stops before getting any prflx candidates.

That doesn't happen with trickle ICE. But if you are using vanilla ICE and all you need is a candidate to prevent the ICE process for terminating, just make up a fake address, e.g. 0.0.0.1 or some such.

 

Even with trickle ICE this will happen when end of candidates is received but no usable candidates were sent.

Setting up some sort of reasonable time-out (40 seconds) before stopping the nomination process even when no usable candidates are available should resolve this issue.

Regards,

_____________
Roman Shpount

 

[Justin Uberti]

On Thu, Feb 7, 2019 at 10:23 AM Roman Shpount <rshp...@gmail.com> wrote:

On Thu, Feb 7, 2019 at 12:07 PM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:

On Thu, Feb 7, 2019 at 8:42 AM Roman Shpount <rshp...@gmail.com> wrote:

On Thu, Feb 7, 2019 at 11:32 AM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:

If you don't use STUN or TURN servers, your application probably didn't work very well before...

 

Why? If you have a server running on public IP with UDP and TCP candidates, it works extremely well without STUN or TURN. In fact, all STUN or TURN servers do in this case are slowing call setup down and, in case of TURN, add latency by introducing extra hop. 

Regardless, even if one side doesn't understand mDNS, things will continue to work. The non-mDNS side will send an IP address candidate, the mDNS side will form a candidate pair with that address, and then the non-mDNS side will get an incoming connectivity check which will cause it to form a prflx candidate, and everything is good.

In the above described case, server ends up with no usable candidates. So, the ICE nomination process on the server stops before getting any prflx candidates.

That doesn't happen with trickle ICE. But if you are using vanilla ICE and all you need is a candidate to prevent the ICE process for terminating, just make up a fake address, e.g. 0.0.0.1 or some such.

 

Even with trickle ICE this will happen when end of candidates is received but no usable candidates were sent.

Hmm, this is a good point, but won't this already happen today? That is, if you supply a single 192.168.x.x host candidate from the client, won't the server fail its ICE checks to that candidate immediately, leading to termination of ICE?

Setting up some sort of reasonable time-out (40 seconds) before stopping the nomination process even when no usable candidates are available should resolve this issue.

Agreed, it seems like both endpoints will need to wait N seconds after the offer-answer exchange (including end-of-candidates if relevant) to provide time for discovery of any prflx candidates. @emcho, what do you think? 

Regards,

_____________
Roman Shpount

 

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAD5OKxuQ_7hLOWB61XQ1rhBJMuG98Wvi8KF7217zLSoAujiarw%40mail.gmail.com.

[Roman Shpount]

On Thu, Feb 7, 2019 at 5:02 PM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:

On Thu, Feb 7, 2019 at 10:23 AM Roman Shpount <rshp...@gmail.com> wrote:

On Thu, Feb 7, 2019 at 12:07 PM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:

On Thu, Feb 7, 2019 at 8:42 AM Roman Shpount <rshp...@gmail.com> wrote:

On Thu, Feb 7, 2019 at 11:32 AM 'Justin Uberti' via discuss-webrtc <discuss...@googlegroups.com> wrote:

If you don't use STUN or TURN servers, your application probably didn't work very well before...

 

Why? If you have a server running on public IP with UDP and TCP candidates, it works extremely well without STUN or TURN. In fact, all STUN or TURN servers do in this case are slowing call setup down and, in case of TURN, add latency by introducing extra hop. 

Regardless, even if one side doesn't understand mDNS, things will continue to work. The non-mDNS side will send an IP address candidate, the mDNS side will form a candidate pair with that address, and then the non-mDNS side will get an incoming connectivity check which will cause it to form a prflx candidate, and everything is good.

In the above described case, server ends up with no usable candidates. So, the ICE nomination process on the server stops before getting any prflx candidates.

That doesn't happen with trickle ICE. But if you are using vanilla ICE and all you need is a candidate to prevent the ICE process for terminating, just make up a fake address, e.g. 0.0.0.1 or some such.

 

Even with trickle ICE this will happen when end of candidates is received but no usable candidates were sent.

Hmm, this is a good point, but won't this already happen today? That is, if you supply a single 192.168.x.x host candidate from the client, won't the server fail its ICE checks to that candidate immediately, leading to termination of ICE?

I think adding a single 192.168.x.x. address this would act the same as bogus address, that you have proposed. So this will keep ICE nomination process running until STUN bind transaction to this address times out, which is, by default is 39.5 seconds. This is usually enough to peer reflexive candidates to be collected.

_____________
Roman Shpount

 

[Alessandro Amirante]

Is it safe to assume that only *private* host candidates will be affected, while *public* ones will still be gathered?

I made a few tests with this feature enabled via chrome flags and it seemed to kill IPV6. Didn't test extensively though, so I may be wrong. I'll report back when I make more tests tomorrow.

[Alessandro Amirante]

I stand corrected, v6 candidates are still there.

[Justin Uberti]

We don't know if the candidate is public or not unless you supply a STUN server, but if a STUN server is present, you should get a raw IP address candidate (either host or srflx as appropriate)

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9e2633f0-60b2-41f7-82f1-f699963ac532%40googlegroups.com.

[Lorenzo Miniero]

Can't RFC1918 be used as a first way to distinguish them? Or are there addresses outside of those spaces that look public but really aren't?

Lorenzo

[Justin Uberti]

Right, and IPv6 has no such shortcuts.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2d2f1a9d-e6d2-4449-b2d8-001a751985eb%40googlegroups.com.

[Alessandro Amirante]

I guess you can't really know how people configure their private networks. They can use IP addresses from a public space internally. 

Anyway, I have some concerns about obfuscating *all* host candidates with mDNS. In this way, connectivity via host candidates is limited to LAN only. Peers with public IPs that can communicate without STUN would instead require it. This is a limitation especially with IPv6, as v6 addresses are usually publicly reachable even in natted environments.

You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/4Yggl6ZzqZk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2d2f1a9d-e6d2-4449-b2d8-001a751985eb%40googlegroups.com.

[Justin Uberti]

STUN is cheap though - why not use that to avoid this issue?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAEk4y02aMMKDypBkX1ZxsA%3DJoDTauu7jL2hQnsY8jQF5cgDNgg%40mail.gmail.com.

[Alan Ford]

Within an enterprise, with multiple network segments (for example), you don't need a STUN server today. With mDNS, you would need one. The bureaucracy, overhead, maintenance, etc, of deploying another server seems unnecessary and prohibitive (external STUN may also not be an option due to security policies).

[Justin Uberti]

There are various solutions here; the application server could act a STUN server; libnice could be updated; a bogus candidate could be generated.

However, resolution of https://bugs.chromium.org/p/chromium/issues/detail?id=930339 should make this a non-issue.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/69e84ecf-1830-47c2-96da-da94fcf86b68%40googlegroups.com.

[Danilo]

Within an enterprise, with multiple network segments (for example), you don't need a STUN server today. With mDNS, you would need one. The bureaucracy, overhead, maintenance, etc, of deploying another server seems unnecessary and prohibitive (external STUN may also not be an option due to security policies).

By the way, that doesn't only apply to VLAN based network segments, but for example many WiFi access points (e.g. by Cisco Small Business) also drop any mDNS broadcasts at the WiFi-boundary (and this can't be turned off). That means that mDNS candidates can only be resolved when the two sides are connected to the same AP within the company.

Are there any stats being collected about the "resolvability" of mDNS-candidates versus regular IP candidates in the wild? Is there a significant difference?

 

On Sunday, February 10, 2019 at 12:29:48 AM UTC+1, Justin Uberti wrote:

However, resolution of https://bugs.chromium.org/p/chromium/issues/detail?id=930339 should make this a non-issue.

+1, that's a good improvement for media based applications (using host candidates for tracking is definitely not nice).

However, it means that for enterprise users of datachannel-only applications, they now have the choice between accepting the privacy implications of explicitly giving microphone/camera permissions to an application that does not require microphone or camera, versus accepting the privacy implications of data traffic going through a third party TURN server even though both clients are in the same network.

I understand the aversion to adding more prompts, but I'm still convinced that an "Allow this application to establish a direct data connection" prompt for non-media applications would solve a lot of those issues. First of all it would not require data-only applications to request camera and microphone access, and you could apply the same technique as in issue 930339 for data channels. If the permission is granted, return plain host IPs, otherwise return mDNS FQDNs.

It's really hard to convey the meaning seemingly unrelated permissions to the user. Case in point: In Android the user needs to grant location permission in order to establish BLE connections. Of course, BLE can be used for tracking, therefore the location permission makes sense to an informed developer, but just check out Fitbit forums to see how many people are upset because the Fitbit app wants to access the location. The same thing could happen with the getUserMedia permission.

Danilo

[Lorenzo Miniero]

Il giorno lunedì 11 febbraio 2019 09:29:22 UTC+1, Danilo ha scritto:

On Sunday, February 10, 2019 at 12:29:48 AM UTC+1, Justin Uberti wrote:

However, resolution of https://bugs.chromium.org/p/chromium/issues/detail?id=930339 should make this a non-issue.

+1, that's a good improvement for media based applications (using host candidates for tracking is definitely not nice).

However, it means that for enterprise users of datachannel-only applications, they now have the choice between accepting the privacy implications of explicitly giving microphone/camera permissions to an application that does not require microphone or camera, versus accepting the privacy implications of data traffic going through a third party TURN server even though both clients are in the same network.

I understand the aversion to adding more prompts, but I'm still convinced that an "Allow this application to establish a direct data connection" prompt for non-media applications would solve a lot of those issues. First of all it would not require data-only applications to request camera and microphone access, and you could apply the same technique as in issue 930339 for data channels. If the permission is granted, return plain host IPs, otherwise return mDNS FQDNs.

And as we pointed out a few other times, it's not just datachannel-only PeerConnections: recvonly audio/video ones would suffer from the same constraint. One more reason why I've never understood why getUserMedia is being used as a consent to communicate.

Lorenzo

[Justin Uberti]

On Mon, Feb 11, 2019 at 12:29 AM Danilo <gez...@gmail.com> wrote:

Within an enterprise, with multiple network segments (for example), you don't need a STUN server today. With mDNS, you would need one. The bureaucracy, overhead, maintenance, etc, of deploying another server seems unnecessary and prohibitive (external STUN may also not be an option due to security policies).

By the way, that doesn't only apply to VLAN based network segments, but for example many WiFi access points (e.g. by Cisco Small Business) also drop any mDNS broadcasts at the WiFi-boundary (and this can't be turned off). That means that mDNS candidates can only be resolved when the two sides are connected to the same AP within the company.

Are there any stats being collected about the "resolvability" of mDNS-candidates versus regular IP candidates in the wild? Is there a significant difference?

 

Yes, this will all be analyzed (in aggregate).

 

On Sunday, February 10, 2019 at 12:29:48 AM UTC+1, Justin Uberti wrote:

However, resolution of https://bugs.chromium.org/p/chromium/issues/detail?id=930339 should make this a non-issue.

+1, that's a good improvement for media based applications (using host candidates for tracking is definitely not nice).

However, it means that for enterprise users of datachannel-only applications, they now have the choice between accepting the privacy implications of explicitly giving microphone/camera permissions to an application that does not require microphone or camera, versus accepting the privacy implications of data traffic going through a third party TURN server even though both clients are in the same network.

I understand the aversion to adding more prompts, but I'm still convinced that an "Allow this application to establish a direct data connection" prompt for non-media applications would solve a lot of those issues. First of all it would not require data-only applications to request camera and microphone access, and you could apply the same technique as in issue 930339 for data channels. If the permission is granted, return plain host IPs, otherwise return mDNS FQDNs.

It's really hard to convey the meaning seemingly unrelated permissions to the user. Case in point: In Android the user needs to grant location permission in order to establish BLE connections. Of course, BLE can be used for tracking, therefore the location permission makes sense to an informed developer, but just check out Fitbit forums to see how many people are upset because the Fitbit app wants to access the location. The same thing could happen with the getUserMedia permission.

This has been discussed at length, and the conclusion was that this sort of prompt is too low-level for users to understand. 

But we might be worrying too much about this. Let's see what the experimental data shows. 

Danilo

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/0ecef485-734b-4128-82c8-cf663cb4c56d%40googlegroups.com.

[Jeremy Noring]

I'm probably adding noise to the conversation, but for those of us who don't care about p2p functionality (read: we're using webrtc with a media server), I've always wanted a "simplified" connection mode for webrtc. In this configuration, ICE amounts to nothing more than complexity and an additional point of failure.

[Jozsef Vass]

This does not seem to be working with loopback. I enable the flag in Chrome 72 and https://webrtc.github.io/samples/src/content/peerconnection/pc1/ or https://webrtc.github.io/samples/src/content/peerconnection/audio/ does not work any more. This affects our microphone/speaker self test in the browser.

Jozsef

On Mon, Jan 28, 2019 at 1:36 PM Jeroen de Borst <jero...@webrtc.org> wrote:

An experiment to use mDNS to obfuscate host candidate IP addresses has started in Chrome Canary (M73).

With this feature, host IPs will no longer directly be exposed by the RTCPeerConnection API, increasing privacy. Host candidates will only indirectly be exposed through a randomly generated mDNS hostname.

Purpose and mechanisms used are described in this spec:

https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02

The expected effects on connectivity between 2 WebRTC agents are:

1. Two WebRTC agents using this feature, running in the same private network, may no longer be able to communicate directly if they are not in the same mDNS broadcast domain.
   
2. A WebRTC agent using this feature will still be able to communicate with other agents on the same private network when the other agent does not have this feature (implemented or enabled). In this case, the other agent would classify the obfuscated host candidates as peer-reflexive candidates.
   
3. Connectivity using server-reflexive or relay candidates will be unaffected.
   

No application code is affected by this feature, so there are no actions for developers with regard to this experiment.

This experiment affects Chrome on Windows, MacOS and Linux.

Regards,

Jeroen

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAM6ffLJoag6MpF7s827Lq-wHd%3DtZ3aRvQiHqq60%3DX-5%2BHVAKSg%40mail.gmail.com.

[Justin Uberti]

Please try again with Chrome 73, file a crbug if it doesn't work there.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CACHtiy_s6k35kWTpD2F%3Dsx%3D8aj2s1P8LdFW%2B_5-yMuMjJHxVaw%40mail.gmail.com.

[Jozsef Vass]

Tested with Chrome Beta 73.0.3686.27 and Canary 74.0.3705.0 and both worked.

Thank you.

Jozsef

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOJ7v-1JukWmYBvmckfSnT7r-%2BYMSqVMk5di-Gi6C9Crn4Uf4g%40mail.gmail.com.

[mawo...@cisco.com]

This host candidates IP address obfuscation is also breaking the Cisco Meeting Server (it's a Cisco product for on-premise video conferencing, part of Cisco Webex Meetings portfolio). The server currently fails to process a whole batch of ice candidates received from the client app if one of them contains an invalid ip address - this results in other good relay or server reflexive candidates being ignored. This can be easily fixed, but there are further problems with the fact that mDNS doesn't work in some of our customer networks, even on the Cisco internal network mDNS is getting blocked so the lookup fails in cases where both hosts are still on Cisco LAN and could otherwise reach each other using the LAN IPs directly.

Therefore, can I get a confirmation that this feature will not make it into Chrome stable version until https://bugs.chromium.org/p/chromium/issues/detail?id=930339 is resolved? This should be good enough for us as we always ask for camera/mic permissions.

Regards,

Marcin

[Qingsi Wang]

The feature is behind a flag that defaults to disabled and the current experiment is for the canary builds. We do not expect to change the setup before https://bugs.chromium.org/p/chromium/issues/detail?id=930339 is finally resolved, and we also expect this issue resolved before M73 stable.

Best,

Qingsi

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d939c142-3950-4a2d-b126-4535a79c83fe%40googlegroups.com.

[Nikita Petrov]

What is the target version for production rollout of mDNS obfuscation by default? Is it M73 stable?

[Justin Uberti]

That's the current target, but that's somewhat optimistic and assumes we don't find any new issues during the rollout.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7889997f-37b6-4592-96af-419b673e4303%40googlegroups.com.

[Basar Daldal]

Hi, 

What is the latest update on the plan for having mDNS obfuscation by default? I see the the default is still disabled on m73 stable and latest Chrome Canary

Thanks,

Basar

[Qingsi Wang]

WebRTC users,

We are gradually expanding our experiment of using mDNS to conceal host IP addresses in M75 Stable. This feature is gated by the getUserMedia() permissions, and the IP address of a host candidate will be replaced by a type-4 UUID if it is gathered without the media capture permission via getUserMedia(). For the latest standardization draft on the purpose and mechanisms used, please see https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-03.

For applications that rely on the local IP addresses, performance impact can be expected if the media capture permission is not granted during the use. For development, debugging, and managed deployment, this feature can be disabled without enrolled into the experiment as follows:

1. Keep chrome://flags/#enable-webrtc-hide-local-ips-with-mdns as "Default"

2. Launch chrome with the following command line

path_to_chrome --disable-field-trial-config --disable-features=WebRtcHideLocalIpsWithMdns

This experiment affects Chrome on Windows, MacOS, Linux and ChromeOS.

Best regards,

Qingsi

[Lennart Grahl]

I think it's unfortunate that this is being activated before a potential solution to the privilege escalation of getUserMedia has been discussed.

[Francesco Durighetto]

Am I the only one not receiving srflx candidates alongside a single uuid.local mDns address even with valid turn and stun config?

Chrome: 75.0.3770.100 

SCENARIO:

subscriber only (chrome) —> SFU (ICE stack based on libnice)

subscriber send offer (receivevideo: true, recvaudio: true), SFU send answer. SFU is faster on sending candidates back to chrome.
Chrome tries to connect to our SFU and succeeded in that, so it only send a mdns.local candidate to SFU.

This candidate is not already supported by libnice, which drops that candidate.
Chrome sees the peerconnection in Connected state, so it doesn’t bother to send other candidates to our SFU (should send at least one srflx imo).

But for libnice, no remote candidates are received since the only mdns.local was dropped.

This prevents libnice to start it’s own connectivity check (by design, even if there are few proposal to handle this mdns candidates, still working on it), so for our SFU, no clients are currently “connected”, even if chrome is indeed in connected state.

So my current workaround is to “fake” a remote candidate when a .local is received and I wasn’t able to resolve it, to force libnice to start connectivity check and let him “know” that a remote peer is already connected, so it calls a callback and our codebase can start working.

I would not call this an "experiment"

[Qingsi Wang]

> Chrome sees the peerconnection in Connected state, so it doesn’t bother to send other candidates to our SFU

Does it mean RTCPeerConnection.onicecandidate is not triggered? Other candidates should surface from the peer connection regardless of whether it's connected or not. If onicecandidate is not triggered, please file a bug on crbug.com and I'll look into it. Can you also confirm this is not the behavior of the web app in handling candidates?

--

---
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 discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8c5f68bd-c740-4d30-a71a-1ad716adcf8a%40googlegroups.com.

[Philipp Hancke]

webrtc.org has forever been not gathering srflx and relay candidates when the connection got established early. Which is a somewhat useful optimization in general but... not in this case.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CA%2Bm752L9mx6Lv0qTXSxjemNbkTD5SXmn7u%2B090wcQ%3D0v81CVBA%40mail.gmail.com.

[Harald Alvestrand]

The reception of a connectivity check at the SFU end SHOULD result in a peer-reflexive candidate being registered at that end. Shouldn't the SFU end start connectivity checks when it gets a peer-reflexive candidate?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiJ3%2BvqcKsObpP3MV%3Da5Ggv3c0oWfooVDqbULO8WjEHTZw%40mail.gmail.com.

[Francesco Durighetto]

Exactly, onicecandidate is not triggered. As Philipp said in the next post, Webrtc.org never sent additional candidates to reduce overhead in ice stack I think, but in this case could potentially breaks the currently deployed SFUs implementation.

Here's the issue: crbug

Il giorno martedì 16 luglio 2019 19:55:51 UTC+2, Qingsi Wang ha scritto:

> Chrome sees the peerconnection in Connected state, so it doesn’t bother to send other candidates to our SFU

Does it mean RTCPeerConnection.onicecandidate is not triggered? Other candidates should surface from the peer connection regardless of whether it's connected or not. If onicecandidate is not triggered, please file a bug on crbug.com and I'll look into it. Can you also confirm this is not the behavior of the web app in handling candidates?

On Tue, Jul 16, 2019 at 5:33 AM Francesco Durighetto <francesco...@gmail.com> wrote:

Am I the only one not receiving srflx candidates alongside a single uuid.local mDns address even with valid turn and stun config?

Chrome: 75.0.3770.100 

SCENARIO:

subscriber only (chrome) —> SFU (ICE stack based on libnice)

subscriber send offer (receivevideo: true, recvaudio: true), SFU send answer. SFU is faster on sending candidates back to chrome.
Chrome tries to connect to our SFU and succeeded in that, so it only send a mdns.local candidate to SFU.

This candidate is not already supported by libnice, which drops that candidate.
Chrome sees the peerconnection in Connected state, so it doesn’t bother to send other candidates to our SFU (should send at least one srflx imo).

But for libnice, no remote candidates are received since the only mdns.local was dropped.

This prevents libnice to start it’s own connectivity check (by design, even if there are few proposal to handle this mdns candidates, still working on it), so for our SFU, no clients are currently “connected”, even if chrome is indeed in connected state.

So my current workaround is to “fake” a remote candidate when a .local is received and I wasn’t able to resolve it, to force libnice to start connectivity check and let him “know” that a remote peer is already connected, so it calls a callback and our codebase can start working.

I would not call this an "experiment"

--

---
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 discuss...@googlegroups.com.

[Qingsi Wang]

Thanks for opening the bug. I verified the cause in the source and I think libwebrtc does stop the gathering when we have a connected pair. On the other hand, like Harald pointed out, upon learning the prflx candidate (the underlying IP of the mDNS name) on the server side, wouldn't the server be able to ping the user with triggered checks?

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/aee22b90-875f-49df-9649-d8678d72fa39%40googlegroups.com.

[youenn fablet]

FWIW, some webrtc solutions faced the same issue with Safari 11 and
12. In that specific case, no candidate at all was provided by Safari.
A robust webrtc server should probably not rely on the fact that an
unnecessary candidate (be it MDNS, host or SRFLX) is provided by the
client. It might for instance be that the mDNS registration fails, the
STUN server has a temporary outage... It also potentially slows down
the connection setup.
I agree with Harald in that the reception of a PRFLX candidate should
be sufficient to proceed.
Some webrtc solutions were updated when adopting Safari for that reason.
Y
Le mer. 17 juil. 2019 à 01:10, Francesco Durighetto
<francesco....@gmail.com> a écrit :

> To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/aee22b90-875f-49df-9649-d8678d72fa39%40googlegroups.com.