Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios

From: James Pearce <[email-masked]>
Date: Wed, 23 Aug 2017 22:06:08 +0100

Please forgive me if I abused the process in any way - this is my first contribution to a mailing list such as this.

I am the submitter of the original Mozilla bug identifying this corner case mentioned by Byron. (I hesitate to call it as such because the impact has been significant to our particular WebRTC use case). I'd like to attempt to make my case...

I think there are both usability and privacy issues that need to be considered here. 

In my particular case, the remote peer is on a VPN. The VPN is not installed as the default route (common for corporate and organisational VPNs). Only the remote peer is supplying media. This might seem an unusual setup, but I think this kind of use will grow as the benefits of very-low latency media streaming become more important. With no media to contribute, the local peer never calls gUM. As both peers are on a VPN, and gUM is never called, the connection fails outright, since the connection falls back to mode 2, but the VPN is not the default route - there is no opportunity to ever obtain user permission.

Perhaps more importantly there is a privacy concern as well. As I understand it, the purpose of mode 2 is to prevent drive-by enumerations of addresses of alternative routes that should remain private. The assumption seems to be that the address of the default route is safe to reveal. However, where the origin came via a non-default route, it seems like an unsafe assumption. As a contrived example, if I'm a corporate whistleblower, I don't want the external address of my default route revealed to my employer when I'm using my corporate VPN. However as the spec is currently worded, it allows just that.

The obvious solution seems to be to change the behaviour of mode 2. Rather than using the default route in all cases, we should use the route that was used to fetch the origin. This seems to resolve both the usability and privacy concerns without reducing existing security.

Thanks for listening,

James

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 23 Aug 2017 15:36:03 -0700

I agree. This would be consistent with the spirit of the guidelines: "don't
reveal any more IP addresses than have already been revealed." This may
have even been the intent from the start; there's just not a clear
definition for "default route". "Default route used to fetch the origin"
seems like a reasonable definition.

Justin, do you recall if this has been brought up before? Do you have any
opinions?

On Wed, Aug 23, 2017 at 2:06 PM, James Pearce <[email-masked]> wrote:

> Please forgive me if I abused the process in any way - this is my first
> contribution to a mailing list such as this.
>
> I am the submitter of the original Mozilla bug identifying this corner
> case mentioned by Byron. (I hesitate to call it as such because the impact
> has been significant to our particular WebRTC use case). I'd like to
> attempt to make my case...
>
> In my particular case, the remote peer is on a VPN. The VPN is not
> installed as the default route (common for corporate and organisational
> VPNs). Only the remote peer is supplying media. This might seem an unusual
> setup, but I think this kind of use will grow as the benefits of very-low
> latency media streaming become more important. With no media to contribute,
> the local peer never calls gUM. As both peers are on a VPN, and gUM is
> never called, the connection fails outright, since the connection falls
> back to mode 2, but the VPN is not the default route - there is no
> opportunity to ever obtain user permission.
>
> Perhaps more importantly there is a privacy concern as well. As I
> understand it, the purpose of mode 2 is to prevent drive-by enumerations of
> addresses of alternative routes that should remain private. The assumption
> seems to be that the address of the default route is safe to reveal.
> However, where the origin came via a non-default route, it seems like an
> unsafe assumption. As a contrived example, if I'm a corporate
> whistleblower, I don't want the external address of my default route
> revealed to my employer when I'm using my corporate VPN. However as the
> spec is currently worded, it allows just that.
>
> The obvious solution seems to be to change the behaviour of mode 2. Rather
> than using the default route in all cases, we should use the route that was
> used to fetch the origin. This seems to resolve both the usability and
> privacy concerns without reducing existing security.
>
> Thanks for listening,
>
> James
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Byron Campen <[email-masked]>
Date: Wed, 23 Aug 2017 19:08:18 -0500

I suppose that if the non-default route is being used, and there's 
a NAT in the way, you would be revealing information that the webserver 
didn't already have. But that has always been the case with mode 2.

     Another worthwhile question to ask: what if you're connecting to 
the origin via a proxy? Should that effect mode 2? Or maybe even be a 
different mode?

Best regards,
Byron Campen

