Subject: [rtcweb] Please require user consent for data channels

From: Daniel Roesler <[email-masked]>
Date: Sat, 11 Jul 2015 09:42:29 -0700

Howdy all, this is mostly a re-surfacing of the discussion about IP
address leaking back in April[1], which unfortunately I did not
discover until recently.

One of the items in the new proposal was "WebRTC already requires
permission to access getUserMedia. Why not use that permission to
control interface enumeration?" That item didn't really get discussed
much in the thread, but I think it's one of the most important issues.

Why? There is now a documented case where a third party on nytimes.com
is using a fake webRTC datachannel to silently gather user local (and
potentially "real" ISP) IP addresses.

https://twitter.com/incloud/status/619624021123010560

So I'd like to voice my support for adding a consent requirement that
would prevent this type of silent behavior. A user that is
purposefully visiting a site that has a legitimate reason for using a
webRTC data channel will have the necessary context to give consent,
just like they have to get consent on getUserMedia.

I'm really unclear on why it's so important to have the silent webRTC
data channel behavior. P2P data connections should be held to the same
consent requirements just like P2P video and voice connections. In
addition to the silent third party local IP tracking, a silent P2P
data channel opens up users to silently becoming nodes in a web-based
file sharing network. For example, webtorrent[2] can be silently
embedded on a website so that all of the users to that website start
seeding content they don't know they are seeding.

Possible fix:

1. Require user consent before calling the callback on createOffer().
2. If the user has already given consent via getUserMedia, the user
consent requirement is satisfied.
3. If there's no previous gUM consent, then ask the user for consent.

This implementation requires no updates to current webRTC demos, since
you have to wait for a callback on createOffer anyway. I'm open to
other ways, such as making createDataChannel asynchronous like gUM,
but that would require updates to existing apps that use
createDataChannel.

Thanks!
Daniel Roesler

[1]: https://www.ietf.org/mail-archive/web/rtcweb/current/msg14494.htm
[2]: https://github.com/feross/webtorrent

---

From: Matthew Kaufman <[email-masked]>
Date: Sat, 11 Jul 2015 21:26:30 -0700

On 7/11/2015 9:42 AM, Daniel Roesler wrote:
> ...

On the IPv6 Internet, the IP address you use to reach the web site is 
almost certainly the same as your "local" IP address. There's no 
additional information exposed by allowing an application to discover 
that information directly via JavaScript.

The IPv4 Internet is essentially out of addresses and in the process of 
being retired. I don't believe there's any reason at this point to 
disable functionality in order to improve compatibility with this legacy 
network.

Matthew Kaufman

ps. You can also gather all these addresses for any browser with Flash 
Player installed by asking Flash to connect via RTMFP to a server, 
whereupon it will report the full enumeration of available IPv4 and IPv6 
addresses to that server.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sun, 12 Jul 2015 10:49:31 +0200

Hi,

While acknowledging that there might be a potential privacy issue, I 
don't think agree on your analysis on the issue that you have made nor 
your proposal.

The information available in the ICE gathering process and made 
available to the JS app is the following:

-Host candidates, mostly private IP addresses
-Server reflexive candidates, exposing the public IP address as shown by 
the TURN/STUN server
-Relay candidates, hosted by the TURN server

My understanding of the issue is that the leak happens when the 
application is able to retrieve information not already available to it.
That happens either when the user is using a VPN and have multiple 
public IP addresses or using an external PROXY so the http/ws connection 
have a different originator public IP address. AFAIK there should be no 
potential danger in leaking the private IP4 addresses (here you got 
mine, in case you are interested 127.0.0.1 and 192.168.64.2 ;). I have 
not much background on IPv6, so please complete any missing info and how 
would it affect here.

I don't think it is a good idea to tight the solution of requesting user 
permission, to not leak IP information, as theoretically a user could be 
interested in using webrtc (audio/video/datachannels) and still don't 
disclose their public IP address (i.e. forcing all the data to go via a 
TURN server).

One possible solution would be that the browser don't gather/announce 
host&reflexive candidates when an HTTP proxy is set, and only use turn 
relay candidates instead. The second solution (which I think it is 
already discussed somewhere else) would be to allow the user to 
configure a TURN server to override the app settings and force all 
connection to go through it. (Then build a chained-TURN infrastructure 
into TOR and you could have a killer combo ;)

Regarding the issue that the browser becomes a CDN peer, not sure if 
anyone has ever raised the issue before. From my point of view, there is 
not, but in any case, I think it is orthogonal to the leak issue.

Best regards
Sergio

On 11/07/2015 18:42, Daniel Roesler wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Daniel Roesler <[email-masked]>
Date: Sun, 12 Jul 2015 12:19:03 -0700

Thanks very much for the responses! Going to try and address both inline below.

On Sat, Jul 11, 2015 at 9:26 PM, Matthew Kaufman <[email-masked]> wrote:
>
> On the IPv6 Internet, the IP address you use to reach the web site is almost
> certainly the same as your "local" IP address. There's no additional
> information exposed by allowing an application to discover that information
> directly via JavaScript.
>
> being retired. I don't believe there's any reason at this point to disable
> functionality in order to improve compatibility with this legacy network.
>

I disagree with this sentiment. IPv4 will be around for many more
years and many ISPs still do not assign their customers IPv6
addresses. If IPv6 is replacing IPv4 so readily, why not only offer
WebRTC through IPv6? It's a huge double standard to say that we won't
support privacy issues of one network while at the same time
supporting connectivity though it.

> Player installed by asking Flash to connect via RTMFP to a server, whereupon
> it will report the full enumeration of available IPv4 and IPv6 addresses to
> that server.

Yes, however flash can easily be blocked using click-to-enable (i.e.
user consent) and will not be installed on the majority of modern
browsers (mobile devices). WebRTC will be. What I'm asking for here is
a similar flash-blocking behavior to what is possible in Chromium
(built-in setting) and Firefox (via FlashBlock addons), so that users
can choose to click-to-enable based on context (just like they need to
already in getUserMedia).

On Sun, Jul 12, 2015 at 1:49 AM, Sergio Garcia Murillo
<[email-masked]> wrote:
> Hi,
>
> While acknowledging that there might be a potential privacy issue, I don't
> think agree on your analysis on the issue that you have made nor your
> proposal.

I'd like to strongly encourage everyone here to stop treating this
issue as "might be a potential privacy issue". There have been
numerous news articles[1][2][3][4], discussion by
VPNs/Tor[5][6][7][8], my github proof-of-concept has over 1,500 stars
and 195 forks[9], the Mozilla Firefox bug has over 100 comments and is
marked as sec-moderate[10], and we are now seeing it exploited in the
wild to detect VPN users[11]. This is not "might be a potential
privacy issue". This is an existing, significant privacy issue.

[1]: https://torrentfreak.com/huge-security-flaw-leaks-vpn-users-real-ip-addresses-150130/
[2]: http://lifehacker.com/how-to-see-if-your-vpn-is-leaking-your-ip-address-and-1685180082
[3]: https://threatpost.com/webrtc-found-leaking-local-ip-addresses/110803
[4]: http://news.softpedia.com/news/WebRTC-in-Firefox-and-Chrome-Reveals-IPs-Behind-VPN-471881.shtml
[5]: https://www.expressvpn.com/blog/explaining-webrtc-ip-leak-vulnerability-affecting-web-browsers/
[6]: https://trac.torproject.org/projects/tor/ticket/5578
[7]: https://ipleak.net/
[8]: https://www.privateinternetaccess.com/forum/discussion/8204/
[9]: https://github.com/diafygi/webrtc-ips
[10]: https://bugzilla.mozilla.org/show_bug.cgi?id=959893
[11]: https://twitter.com/incloud/status/619624021123010560

>
> The information available in the ICE gathering process and made available to
> the JS app is the following:
>
> -Server reflexive candidates, exposing the public IP address as shown by the
> TURN/STUN server
> My understanding of the issue is that the leak happens when the application
> is able to retrieve information not already available to it.
> That happens either when the user is using a VPN and have multiple public IP
> addresses or using an external PROXY so the http/ws connection have a
> different originator public IP address. AFAIK there should be no potential
> danger in leaking the private IP4 addresses (here you got mine, in case you
> are interested 127.0.0.1 and 192.168.64.2 ;). I have not much background on
> IPv6, so please complete any missing info and how would it affect here.

