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

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

On 18/07/2015 10:37, Sergio Garcia Murillo wrote:
> 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 ;)
>

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

Best regards
Sergio