On 8/23/17 5:36 PM, Taylor Brandstetter wrote:
> I agree. This would be consistent with the spirit of the guidelines: 
> "don't reveal any more IP addresses than have already been revealed." 
> This may have even been the intent from the start; there's just not a 
> clear definition for "default route". "Default route used to fetch the 
> origin" seems like a reasonable definition.
>
> Justin, do you recall if this has been brought up before? Do you have 
> any opinions?
>
> On Wed, Aug 23, 2017 at 2:06 PM, James Pearce <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Please forgive me if I abused the process in any way - this is my
>     first contribution to a mailing list such as this.
>
>     I am the submitter of the original Mozilla bug identifying this
>     corner case mentioned by Byron. (I hesitate to call it as such
>     because the impact has been significant to our particular WebRTC
>     use case). I'd like to attempt to make my case...
>
>     installed as the default route (common for corporate and
>     organisational VPNs). Only the remote peer is supplying media.
>     This might seem an unusual setup, but I think this kind of use
>     will grow as the benefits of very-low latency media streaming
>     become more important. With no media to contribute, the local peer
>     never calls gUM. As both peers are on a VPN, and gUM is never
>     called, the connection fails outright, since the connection falls
>     understand it, the purpose of mode 2 is to prevent drive-by
>     enumerations of addresses of alternative routes that should remain
>     private. The assumption seems to be that the address of the
>     default route is safe to reveal. However, where the origin came
>     via a non-default route, it seems like an unsafe assumption. As a
>     contrived example, if I'm a corporate whistleblower, I don't want
>     the external address of my default route revealed to my employer
>     when I'm using my corporate VPN. However as the spec is currently
>     worded, it allows just that.
>
>     The obvious solution seems to be to change the behaviour of mode
>     2. Rather than using the default route in all cases, we should use
>     the route that was used to fetch the origin. This seems to resolve
>     both the usability and privacy concerns without reducing existing
>     security.
>
>     Thanks for listening,
>
>     James
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 23 Aug 2017 18:53:56 -0700

This is the first time I've heard this case discussed. I assume the basic
issue is that you want to use the same interface to connect to the remote
endpoint as was used to load the page, even when the default route would
have caused you to use a different interface?