If you read the above articles and discussion surrounding the leak.
The concern is not around local or private IPs, it's around public IPs
for VPN users. Personal VPN use is extremely widespread
internationally, mostly for censorship and content-blocking
circumvention. Chinese users use them to get around the great
firewall. Australian users use them to be able to watch Netflix. Tor
is often not a suitable option because the web service they are trying
to reach blocks Tor (e.g. bank website) or is too data heavy (e.g.
streaming video).

>From the popularity of the issue, it's clear that the vast majority of
users thought that using a VPN hid their real IP address from the
websites they were visiting. It has been a huge shock (including for
me) that default VPN configurations let the browser (and thus WebRC)
know the real IP. Is that an operating system or VPN software issue?
Either way, due to WebRTC this real IP access issue has now spread to
javascript, so that any website can access your real IP.

"AFAIK there should be no potential danger in leaking the private IP4 addresses"

Here's a real-life example of the danger this has. China started
injecting malicious javascript into people's Baidu searches when those
searches came from outside China[12]. This was used to DDOS Github,
but what if that javascript contained a webrtc data channel setup? All
of a sudden, China could obtain the real Chinese IPs of citizens who
were using VPNs. The result of this could definitely be
life-threatening. Again, just saying "use Tor" means those citizens
cannot use many modern internet services (especially streaming video).
Personal VPNs are a fantastic compromise that provide access at quite
good speeds while retaining a good-enough-for-Netflix level or
privacy. WebRTC's real IP leaking removes this middle ground
compromise.

[12]: http://arstechnica.com/security/2015/03/github-battles-largest-ddos-in-sites-history-targeted-at-anti-censorship-tools/

> disclose their public IP address (i.e. forcing all the data to go via a TURN
> server).
>
> host&reflexive candidates when an HTTP proxy is set, and only use turn relay
> candidates instead. The second solution (which I think it is already
> discussed somewhere else) would be to allow the user to configure a TURN
> server to override the app settings and force all connection to go through
> it. (Then build a chained-TURN infrastructure into TOR and you could have a
> killer combo ;)

I'm fully supportive of removing the real IPs from the onicecandidate
results. However, as we saw in April's discussion thread and now in
this thread, identifying that IP is a complex topic that likely
doesn't have an easy answer and might require significant browser or
operating system-level changes. So, I'm suggesting here that an easier
solution is to make data channels require user-consent (again, just
like what already happens with audio and video channels).

>
> Regarding the issue that the browser becomes a CDN peer, not sure if anyone
> has ever raised the issue before. From my point of view, there is not, but
> in any case, I think it is orthogonal to the leak issue.

It is orthogonal to the privacy issue, but this user-consent proposal
also helps address this issue, too.

Thanks again for the responses!
Daniel

---

From: Lorenzo Miniero <[email-masked]>
Date: Sun, 12 Jul 2015 21:35:56 +0200

On Sun, 12 Jul 2015 12:19:03 -0700

> like what already happens with audio and video channels).

I don't see how that would fix anything. Setting up a recvonly audio/video PeerConnection won't get you any user-consent request either.

Forcing TURN in those cases seems more like it.

Lorenzo

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 12 Jul 2015 22:14:20 +0200

> On 12 Jul 2015, at 21:19, Daniel Roesler <[email-masked]> wrote:
> 
Don't you ask for user consent for a peer connection?

Best regards
Michael

---

From: tim panton <[email-masked]>
Date: Sun, 12 Jul 2015 21:15:08 +0100

> On 12 Jul 2015, at 20:19, Daniel Roesler <[email-masked]> wrote:
> 

The problem is that those VPNs are misconfigured.
If you want your VPN to ensure you don’t reveal the ISP provided public IP,
then you shouldn’t allow it to be the default route. You set the default 
route to the VPN - and then add a specific route to let just the VPN packets flow 
out with that IP.

If you do this correctly the STUN address webRTC gets is that of the far end of the 
VPN tunnel - which your website already knew.

I don’t think that just because some VPN service vendors can’t update their 
scripts correctly we should freeze web protocols.

This doesn’t help http proxy services of course, but that isn’t a VPN.

Tim.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 12 Jul 2015 15:02:58 -0700

Consent is an API issue not a protocol and therefore is owned by W3C, not IETF. Why not take it up there?

> On Jul 11, 2015, at 9:42 AM, Daniel Roesler <[email-masked]> wrote:
>

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 13 Jul 2015 08:16:13 -0700

On 7/12/2015 12:19 PM, Daniel Roesler wrote:
> years

Maybe.

> and many ISPs still do not assign their customers IPv6
> addresses.

Only ones that don't expect to stay in business.

>   If IPv6 is replacing IPv4 so readily, why not only offer
> WebRTC through IPv6?

I would support such a proposal.

> It's a huge double standard to say that we won't

IPv6 won't have that "privacy", so there's no reason for IPv4 users to 
continue to expect such.

Matthew Kaufman

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 13 Jul 2015 11:54:55 -0700

> Don't you ask for user consent for a peer connection?

No.

Since there seems to be some misunderstanding on this thread: consent is 
required for getUserMedia (camera/microphone) access. This is true 
regardless of whether or not you send that data anywhere over the 
network. User consent is not required for a peer connection (since you 
cannot use it to send any data that you could not otherwise have just 
relayed through the server, e.g., via WebSockets).

Consent *is* required by the other side to continue receiving your data 
(to prevent DDoS attacks), but that is automatic and does not require 
user intervention (other than viewing a page/running a program designed 
to operate the other end of the PeerConnection).

These issues are all detailed in 
<https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch>. I would 
encourage those participating in this thread to read that document. We 
could always benefit from additional review.

---

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 16 Jul 2015 15:43:07 +0200

On Sat, Jul 11, 2015 at 6:42 PM, Daniel Roesler <[email-masked]> wrote:

> There is now a documented case where a third party on nytimes.com

FYI - The company behind the NY Times IP tracking code turned it off. See
our blog: https://webrtchacks.com/dear-ny-times/#comment-17504

Cheers,
-Victor

---

From: Daniel Roesler <[email-masked]>
Date: Fri, 17 Jul 2015 10:51:53 -0700

> The problem is that those VPNs are misconfigured.

It appears that both built-in L2TP and PPTP VPN options for OSX cannot
be configured to hide the real IP address from WebRTC, even if you
select the option to route all traffic through the VPN[1]. You need to
install an OpenVPN client like Tunnelblick in order to hide your real
IP from WebRTC. As soon as I get some time on a Windows box, I'll
investigate the default behavior there.

[1]: https://i.imgur.com/Hyq1zLz.png

Since this is the behavior for built-in VPN options, and even if you
select the "send all traffic over VPN" setting, I disagree with the
sentiment that it's the user's fault or that the VPN has been
misconfigured. WebRTC should assume default behavior for operating
system VPN behavior and apply additional security steps to protect the
user when the operating system falls short. Blaming the operating
system is no excuse when you know the problem exists and you have the
means to protect the user.

On Mon, Jul 13, 2015 at 11:54 AM, Timothy B. Terriberry
<[email-masked]> wrote:
> encourage those participating in this thread to read that document. We could
> always benefit from additional review.

-------<snip from Section 5.4>-------
   API Requirement:  The API MUST provide a mechanism to allow the JS to
      suppress ICE negotiation (though perhaps to allow candidate
      gathering) until the user has decided to answer the call [note:
      determining when the call has been answered is a question for the
      JS.]  This enables a user to prevent a peer from learning their IP
      address if they elect not to answer a call and also from learning
      whether the user is online.
-------</snip from Section 5.4>-------

I'd like to request that "suppress ICE negotiation (though perhaps to
allow candidate gathering)" be changed to "suppress ICE negotiation
and candidate gathering". That would be enough to require user consent
before local and VPN IP addresses are gathered.

Daniel

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Jul 2015 10:58:03 -0700

> means to protect the user.

Rather than trying to decide who's responsibility this is, I suggest it
would be
more productive to ask whether there's some way for the browser to determine
whether the VPN has been configured in this way. If there is, then I at
least
would be willing to investigate whether it's possible for the browser to
behave differently in these cases.

For starters, I would ask what netstat -rn shows in these cases.

> before local and VPN IP addresses are gathered.

This wouldn't address your issue, because this is under *API* control.
the purpose of this section is not to protect the user from the site but
rather to allow the site to provide privacy features for the user.

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Jul 2015 11:04:45 -0700

