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

[Sergio Garcia Murillo <[e-mail]>]

On 18/07/2015 2:19, Justin Uberti wrote:
>
> On Fri, Jul 17, 2015 at 4:35 PM, Sergio Garcia Murillo 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 18/07/2015 1:09, Justin Uberti wrote:
>
>     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