While the suggested solution seems reasonable, this may not always be
possible (e.g., if you don't have access to the origin IP). Also, I think
any public addresses associated with the default route will already be
discoverable via other mechanisms, e.g. XHR (as Byron mentioned above).

On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen <[email-masked]> wrote:

>     I suppose that if the non-default route is being used, and there's a
> NAT in the way, you would be revealing information that the webserver
>     Another worthwhile question to ask: what if you're connecting to the
> origin via a proxy? Should that effect mode 2? Or maybe even be a different
> mode?
>
> Best regards,
> Byron Campen
>
>
> "don't reveal any more IP addresses than have already been revealed." This
> may have even been the intent from the start; there's just not a clear
>> The obvious solution seems to be to change the behaviour of mode 2.
>> Rather than using the default route in all cases, we should use the route
>> that was used to fetch the origin. This seems to resolve both the usability
>> and privacy concerns without reducing existing security.
>>
>> Thanks for listening,
>>
>> James
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: James Pearce <[email-masked]>
Date: Thu, 24 Aug 2017 08:29:57 +0100

Yes, I guess it's true that you could use XHR to discover the default route's public addresses. I suppose the only difference is that it requires a bit more effort - a site that is CORS enabled that actually gathers those addresses. In those cases, a concerned individual might have taken other precautions.

Even if the privacy concern isn't actually a significant issue (personally I think it is), there are still usability issues I think need addressing.

In what cases would the origin IP not be available? In those cases would it be safe to fall back to the default route?

James

> On 24 Aug 2017, at 02:53, Justin Uberti <[email-masked]> wrote:
> 
> This is the first time I've heard this case discussed. I assume the basic issue is that you want to use the same interface to connect to the remote endpoint as was used to load the page, even when the default route would have caused you to use a different interface?
> 
> While the suggested solution seems reasonable, this may not always be possible (e.g., if you don't have access to the origin IP). Also, I think any public addresses associated with the default route will already be discoverable via other mechanisms, e.g. XHR (as Byron mentioned above).
> 
> 
>>     I suppose that if the non-default route is being used, and there's a NAT in the way, you would be revealing information that the webserver didn't already have. But that has always been the case with mode 2.
>> 
>>     Another worthwhile question to ask: what if you're connecting to the origin via a proxy? Should that effect mode 2? Or maybe even be a different mode?
>> 
>> Best regards,
>> Byron Campen
>> 
>> 
>>> I agree. This would be consistent with the spirit of the guidelines: "don't reveal any more IP addresses than have already been revealed." This may have even been the intent from the start; there's just not a clear definition for "default route". "Default route used to fetch the origin" seems like a reasonable definition.
>>> 
>>> Justin, do you recall if this has been brought up before? Do you have any opinions?
>>>

---

From: Byron Campen <[email-masked]>
Date: Thu, 24 Aug 2017 09:12:49 -0500

On 8/24/17 2:29 AM, James Pearce wrote:
> Yes, I guess it's true that you could use XHR to discover the default 
> route's public addresses. I suppose the only difference is that it 
> requires a bit more effort - a site that is CORS enabled that actually 
> gathers those addresses. In those cases, a concerned individual might 
> have taken other precautions.
    So, I guess we could consider a scenario where the machine does not 
have internet access at all, and there's something nefarious going on in 
the private network? Seems kinda out of scope for fingerprinting 
attacks, honestly.

>
> Even if the privacy concern isn't actually a significant issue 
> (personally I think it is), there are still usability issues I think 
> need addressing.
>
> In what cases would the origin IP not be available? In those cases 
> would it be safe to fall back to the default route?
    If you're using an http proxy, this would be the case. I think it 
would be reasonable to fall back to the default route here. Another case 
might be when you're using a file instead of a web server.

Best regards,
Byron Campen

> On 24 Aug 2017, at 02:53, Justin Uberti <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> This is the first time I've heard this case discussed. I assume the 
>> basic issue is that you want to use the same interface to connect to 
>> the remote endpoint as was used to load the page, even when the 
>> default route would have caused you to use a different interface?
>>
>> possible (e.g., if you don't have access to the origin IP). Also, I 
>> think any public addresses associated with the default route will 
>> already be discoverable via other mechanisms, e.g. XHR (as Byron 
>> mentioned above).
>>
>>
>> On Wed, Aug 23, 2017 at 5:08 PM, Byron Campen <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     I suppose that if the non-default route is being used, and
>>     there's a NAT in the way, you would be revealing information that
>>     the webserver didn't already have. But that has always been the
>>     case with mode 2.
>>
>>         Another worthwhile question to ask: what if you're connecting
>>     to the origin via a proxy? Should that effect mode 2? Or maybe
>>     even be a different mode?
>>
>>     Best regards,
>>     Byron Campen
>>
>>
>>>     I agree. This would be consistent with the spirit of the
>>>     guidelines: "don't reveal any more IP addresses than have
>>>     already been revealed." This may have even been the intent from
>>>     the start; there's just not a clear definition for "default
>>>     route". "Default route used to fetch the origin" seems like a
>>>     reasonable definition.
>>>
>>>     On Wed, Aug 23, 2017 at 2:06 PM, James Pearce
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>         Please forgive me if I abused the process in any way - this
>>>         is my first contribution to a mailing list such as this.
>>>
>>>         I am the submitter of the original Mozilla bug identifying
>>>         this corner case mentioned by Byron. (I hesitate to call it
>>>         as such because the impact has been significant to our
>>>         particular WebRTC use case). I'd like to attempt to make my
>>>         case...
>>>
>>>         In my particular case, the remote peer is on a VPN. The VPN
>>>         is not installed as the default route (common for corporate
>>>         and organisational VPNs). Only the remote peer is supplying
>>>         media. This might seem an unusual setup, but I think this
>>>         kind of use will grow as the benefits of very-low latency
>>>         media streaming become more important. With no media to
>>>         contribute, the local peer never calls gUM. As both peers
>>>         are on a VPN, and gUM is never called, the connection fails
>>>         outright, since the connection falls back to mode 2, but the
>>>         VPN is not the default route - there is no opportunity to
>>>         ever obtain user permission.
>>>
>>>         Perhaps more importantly there is a privacy concern as well.
>>>         As I understand it, the purpose of mode 2 is to prevent
>>>         drive-by enumerations of addresses of alternative routes
>>>         that should remain private. The assumption seems to be that
>>>         the address of the default route is safe to reveal. However,
>>>         where the origin came via a non-default route, it seems like
>>>         an unsafe assumption. As a contrived example, if I'm a
>>>         corporate whistleblower, I don't want the external address
>>>         of my default route revealed to my employer when I'm using
>>>         my corporate VPN. However as the spec is currently worded,
>>>         it allows just that.
>>>
>>>         The obvious solution seems to be to change the behaviour of
>>>         mode 2. Rather than using the default route in all cases, we
>>>         should use the route that was used to fetch the origin. This
>>>         seems to resolve both the usability and privacy concerns
>>>         without reducing existing security.
>>>
>>>         Thanks for listening,
>>>
>>>         James

---

From: James Pearce <[email-masked]>
Date: Thu, 24 Aug 2017 17:33:19 +0100

> On 24 Aug 2017, at 15:12, Byron Campen <[email-masked]> wrote:
> 
> 
> 
>    So, I guess we could consider a scenario where the machine does not have internet access at all, and there's something nefarious going on in the private network? Seems kinda out of scope for fingerprinting attacks, honestly.

Yes, I think I agree.

>    If you're using an http proxy, this would be the case. I think it would be reasonable to fall back to the default route here. Another case might be when you're using a file instead of a web server.

Where an HTTP proxy is used to obtain the original page, wouldn't we use the proxy's address for the purpose of obtaining the usable route?

> Byron Campen

Cheers,
James

---

From: Byron Campen <[email-masked]>
Date: Thu, 24 Aug 2017 11:38:40 -0500

On 8/24/17 11:33 AM, James Pearce wrote:
>
>
> On 24 Aug 2017, at 15:12, Byron Campen <[email-masked] 
>> would be reasonable to fall back to the default route here. Another 
>> case might be when you're using a file instead of a web server.
>
> Where an HTTP proxy is used to obtain the original page, wouldn't we 
> use the proxy's address for the purpose of obtaining the usable route?
     Either way would be sane I think. We just have to be careful how we 
word the spec, so it covers this case.

Best regards,
Byron Campen

>>>> basic issue is that you want to use the same interface to connect 
>>>> to the remote endpoint as was used to load the page, even when the 
>>>> While the suggested solution seems reasonable, this may not always 
>>>> be possible (e.g., if you don't have access to the origin IP). 
>>>> Also, I think any public addresses associated with the default 
>>>> route will already be discoverable via other mechanisms, e.g. XHR 
>>>> (as Byron mentioned above).
>>>>
>>>>
>>>>     there's a NAT in the way, you would be revealing information
>>>>     that the webserver didn't already have. But that has always
>>>>     been the case with mode 2.
>>>>
>>>>         Another worthwhile question to ask: what if you're
>>>>     connecting to the origin via a proxy? Should that effect mode
>>>>     2? Or maybe even be a different mode?
>>>>
>>>>     Best regards,
>>>>     Byron Campen
>>>>
>>>>
>>>>>     already been revealed." This may have even been the intent
>>>>>     from the start; there's just not a clear definition for
>>>>>     "default route". "Default route used to fetch the origin"
>>>>>         Please forgive me if I abused the process in any way -
>>>>>         this is my first contribution to a mailing list such as this.
>>>>>
>>>>>         this corner case mentioned by Byron. (I hesitate to call
>>>>>         it as such because the impact has been significant to our
>>>>>         particular WebRTC use case). I'd like to attempt to make
>>>>>         my case...
>>>>>
>>>>>         In my particular case, the remote peer is on a VPN. The
>>>>>         VPN is not installed as the default route (common for
>>>>>         corporate and organisational VPNs). Only the remote peer
>>>>>         is supplying media. This might seem an unusual setup, but
>>>>>         I think this kind of use will grow as the benefits of
>>>>>         very-low latency media streaming become more important.
>>>>>         With no media to contribute, the local peer never calls
>>>>>         gUM. As both peers are on a VPN, and gUM is never called,
>>>>>         the connection fails outright, since the connection falls
>>>>>         back to mode 2, but the VPN is not the default route -
>>>>>         there is no opportunity to ever obtain user permission.
>>>>>
>>>>>         Perhaps more importantly there is a privacy concern as
>>>>>         well. As I understand it, the purpose of mode 2 is to
>>>>>         prevent drive-by enumerations of addresses of alternative
>>>>>         routes that should remain private. The assumption seems to
>>>>>         be that the address of the default route is safe to
>>>>>         reveal. However, where the origin came via a non-default
>>>>>         route, it seems like an unsafe assumption. As a contrived
>>>>>         example, if I'm a corporate whistleblower, I don't want
>>>>>         the external address of my default route revealed to my
>>>>>         employer when I'm using my corporate VPN. However as the
>>>>>         The obvious solution seems to be to change the behaviour
>>>>>         of mode 2. Rather than using the default route in all
>>>>>         cases, we should use the route that was used to fetch the
>>>>>         origin. This seems to resolve both the usability and

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Aug 2017 13:10:07 -0700

On Thu, Aug 24, 2017 at 9:38 AM, Byron Campen <[email-masked]> wrote:

>    If you're using an http proxy, this would be the case. I think it would
> be reasonable to fall back to the default route here. Another case might be
> when you're using a file instead of a web server.
>
>
> Where an HTTP proxy is used to obtain the original page, wouldn't we use
> the proxy's address for the purpose of obtaining the usable route?
>

This makes sense to me.
No Proxy = local v4/v6 used to load origin (bind to 0.0.0.0, connect to
origin IP, getsockname to learn interface)
Proxy = proxy interface
File = default route

Will file an issue at github.com/juberti/draughts/issues to track this.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Aug 2017 13:23:04 -0700

> Will file an issue at github.com/juberti/draughts/issues to track this.

Having thought about it a bit more, I think that binding to 0.0.0.0 or
doing the above will suffice. Essentially, this becomes a recommendation
that if you bind to a specific interface, you should determine that
interface via the origin IP, and not a 'well-known' IP, as was the prior
guidance.

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Aug 2017 15:30:28 -0500

On 8/24/17 15:23, Justin Uberti wrote:
> Essentially, this becomes a recommendation that if you bind to a 
> specific interface, you should determine that interface via the origin 
> IP, and not a 'well-known' IP, as was the prior guidance. 

Thus eliminating something that had always made me vaguely uneasy 
anyway. This seems cleaner all around. I support the proposed change.

/a