> seeding content they don't know they are seeding.
This is already possible using non-WebRTC technologies, e.g. web sockets.
As such, I don't think that permission should be needed to create a data
channel, or receive (but not send) media.

That said, I agree that WebRTC should not allow drive-by harvesting of IP
addresses, and we intend to make changes to Chrome to prevent this.

---

From: Daniel Roesler <[email-masked]>
Date: Fri, 17 Jul 2015 11:22:29 -0700

On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti <[email-masked]> wrote:
>
> This is already possible using non-WebRTC technologies, e.g. web sockets. As
> such, I don't think that permission should be needed to create a data

The big difference is that Web Sockets starts off with an HTTP
request, so it can be filtered by various plugins (PrivacyBadger,
uBlock, Ghostery, etc.). WebRTC is invisible to those services since
it does not have any HTTP requests at all. In fact, is WebRTC the only
browser standard (i.e. not flash) that can fire off a DNS request
that's not (at least at first) for an HTTP address[1]? Lacking an
initial HTTP request makes it impossible for plugins to selectively
filter these requests, so they have to fall back to an all-or-nothing
config setting approach (which hurts WebRTC adoption in
general)[2][3].

> addresses, and we intend to make changes to Chrome to prevent this.

Great to hear! Thanks! Is there a bug that is tracking this?

[1]: https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers
[2]: https://github.com/EFForg/privacybadgerfirefox/issues/394
[3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3

Daniel

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Jul 2015 11:36:14 -0700

The title is somewhat inaccurate, but
https://code.google.com/p/chromium/issues/detail?id=457492 is the current
bug for this.
See also https://code.google.com/p/chromium/issues/detail?id=333752, from
which the above bug was spun out.

On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler <[email-masked]> wrote:

> [1]:
> https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 17 Jul 2015 21:11:32 +0200

If I have understood the looong thread correctly, the issue is that 
Chrome overrides the OS default route and sends the STUN requests via 
all available interfaces, therefore leaking the IP addresses on the process.

AFAIK, that behavior is a Chrome implementation decision (wrong in my 
opinion, but understandable) and it is not specified on WebRTC, so while 
acknowledging the importance of the issue, this is not something that we 
should discuss in this mailing list, except if we decide that we should 
decide to explicitly forbid this behavior and add it to the security draft.

I will send a reply to discuss-webrtc to continue the discussion from a 
Chrome point of view.

Best regards
Sergio

On 17/07/2015 20:36, Justin Uberti wrote:
> https://code.google.com/p/chromium/issues/detail?id=457492 is the 
> current bug for this.
> See also https://code.google.com/p/chromium/issues/detail?id=333752, 
> from which the above bug was spun out.
>
> On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >

---

From: Daniel Roesler <[email-masked]>
Date: Fri, 17 Jul 2015 12:20:00 -0700

On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo
<[email-masked]> wrote:
> If I have understood the looong thread correctly, the issue is that Chrome
> overrides the OS default route and sends the STUN requests via all available
> interfaces, therefore leaking the IP addresses on the process.

Firefox has the same behavior in OSX. So it might also be OSX not
really sending all the traffic through the VPN (like the setting
says).

Would love someone more competent than me to investigate in both OSX
and Windows. I'd be willing to fund VPN subscriptions for them to use
with their research (Private Internet Access supports L2TP, PPTP,
OpenVPN, SOCKS, and they have their own client, but other VPNs are
reported as having their own clients leak the IP, so I'm willing to
fund those, too).

Daniel

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Jul 2015 13:25:57 -0700

What you describe is the proper operation of RFC5245, so this isn't a
Chrome implementation decision (Firefox behaves the same way, and I assume
Edge will as well).

However, we have been thinking about whether refinements to the behaviors
specified in RFC5245 are warranted in the web context.

On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo <
[email-masked]> wrote:

> Chrome overrides the OS default route and sends the STUN requests via all
> available interfaces, therefore leaking the IP addresses on the process.
>
> <https://code.google.com/p/chromium/issues/detail?id=457492>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Jul 2015 21:36:45 +0100

On a related point. I'm not sure it's very compelling but there is
a passing reference in [1] to using WebRTC to discover local IP
addresses as a way of assisting in an attack on rc4 - presumably
the NAT'd source address offers some more known plaintext to an
attacker that can presumably see the WPA encrypted packets and hence
helps speed up the attack. See [1] p12 for the mention, though it
lacks details.

I guess the point is that folks will find unexpected ways to
(ab)use such knowledge once it's available. The right reaction of
course in this case is to not use rc4, but equally it perhaps
provides another example of the unexpected consequences of
exposing addresses.

S.

[1] http://www.rc4nomore.com/vanhoef-usenix2015.pdf

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 17 Jul 2015 23:03:31 +0200

Hi Justin,

Thanks for pointing that out, can you point me were in RFC5245 is that 
behavior described? I fail to find it.

The only references I found about multihoming are about HOST candidates, 
performing connectivity checks and priorization of candidates, but I 
cannot find a reference on sending STUN request to the TURN/STUN server 
via all the available interfaces in order to retrieve the server 
reflexive candidates that is where the leak is originating. Please 
correct me again if I am wrong.

Anyway, this raises another attack vector, as the IP may be leaked not 
directly via the ICE reflexive candidates, but via the connectivity 
checks. That is, the "malicious" server may just not get the IP via the 
server reflexive candidates, but doing an SDP O/A with remote ice 
candidates of a fake ICE server, that correlates the STUN connectivity 
checks with the web visit (via ice username for example).  They don't 
even need a STUN/TURN server deployed.

Best regards
Sergio

On 17/07/2015 22:25, Justin Uberti wrote:
> Chrome implementation decision (Firefox behaves the same way, and I 
> assume Edge will as well).
>
> However, we have been thinking about whether refinements to the 
> behaviors specified in RFC5245 are warranted in the web context.
>
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     If I have understood the looong thread correctly, the issue is
>     that Chrome overrides the OS default route and sends the STUN
>     requests via all available interfaces, therefore leaking the IP
>     addresses on the process.
>
>     AFAIK, that behavior is a Chrome implementation decision (wrong in
>     my opinion, but understandable) and it is not specified on WebRTC,
>     so while acknowledging the importance of the issue, this is not
>     something that we should discuss in this mailing list, except if
>     we decide that we should decide to explicitly forbid this behavior
>     and add it to the security draft.
>
>     I will send a reply to discuss-webrtc to continue the discussion
>     from a Chrome point of view.
>
>     Best regards
>     Sergio
>
>
>>     See also
>>     https://code.google.com/p/chromium/issues/detail?id=333752, from
>>     On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Jul 2015 14:41:34 -0700

On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo <
[email-masked]> wrote:

> performing connectivity checks and priorization of candidates, but I cannot
> find a reference on sending STUN request to the TURN/STUN server via all
> the available interfaces in order to retrieve the server reflexive
> candidates that is where the leak is originating. Please correct me again
> if I am wrong.
>

Section 2.1, paragraphs 2 and 3 talks about getting all interfaces, and
then getting STUN and TURN candidates from said interfaces.

> directly via the ICE reflexive candidates, but via the connectivity checks.
> That is, the "malicious" server may just not get the IP via the server
> reflexive candidates, but doing an SDP O/A with remote ice candidates of a
> fake ICE server, that correlates the STUN connectivity checks with the web
> visit (via ice username for example).  They don't even need a STUN/TURN
> server deployed.
>
> Best regards
> Sergio
>
>
> <[email-masked]>[email-masked]> wrote:
>
>> On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler < <[email-masked]>
>> [email-masked]> wrote:
>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 18 Jul 2015 00:47:41 +0200

On 17/07/2015 23:41, Justin Uberti wrote:
>
>
> On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo 
>     Thanks for pointing that out, can you point me were in RFC5245 is
>     that behavior described? I fail to find it.
>
>     The only references I found about multihoming are about HOST
>     candidates, performing connectivity checks and priorization of
>     candidates, but I cannot find a reference on sending STUN request
>     to the TURN/STUN server via all the available interfaces in order
>     to retrieve the server reflexive candidates that is where the leak
>     is originating. Please correct me again if I am wrong.
>
>
> Section 2.1, paragraphs 2 and 3 talks about getting all interfaces, 
> and then getting STUN and TURN candidates from said interfaces.
>

That was the ones I was looking at, but my understanding of them is 
different:

    If an agent is multihomed, it obtains a candidate from each IP
    address.  Depending on the location of the PEER (the other agent in
    the session) on the IP network relative to the agent, the agent may
    be reachable by the peer through one or more of those IP addresses.
    Consider, for example, an agent that has a local IP address on a
    private net 10 network (I1), and a second connected to the public
    Internet (I2).  A candidate from I1 will be directly reachable when
    communicating with a peer on the same private net 10 network, while a
    candidate from I2 will be directly reachable when communicating with
    a peer on the public Internet.  Rather than trying to guess which IP
    address will work prior to sending an offer, the offering agent
    includes both candidates in its offer.

Here, what I understand is that they are talking about Host ICE candidates, an then, yes, one per interface, no issue here (If my understanding of the leak problem is correct).

    Next, the agent uses STUN or TURN to obtain additional candidates.
    These come in two flavors: translated addresses on the public side of
    a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers
    (RELAYED CANDIDATES).  When TURN servers are utilized, both types of
    candidates are obtained from the TURN server.  If only STUN servers
    are utilized, only server reflexive candidates are obtained from
    them.  The relationship of these candidates to the host candidate is
    shown in Figure 2.  In this figure, both types of candidates are
    discovered using TURN.  In the figure, the notation X:x means IP
    address X and UDP port x.

In this one is talking about getting server reflexive and relay candidates, but in no way I see that the stun server should be contacted by all the interfaces or overriding default routing from OS.

What am I missing?

Best regards
Sergio

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Jul 2015 16:09:56 -0700

> Here, what I understand is that they are talking about Host ICE candidates, an then, yes, one per interface, no issue here (If my understanding of the leak problem is correct).
Agreed.

> In this one is talking about getting server reflexive and relay candidates, but in no way I see that the stun server should be contacted by all the interfaces or overriding default routing from OS.
It is pretty clear from the diagram on page 10 that for each host candidate
X:x, the agent will gather a srflx candidate X1':x1' and relay candidate
Y:y. This is also spelled out in the text underneath the diagram:

   When the agent sends the TURN Allocate request from IP address and
   port X:x, the NAT (assuming there is one) will create a binding
   X1':x1', mapping this server reflexive candidate to the host
   candidate X:x.

Ergo, one tries to gather srflx and relay candidates for each host
candidate X:x.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 18 Jul 2015 01:34:52 +0200

2015-07-18 1:09 GMT+02:00 Justin Uberti <[email-masked]>:
> Ergo, one tries to gather srflx and relay candidates for each host candidate
> X:x.

That's not what I understand.

What I understand is that the browser should bind on 0.0.0.0 (or ::0)
and send the STUN/TURN request, and the underlying OS would decide the
proper interface and source IP. So probably just one or two (IPv4 and
IPv6) STUN/TURN attempts would be performed during the gathering, and
when *that* happens the quoted text above applies (being X the IP of
the candidate matching the source IP chosen by the OS to route the
STUN/TURN request).

Said that, and omitting the above confusing text: what is the purpose
of sending STUN/TURN requests over all the interfaces? How is that
good at all? AFAIK in most cases that will just mean timeouts waiting
for STUN responses (which is bad if trickle ICE is not being used).

To be even more clear: STUN/TURN servers are typically in the public
Internet, although they may also be placed in local networks. Anyhow,
computers within that network have a single and already configured
route to reach the STUN/TURN server (usually the default route).
Sending STUN/TURN requests from other interfaces will just fail.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 18 Jul 2015 01:35:36 +0200

On 18/07/2015 1:09, Justin Uberti wrote:
> It is pretty clear from the diagram on page 10 that for each host 
> candidate X:x, the agent will gather a srflx candidate X1':x1' and 
> relay candidate Y:y. This is also spelled out in the text underneath 
> the diagram:
>

Agree, for each HOST candidate, it should send a STUN request to the 
turn server from that IP:port. But shouldn't the VPN configuration 
prevent the non-VPN-host-candidate STUN request to be sent via the 
non-VPN-interface? (i.e. applying default route based on dest?)

Best regards
Sergio

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Jul 2015 16:41:29 -0700

On Jul 17, 2015 4:35 PM, "Iñaki Baz Castillo" <[email-masked]> wrote:
> and send the STUN/TURN request,

That works most of the time, but it is a cheat. What Chrome and Firefox do
- bind to reach local interface separately - is the only reliable way to do
this. If you bind to 0.0.0.0, you can't handle multiple interfaces
correctly, and that reduces the odds of completing ICE with the best result.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 18 Jul 2015 01:47:47 +0200

2015-07-18 1:41 GMT+02:00 Martin Thomson <[email-masked]>:
> That works most of the time, but it is a cheat. What Chrome and Firefox do -
> bind to reach local interface separately - is the only reliable way to do

If you bind to 0.0.0.0 the OS will find out the proper interface to
send the STUN/TURN request. The browser should then check the chosen
source IP to match the associated local candidate.

>  If you bind to 0.0.0.0, you can't handle multiple interfaces

Any real usecase in which that could be true? Why should the app
override the OS routing table?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Jul 2015 16:56:57 -0700

On Jul 17, 2015 4:48 PM, "Iñaki Baz Castillo" <[email-masked]> wrote:
> send the STUN/TURN request.

No, that's the point, you need control too get this right.

> The browser should then check the chosen

That doesn't always work either. The source address of the packet you send
isn't always reported correctly (not does it necessarily go out the
interface you choose, but that is another problem).

> override the OS routing table?

Which use case? ICE

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 18 Jul 2015 02:00:45 +0200

> interface you choose, but that is another problem).

The point is that you don't even choose the interface. The OS will do for you.

>> override the OS routing table?

I understand we are here discussing how ICE is supposed to work. What
I wonder is: in which case it is useful to send packets to the
STUN/TURN server on all the interfaces instead on relying on the
interface the OS would choose to reach that server?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Jul 2015 17:19:38 -0700

On Fri, Jul 17, 2015 at 4:35 PM, Sergio Garcia Murillo <
[email-masked]> wrote:

>> In this one is talking about getting server reflexive and relay
>> candidates, but in no way I see that the stun server should be contacted by
>> all the interfaces or overriding default routing from OS.
>>
>> candidate X:x, the agent will gather a srflx candidate X1':x1' and relay
>> candidate Y:y. This is also spelled out in the text underneath the diagram:
>>
> Agree, for each HOST candidate, it should send a STUN request to the turn
> server from that IP:port. But shouldn't the VPN configuration prevent the
> non-VPN-host-candidate STUN request to be sent via the non-VPN-interface?
> (i.e. applying default route based on dest?)
>

Replying to Sergio:

Typically with a VPN, the non-VPN interface is locked down so it only has a
single route: to the VPN server. However, split tunnel VPNs allow the
non-VPN interface to route to other addresses (possibly, for performance
reasons), so in this case, the non-VPN-host-candidate STUN request will be
sent successfully from the non-VPN interface.

Sometimes this will be desirable: imagine someone working from home who
wants to connect to their corp VPN, but wants to have their video
conferencing traffic not go through the VPN. Sometimes this will not be
desirable, i.e. when the VPN is being used for privacy. This makes picking
a perfect default setting difficult, although we have some ideas that we
are exploring.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Jul 2015 18:31:29 -0700

> The point is that you don't even choose the interface. The OS will do for
you.

The OS can - and frequently does - get that wrong. The default route can
fail when another might succeed.

You can't allow that to happen if you care about connecting successfully.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 18 Jul 2015 10:19:47 +0200

On 07/17/2015 08:22 PM, Daniel Roesler wrote:
> In fact, is WebRTC the only
> that's not (at least at first) for an HTTP address[1]?

There's also the ftp: URL. And the gopher: URL. And the telnet: URL, if
anyone still remembers that one. In fact, every single URL type that has
an embedded hostname fires off a DNS query.

There is no such thing as a HTTP address. There are only A and AAAA records.
And ws: URLs don't have to point to a server that serves HTTP.

So I'm not sure what the question is really asking, but for all the
interpretations I can come up with that make sense to me, the answer is
"no".

-- 
Surveillance is pervasive. Go Dark.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 18 Jul 2015 10:37:13 +0200

On 18/07/2015 2:19, Justin Uberti wrote:
>
> On Fri, Jul 17, 2015 at 4:35 PM, Sergio Garcia Murillo 
>     Agree, for each HOST candidate, it should send a STUN request to
>     the turn server from that IP:port. But shouldn't the VPN
>     configuration prevent the non-VPN-host-candidate STUN request to
>     be sent via the non-VPN-interface? (i.e. applying default route
>     based on dest?)
>
>
> Replying to Sergio:
>
> Typically with a VPN, the non-VPN interface is locked down so it only 
> has a single route: to the VPN server. However, split tunnel VPNs 
> allow the non-VPN interface to route to other addresses (possibly, for 
> performance reasons), so in this case, the non-VPN-host-candidate STUN 
> request will be sent successfully from the non-VPN interface.
>
> Sometimes this will be desirable: imagine someone working from home 
> who wants to connect to their corp VPN, but wants to have their video 
> conferencing traffic not go through the VPN. Sometimes this will not 
> be desirable, i.e. when the VPN is being used for privacy. This makes 
> picking a perfect default setting difficult, although we have some 
> ideas that we are exploring.

Agree, but IMHO in the case of case of split tunnels, shouldn't that 
issue be solved better if the VPN is configured with the only the routes 
to the corporate system via the VPN and leave the default route for the 
non-VPN-interface for all the other traffic?

You know that I am all for fixing connectivity issues in corp networks 
(my business depends on that!) but in this case I think the privacy of 
non-WebRTC users that has a VPN configured correctly should be more 
important than solving the issues of someone willing to do WebRTC but 
not doing enough to make it work.

Could you share the ideas in the list? As Firefox and Edge might have 
the same behavior (and issues) I think it could be interesting if we can 
get to a good common solution and add it to the security draft (if you 
have not done it already ;)

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 18 Jul 2015 11:00:31 +0200

On 18/07/2015 10:37, Sergio Garcia Murillo wrote:
>> allow the non-VPN interface to route to other addresses (possibly, 
>> for performance reasons), so in this case, the non-VPN-host-candidate 
>> STUN request will be sent successfully from the non-VPN interface.
>>
> issue be solved better if the VPN is configured with the only the 
> routes to the corporate system via the VPN and leave the default route 
> for the non-VPN-interface for all the other traffic?
>
> the same behavior (and issues) I think it could be interesting if we 
> can get to a good common solution and add it to the security draft (if 
> you have not done it already ;)
>

BTW, shouldn't this conversation be crossposted/forwarded to the TRAM 
list as well?

Best regards
Sergio

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 18 Jul 2015 11:22:59 +0200

> You can't allow that to happen if you care about connecting successfully.

Are we talking about ICE gathering and STUN/TURN servers? or are we
talking about p2p ICE connectivity?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 18 Jul 2015 11:31:44 +0200

> sent successfully from the non-VPN interface.

Is that really the most common VNC scenario? Never seen that. I
thought that usually the VNC client adds its own network routes to
reach other users/servers within the same VNC network and leaves the
default route (and others) intact.

My worries are about ICE gathering and the timeout it causes when a
STUN request is sent to the STUN/TURN server from all the local
interfaces. Security/privacy issues (if we consider that leaking all
the host and reflexive addresses is an issue) can happen during ICE
gathering and also when connecting the remote peer.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Sat, 18 Jul 2015 05:38:35 -0400

> You can't allow that to happen if you care about connecting successfully.
Sending data to a particular destination over an interface that is not
supposed to be used based on the local routing is definitely something that
goes against the local policy and should be discouraged. For instance on a
mobile device, not being able to reach a particular STUN/TURN server over
WiFi, should not give the browser an automatic permission to send media
over cell data interface and generate a huge bill for the customer.
Forcibly overwriting default route is something that should need user
consent. I understand that we want the call to succeed in as many cases as
possible, but blindly assuming that the local routing policy exists for no
reason whatsoever is somewhat dangerous.

Would it make sense to use the default route when sending BIND requests to
the STUN/TURN server and ICE connectivity checks? All the host interfaces,
including non-default, should, of cause, be included as targets for remote
connectivity checks. An extra option should enable using non-default
interfaces to send ICE requests and it should only be enabled if user
explicitly agrees to it. Vast majority of users will never need it anyway.

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 18 Jul 2015 12:01:26 +0200

2015-07-18 11:38 GMT+02:00 Roman Shpount <[email-masked]>:
> WiFi, should not give the browser an automatic permission to send media over
> cell data interface and generate a huge bill for the customer. Forcibly
> overwriting default route is something that should need user consent. I
> understand that we want the call to succeed in as many cases as possible,
> but blindly assuming that the local routing policy exists for no reason
> whatsoever is somewhat dangerous.

+1

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Simon Perreault <[email-masked]>
Date: Sat, 18 Jul 2015 16:59:20 -0400

>> whatsoever is somewhat dangerous.

-1

Justin and Martin are right.

This is a concept that was explained during the ICE tutorial that was
presented at IETF 92.

Imagine the following multihomed host with three interfaces:

- Wi-fi interface with default route.
- Wired interface with default route.
- VPN interface with default route.

Which one should you use to talk to the STUN/TURN server? If you bind to
0.0.0.0 then the kernel *will* pick one, but only because it *has to.
All three interfaces are equivalent: they all have a default route and
can a priori be used to talk to the server.

Being multihomed means multiple interfaces with a default route. There's
no "going against the local policy" in this case when sending packets on
any interface.

The point is that in this case, all three interfaces can potentially
yield different server-reflexive candidates, which is why they must be
gathered separately. As for relayed candidates, they also need to be
gathered separately because some interfaces may be faster for talking to
the TURN server and it is useful to compare the candidates gathered on
all 3 interfaces. Also nothing guarantees that you're allowed to reach
the server server on any interface that has a default route, so you need
to try them all.

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 19 Jul 2015 06:06:28 +0000

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Sunday, July 19, 2015 2:29 AM
> To: Iñaki Baz Castillo; Roman Shpount
> Cc: [email-masked]
> Subject: Re: [rtcweb] Please require user consent for data channels
> 
> >> Sending data to a particular destination over an interface that is
> >> not supposed to be used based on the local routing is definitely
> >> something that goes against the local policy and should be
> >> discouraged. For instance on a mobile device, not being able to reach
> >> a particular STUN/TURN server over WiFi, should not give the browser
> >> an automatic permission to send media over cell data interface and
> >> generate a huge bill for the customer. Forcibly overwriting default
> >> route is something that should need user consent. I understand that
> >> we want the call to succeed in as many cases as possible, but blindly
> >> assuming that the local routing policy exists for no reason whatsoever is
> somewhat dangerous.
> >
> > +1
> 
> -1
> 
> This is a concept that was explained during the ICE tutorial that was presented
> at IETF 92.
> 
> All three interfaces are equivalent: they all have a default route and can a priori
> be used to talk to the server.
> 
> Being multihomed means multiple interfaces with a default route. There's no
> "going against the local policy" in this case when sending packets on any
> interface.
> 
> The point is that in this case, all three interfaces can potentially yield different
> server-reflexive candidates, which is why they must be gathered separately. As
> for relayed candidates, they also need to be gathered separately because some
> interfaces may be faster for talking to the TURN server and it is useful to
> compare the candidates gathered on all 3 interfaces. Also nothing guarantees
> that you're allowed to reach the server server on any interface that has a
> default route, so you need to try them all.

This will change in the future with multiple provisioning domains (PVD) defined in MIF WG, new socket API will be provided to allow applications to learn about each PVD and use them separately, and as discussed in https://tools.ietf.org/html/rfc7556#section-6.3 application may not override hard set selected by the user.

-Tiru

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 19 Jul 2015 09:21:16 +0200

> This will change in the future with multiple provisioning domains (PVD) defined in MIF WG, new socket API will be provided to allow applications to learn about each PVD and use them separately, and…
Rule #53 of the IETF: Things will change in the future, including
deployment of just-completed iETF standards, but we don't know when and how.

Solutions we engineer MUST work in the current Internet.

+1 to Simon - the way systems are designed, implemented and deployed
*now*, there may be multiple interfaces with multiple default addresses,
and there's nothing intrinsically illegal, immoral or fattening about an
application accessing them.

(I have personal opinions about the APIs we use to access those
interfaces, only some of which are suitable for repeating in polite
company, but that is a completely different topic.)

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sun, 19 Jul 2015 09:41:59 +0200

Most probably you already have thought about it, but how about adding an
interface black/white list for webrtc in privacy settings? IIRC chrome was
already skipping some hardcoded virtual interface names.

Best regards
Sergio

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jul 2015 13:43:10 +0200

2015-07-20 13:37 GMT+02:00 Tim Panton <[email-masked]>:

> E.g. I’m at home and my chromebook pixel (or firefox tablet) is on wifi,
> but I’ve left LTE enabled.
> I (or the OS) is configured to prefer wifi wen available - but it happens
> that for a specific peer LTE completes first.
> So now my video call goes over LTE without my say-so and with no hint this
> is happening  - costing me real
> money. My only option is to completely disable LTE when I get home  (and
> lose SMS too) ?
>

Exactly.

Setting the default network route should be enough to avoid that and to
ensure a global network policy for the whole OS, unless an app (the
browser) plays to be God.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Mon, 20 Jul 2015 13:26:00 +0100

> On 18 Jul 2015, at 02:31, Martin Thomson <[email-masked]> wrote:
> 
> 
> On Jul 17, 2015 5:01 PM, "Iñaki Baz Castillo" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> The OS can - and frequently does - get that wrong. The default route can fail when another might succeed.
> 
Gulp. Whilst I mostly see the logic - it is wholly unexpected behaviour to the average sys admin. 
Certainly not what I expected.

It strikes me that binding to all interfaces might well give a vector for attackers to map out a company’s internal networks.
It also may restrict the user’s ability to manipulate which medium is used. 

E.g. I’m at home and my chromebook pixel (or firefox tablet) is on wifi, but I’ve left LTE enabled.
I (or the OS) is configured to prefer wifi wen available - but it happens that for a specific peer LTE completes first.
So now my video call goes over LTE without my say-so and with no hint this is happening  - costing me real
money. My only option is to completely disable LTE when I get home  (and lose SMS too) ?

Perhaps we should default to binding to 0.0.0.0 and allow a user config’d preference for more exhaustive searching.

Tim.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Jul 2015 14:32:52 +0200

> Certainly not what I expected.

I don't know how you can expect ICE to work otherwise.

> It strikes me that binding to all interfaces might well give a vector
> for attackers to map out a company’s internal networks.

You are sending your IP address(es) as payload so that your peer may
connect to them. We've been doing this in various protocols for ages.
Just take FTP for example, where data and signalling are separate. How
is any of this different?

> I (or the OS) is configured to prefer wifi wen available - but it
> happens that for a specific peer LTE completes first.

That is a valid concern, and the answer to it is MIF.

Simon

---

From: Tim Panton <[email-masked]>
Date: Mon, 20 Jul 2015 13:58:47 +0100

> On 20 Jul 2015, at 13:32, Simon Perreault <[email-masked]> wrote:
> 

I’d hardly take FTP as a model citizen :-)

But what is different is that we have removed _all_ the sysadmin’s levers
to prevent mapping of internal address spaces.

If I understand correctly we bind to each and every interface
that is up and send out packets to all remote candidates down _every_ interface,
ignoring any preferences set by the admin in the local routing table which
were set to ensure (say) only critical traffic is sent down certain interfaces.

I can think of some financial institutions who’s IDSs will go off when packets
to public external addresses start turning up on internal LANS . (hopefully they 
will get dropped at the egress router, but by then the IDS will have paged someone).

Likewise my fantastically expensive BGAN link which is used for
emergencies only will suddenly start carrying STUN requests irrespective of how I configure my
routes ?

> That is a valid concern, and the answer to it is MIF.

And in the meanwhile ?

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jul 2015 15:13:05 +0200

> I don't know how you can expect ICE to work otherwise.

It would just work. The STUN/TURN server should be reachable using the OS
configured routes, isn't it?

Please, don't argument that "otherwise it would not work" because that is
not true at all.

> connect to them.

The fact that the client announces its (probably) private VPN addresses to
the remote peer does not mean that it also reveals the associated public
reflexive IP. That just happens if the client performs STUN procedures over
that interface, which is exactly the issue being discussed (at least right
now).

> We've been doing this in various protocols for ages.

The FTP client does not override the OS routes but instead contacts both
the FTP signaling address and the FTP data address using the OS configured
routes (rather than forcing local interfaces to reach them). So yes, it is
fully different IMHO.

> That is a valid concern, and the answer to it is MIF.

Sorry, what does MIF stand for?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Jul 2015 15:26:48 +0200

> were set to ensure (say) only critical traffic is sent down certain interfaces.

I have difficulty understanding what it is that's bugging you. Is it the
signalling payload (i.e., sending the list of address), or is it the
connectivity checks that are done on all candidate pairs?

> will get dropped at the egress router, but by then the IDS will have paged someone).

But that's not going to happen unless there's a route. I think there
could be a misunderstanding here. For example, if there's a VPN with a
10.0.0.0/8 route but no default route, the ICE client will *not* send a
request to a TURN server listening on 192.0.2.1 over the VPN interface.
That would make no sense whatsoever.

> emergencies only will suddenly start carrying STUN requests irrespective of how I configure my

Only if it's possible to route the packet to the STUN server over the
BGAN link. There must be a route.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Jul 2015 15:32:48 +0200

Le 2015-07-20 15:13, Iñaki Baz Castillo a écrit :
> It would just work. The STUN/TURN server should be reachable using the
> OS configured routes, isn't it?

I have no idea what you're talking about. Yes there must be a route. But
that's completely orthogonal to which interface you're binding to.

> Please, don't argument that "otherwise it would not work" because that
> is not true at all.

It is. But I'm not sure we're talking about the same "it" anymore.

> The fact that the client announces its (probably) private VPN addresses
> to the remote peer does not mean that it also reveals the associated
> public reflexive IP. That just happens if the client performs STUN
> procedures over that interface, which is exactly the issue being
> discussed (at least right now).

If you can find a server-reflexive candidate on the VPN interface, it
means you can talk to the Internet using that interface, using that
server-reflexive IP address. How is that private knowledge at all? How
do you expect to keep your server-reflexive address private but still
use it for communication?

> the FTP signaling address and the FTP data address using the OS
> configured routes (rather than forcing local interfaces to reach them).
> So yes, it is fully different IMHO.

The routing table is *not* overridden by explicitly binding to an interface.

> Sorry, what does MIF stand for?

https://datatracker.ietf.org/wg/mif/documents/

The MIF WG is working on exactly this kind of problem. They are
developing an API for solving precisely this kind of interface
preference problem. IMHO ICE could perhaps be extended to make use of
this API. But I see it as "just" an enhancement.

Simon

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jul 2015 15:45:03 +0200

> connectivity checks that are done on all candidate pairs?

Unfortunately we are mixing two probably separate concerns:

1) ICE gathering and possible sensitive IP leak when connecting the
STUN/TURN server (decided by the web app) from all the interfaces (those
that of course have a route to the server).

2) Same issue when the IPs are announced in the SDP and ICE connectivity
checks with the remote peer are performed.

We should focus :)

> BGAN link. There must be a route.

 Yes, but the point is that one may have enabled a secondary route (a
default route via eth2) but prefer to use another route as default (eth1).
The browser will not respect that because it will try both eth1 and eth2.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Mon, 20 Jul 2015 14:45:32 +0100

> On 20 Jul 2015, at 14:26, Simon Perreault <[email-masked]> wrote:
> 

I’m not worried about the signalling payload (i.e. the list of local interface addresses - 
except of course the mac-based ipv6 auto conf one).
I am worried about what can be learnt from /caused by sending packets down interfaces
when the sysadmin isn’t expecting it.

(In the end some of those learnings may end up in signalling as candidates too).

> That would make no sense whatsoever.

And yet that’s what I read Martin to say : 
"> The point is that you don't even choose the interface. The OS will do for you.
The OS can - and frequently does - get that wrong. The default route can fail when another might succeed."

I read that as 'another interface’ - but if he means  ‘another route’ then I’m happier - I think.
Can @justin or @martin confirm what the browsers currently do ?

> BGAN link. There must be a route.

There must be a _locally_ configured route - It doesn’t matter if the egress router at the far end of the BGAN drops 
the STUN packet I’ve still wasted my money :-(

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jul 2015 15:51:02 +0200

> use it for communication?

Ok, let's simplify this subject:

- Computer with two default routes (A and B) and a private network route
(C).
- A is the preferred default route one so has priority in the routing table.
- Every packet whose destination is not C network should be sent over A.
...
- or not? should a specific app override it?

 This seems more a moral issue.

> The routing table is *not* overridden by explicitly binding to an

I meant "using a secondary default route". Sorry for the confusion.

> this API. But I see it as "just" an enhancement.

Good to know. Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jul 2015 15:56:10 +0200

2015-07-20 15:45 GMT+02:00 Tim Panton <[email-masked]>:

> fail when another might succeed."
>

I can confirm (OSX) that during ICE gathering STUN requests to the STUN
server are not sent over interfaces not belonging to any network route that
can reach the STUN/TURN server. This is, network routes are "respected".
The issue is that all the existing routes capables of reaching the STUN
server are tested (instead of the first one).

Note that we should avoid the term "default route" here as it stands for
0.0.0.0. It may happen that the webrtc app uses a private STUN server which
is just reachable via a VPN interface (and its specific route to reach the
VPN network in which the STUN server is placed) so in this case the default
route should not be tested because there is a route with higher priority to
reach the server.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Jul 2015 16:00:30 +0200

Just to be sure I am not going crazy, I just wrote this test:

> #include <sys/socket.h>
> #include <sys/types.h>
> 
> #include <netinet/in.h>
> #include <string.h>
> 
> int
> main(int argc, char *argv[])
> {
>         int                      s;
>         struct sockaddr_in       sin;
>         char                     foo[] = "bar";
> 
>         s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
> 
>         sin.sin_family = AF_INET;
>         sin.sin_addr.s_addr = inet_addr("192.168.2.128");
>         sin.sin_port = htons(1234);
>         memset(&sin.sin_zero, 0, sizeof(sin.sin_zero));
>         bind(s, (struct sockaddr *)&sin, sizeof(sin));
> 
>         sin.sin_family = AF_INET;
>         sin.sin_addr.s_addr = inet_addr("192.168.2.200");
>         sin.sin_port = htons(53);
>         memset(&sin.sin_zero, 0, sizeof(sin.sin_zero));
>         sendto(s, foo, sizeof(foo), 0, (struct sockaddr *)&sin, sizeof(sin));
> 
>         sin.sin_family = AF_INET;
>         sin.sin_addr.s_addr = inet_addr("8.8.8.8");
>         sin.sin_port = htons(53);
>         memset(&sin.sin_zero, 0, sizeof(sin.sin_zero));
>         sendto(s, foo, sizeof(foo), 0, (struct sockaddr *)&sin, sizeof(sin));
> 
>         return (0);
> }

I ran it on this system:

> sperreault@debian:~$ ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>     link/ether 00:0c:29:66:b9:2c brd ff:ff:ff:ff:ff:ff
>     inet 192.168.2.128/24 brd 192.168.2.255 scope global eth0
>     inet6 fe80::20c:29ff:fe66:b92c/64 scope link
>        valid_lft forever preferred_lft forever
> sperreault@debian:~$ ip r
> 192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.128
> sperreault@debian:~$

Strace's output is:

> bind(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("192.168.2.128")}, 16) = 0
> sendto(3, "bar\0", 4, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.2.200")}, 16) = 4
> sendto(3, "bar\0", 4, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16) = -1 ENETUNREACH (Network is unreachable)

This confirms that bind() does not override the routing table.

Simon

---

From: Daniel Roesler <[email-masked]>
Date: Mon, 20 Jul 2015 07:08:14 -0700

A gentle reminder to stop referring to this as a "possible" sensitive IP
leak. It *is currently* a sensitive IP leak, and is already being exploited
in the wild[1].

[1]: https://webrtchacks.com/dear-ny-times/

Daniel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jul 2015 16:09:27 +0200

2015-07-20 16:00 GMT+02:00 Simon Perreault <[email-masked]>:

> > bind(3, {sa_family=AF_INET, sin_port=htons(1234),
> sin_addr=inet_addr("192.168.2.128")}, 16) = 0
> > sendto(3, "bar\0", 4, 0, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("192.168.2.200")}, 16) = 4
> > sendto(3, "bar\0", 4, 0, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("8.8.8.8")}, 16) = -1 ENETUNREACH (Network is
> unreachable)
>

Yes sure, I also confirmed that with some traces when Chrome performs ICE
gathering having my OSX computer a VPN interface with no route to reach the
STUN server.

So we are talking about whether the browser should just try the OS
preferred route capable of reaching the STUN server or all the capable ones.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jul 2015 16:11:19 +0200

> [1]: https://webrtchacks.com/dear-ny-times/

I just added "possible" because that is the original subject discussed in
this thread, and I didn't want to take part on it :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Jul 2015 16:14:08 +0200

> preferred route capable of reaching the STUN server or all the capable ones.

Correct. Thanks for re-focusing the discussion.

As for this precise question, I don't have an opinion. My intuition is
it would perhaps make sense to reflect routing priorities into ICE
prioritization or nomination criteria. But that would be very
implementation-specific.

Simon

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 Jul 2015 10:16:00 -0400

Just to be completely clear, we are talking about the metric parameter in
the route. If I set a lower metric on the route to some destination (or if
OS sets a lower metric on the route to some destination), I expect this
route to be used. On some operating systems, this can be overwritten by
explicitly binding to a particular IP address (interface). This breaks
things and is somewhat unexpected to the system administrator. This is also
something that only happens in case of ICE. No other browser based protocol
would send data over a route with higher metric.

Regards,
_____________
Roman Shpount

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 20 Jul 2015 14:34:18 +0000

On Jul 20, 2015, at 4:16 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

Just to be completely clear, we are talking about the metric parameter in the route. If I set a lower metric on the route to some destination (or if OS sets a lower metric on the route to some destination), I expect this route to be used. On some operating systems, this can be overwritten by explicitly binding to a particular IP address (interface). This breaks things and is somewhat unexpected to the system administrator. This is also something that only happens in case of ICE. No other browser based protocol would send data over a route with higher metric.

https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension

Apple has announced that their HTTP client implementation will do (something like) this in iOS 9, to solve the “Parking lot WiFi” problem.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 Jul 2015 10:28:59 -0400

> - VPN interface with default route.

On the multihomed host, all the default routes will have different metrics.
In some cases these metrics are automatically calculated by OS. In some
cases, they are set by the system administrator. In either case, ICE
ignores the metric value and tries to route over all interfaces. This is
unexpected and can be considered a violation of the local policy (i.e. if
administrator added a route with a lower metric, it expects it to be used).
No other browser protocol does this.

> can a priori be used to talk to the server.

See above, this is not the case. All interfaces have a default route but
they are not equal. If they were equal, OS will round robin among them.

> no "going against the local policy" in this case when sending packets on

Once again, this is not the case. Metric value on the interface is local
policy and should be respected.

> the server server on any interface that has a default route, so you need

This is a policy decision on the local computer. As a network administrator
I should be able to specified the preferred default route. It does not mean
that I should remove the default routes for all the other interfaces.
Setting a metric should be enough. On the other hand, if I prefer the
browser to pick the best connection on its own, I should be able to allow
this as well, but this is going to be a much less common case. Taking into
account potential privacy or financial implications of this choice, I think
the browser should error on the side of caution.

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 20 Jul 2015 10:49:59 -0400

> Solutions we engineer MUST work in the current Internet.

I agree completely.

> application accessing them.

If a local system administrator set a lower metric to a particular default
(or any other route) vs all the other routes to a certain destination, this
route should be used to reach this destination. This is the normal behavior
for all other network communications from the browser (HTTP. WebSockets, or
even FTP or gopher). With ICE, browsers depart from this model. I
understand that this can enable browsers to set up a WebRTC media
connection where it would not be able to do so otherwise. On other hand
using secondary routes can produce some unexpected results, such as
exposing reflexive addresses on secondary interfaces or sending data over
LTE network when WiFi is available. I think using secondary routes should
only be enabled after user consent or if an appropriate browser setting is
enabled. In wast majority of cases, primary default route is sufficient to
set up the WebRTC connection. My assumption is that using secondary default
routes only improves the chances of connection in extremely small number of
cases. Based on the systems I have worked with, we are talking about less
then 1/10 of the percent of end users.

Regards,
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jul 2015 16:58:33 +0200

> then 1/10 of the percent of end users.

Agreed. Important concerns here are:

1) The app (browser) should respect the routing local policy. It means that
it should consider the metric/priority of the capable routes (as the
administrator or OS decided), or that it should just use the best one (but
this may also cause issues as stated in next bullet).

2) If the browser also uses a secondary capable route it may cause real money
(if for example the secondary route goes through a LTE interface while the
primary route is WiFi based).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Mon, 20 Jul 2015 12:37:15 +0100

> On 18 Jul 2015, at 00:41, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Jul 17, 2015 4:35 PM, "Iñaki Baz Castillo" <[email-masked] <mailto:[email-masked]>> wrote:
> That works most of the time, but it is a cheat. What Chrome and Firefox do - bind to reach local interface separately - is the only reliable way to do this. If you bind to 0.0.0.0, you can't handle multiple interfaces correctly, and that reduces the odds of completing ICE with the best result.
> 
> 

Tim.

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk <http://www.westhawk.co.uk/>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 27 Jul 2015 12:02:01 -0700

> browser) plays to be God.
​So, the work of MIF got mentioned during the IETF WG meeting, but I'm not
sure that folks have its coordinates; just in case, the documents are all
here:

http://datatracker.ietf.org/wg/mif/documents/

It's the right IETF venue to discuss the general question of how to manage
multiple interfaces.

regards,

Ted​

---

From: Roman Shpount <[email-masked]>
Date: Mon, 27 Jul 2015 15:09:30 -0400

> It's the right IETF venue to discuss the general question of how to manage
Is this the right venue to discuss how ICE should handle multiple
interfaces as well?
_____________
Roman Shpount

---

From: Ted Hardie <[email-masked]>
Date: Mon, 27 Jul 2015 12:27:06 -0700

On Mon, Jul 27, 2015 at 12:09 PM, Roman Shpount <[email-masked]> wrote:

>> ​So, the work of MIF got mentioned during the IETF WG meeting, but I'm
>> not sure that folks have its coordinates; just in case, the documents are
>> all here:
>>
>> It's the right IETF venue to discuss the general question of how to
>> manage multiple interfaces.
>>
>>
​
I don't think that question has enough detail to answer.  For ICE, the
current theory is questions on what ICE does with the interface information
it has go to MMUSIC, though that may get updated to a dedicated group.  MIF
would be for discussing what interface states get surfaced and when.

(Other views of this are possible, of course, and your mileage may vary
when posting).

Ted

---

From: Randell Jesup <[email-masked]>
Date: Thu, 30 Jul 2015 02:32:35 -0400

Note: responding to an older message. Also, Mozilla is planning to land 
a number of optional controls for ICE candidate generation and TURN 
server use.  We also plan to add hooks that extensions can use to prompt 
(depending on circumstance) or monitor 'background' use of 
PeerConnections (without user-granted permission).

> much in the thread, but I think it's one of the most important issues.

In addition to Kaufman's answer, I'll add that this would effectively 
make WebRTC unusable for users - and/or would destroy the utility of 
camera access requests (and WebRTC), due to user request-fatigue.  (If 
you ask a user for permission too many times, especially for something 
they asked to do and the question is about something they don't really 
understand, they either a) always hit yes regardless of the question, or 
b) stop using the feature entirely, because it's too annoying.)

Even camera-access requests are arguably a problem - but the alternative 
(granting permanent permission by default) is itself problematic.

> potentially "real" ISP) IP addresses.

Sure, and gathering those for normal users is already trivially possible 
*without* webrtc - external IP's are trivial: whatismyipaddress.com, and 
for LAN addresses you can infer the LAN address with high probability by 
trying to load images from likely gateway addresses 
(192.168.0.1/192.168.1.1/10.0.0.1/etc) to find the likely subnet, and 
then scan the subnet using the same trick, recording the time-to-fail 
for each.  That will map the entire list of devices on the LAN, and you 
may be able to infer from it which address is yours (probably the 
fastest failure).  Note the LAN map itself is often a larger fingerprint 
reveal than the LAN IP address alone.  And yes, I've seen real examples 
of these tricks.

The case this doesn't directly cover fully is the "partial VPN" case, 
where someone has a VPN, but *also* still allows routing out directly 
without going through the VPN.  This is already hugely risky if you're 
trying to maintain anonymity - it's a false sense of security.  However 
it is at least a real concern, as is the "hiding at a shelter" case 
discussed a long time ago, where the issue is exposing external IP's to 
a remote caller (not to the service provider or STUN/TURN server).  I 
will note that there are many ways someone can find your external IP 
address unless you're very paranoid and careful (never load images in 
email, etc).

> just like they have to get consent on getUserMedia.

You could disable DataChannels and have the same problem, note - this 
would have to apply to all PeerConnections (think of a call with 
offerToReceiveAudio - no gUM request would be made).

> consent requirements just like P2P video and voice connections.

They are.

> In addition to the silent third party local IP tracking, a silent P2P

Note we don't require permissions to open WebSockets either.  While 
those don't allow P2P access, downloaded JS can use your CPU for bitcoin 
mining (though not efficiently yet), SETI searches, can store data and 
serve it back to the same (or other) servers, etc.

> 3. If there's no previous gUM consent, then ask the user for consent.

This could be done technically, and would cover the 
offerToReceiveAudio/Video case.  And there are still ways this could be 
abused, though not as easily.

It would cause people using WebRTC for the advantages DataChannels has 
over WebSockets to be annoyed (such as games).  Anything that benefits 
from UDP-like semantics has cause to use WebRTC/DataChannels, even if 
it's just talking directly to the server, and this would put a huge 
roadblock in the face of such utility.   Web-based games are starting to 
make use of DataChannels, and this would be a real problem for them.

Working around this for access back to the server would require some 
variant of CORS (to bypass the request if it's back to the same origin 
you loaded the page from - and that means you'd make it trivial again 
for the site to find your IPs, which was the reason this was brought 
up).  So that's not really useful.

One thing that *could* be done is to create an option to force such 
requests; we can debate what the visibility of such an option should be, 
and what the defaults should be - but a designed-in option opens the 
door for trivial extensions to change the or to provide UI to expose it 
(either in prefs or in main browser chrome or in a modal popup).  We 
could also flip the pref by default in private browsing mode, though 
that might require in-browser UI since random sites may trigger it.

Speaking to the non-fingerprinting aspects of this which had previously 
been discussed:

I understand your concerns, however the IP address exposure and LAN 
exposure is a red herring (and even more so in IPV6 world), except for 
the "I'm hiding" cases (poorly-configured VPN hiding or hiding from 
another user of the service).  We do surface the ability to not only 
know what PeerConnections are in use, but also that have been in use, so 
you can vet if sites are actually making connections. Right now it 
doesn't list unconnected PeerConnections (used for IP address 
harvesting), but it could.

One could also provide some sort of semi-persistent indicator of such 
background usage without requiring the user to interact with it.  (See 
the hooks I mention at the top of this post.)

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't [email-masked]!  Way too much spam

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 Jul 2015 15:26:44 -0400

Hi Randell,

I do agree with most of your argument regarding fingerprinting and gUM. I
also agree that this is not just the data channel issue and similar
exploits can be created using audio or video connections. Furthermore,
these usage patterns are very difficult to distinguish from legitimate
applications. On the other hand I would argue that all of this exploits do
not matter, since you can get the same information using non webrtc related
HTML functionality.

One thing that I do not agree with is that PeerConnection introduced a
significant new behavior -- routing data over the non-default network
interface. This is something that was not possible before. There is no way
to overwrite default routing with HTTP request or anything similar
generated by the browser. Overwriting default routing would allow creation
of a whole new class of exploits, from determining user other IP addresses
to forcing traffic over unexpected networks and generating expenses for the
 user. My suggestion is that until system wide preferences are exposed via
some other mechanism defined by MIF, web browser should follow the local
policy and do not overwrite local routing metrics by sending ICE requests
over specific interfaces. At the very least, this should only be enabled
via some sort of configuration option which should be disabled by default.
I understand that using only default routes can decrease the chances of
connection, but from my experience* we are talking about less then 0.1% of
all the users.

Also, please note that a lot of software VPNs do allow routing over
secondary gateways. There is nothing fake or unusual about them. For
instance Microsoft default PPTP VPN simply creates a virtual adapter for
the VPN connection and creates a route with lower metric. This virtual
adapter, on the other hand is using the previous default route for PPTP
connection.

* We have deployed a VoIP system with 500K users that used ICE in
combination with TURNs over default route with HTTP connect option. Total
number of users who could not place a call even though they could connect
to the web server was less then 0.1%.
_____________
Roman Shpount