Re: [rtcweb] New proposal for IP address handling in WebRTC

I'm still more of a fan of going with a solutions of "if you want your VPN to hide your IP address, make sure you use a VPN that hides your IP address." - that is to say don't use a split tunnel VPN if you want to make sure all your traffic only goes down the VPN. 

I don't think the "default route" is as straight forward as that. For example, if the VPN is v4 only, but there is a v6 connectivity too, then the default route for v6 packets is not over the VPN but default route for v4 might be over the VPN. I think we would need to understand how cases like this work. If we add in the type of multpath proposal that people want for WiFi / Cellular handover. It's complicated with some VPNs - for example, the IOS VPN can look at the DNS information to decide what the default route might be for  a given flow so the default route for one flow might not be the same as for another flow. 

> On Apr 19, 2015, at 11:49 PM, Justin Uberti <juberti@google.com> wrote:
> 
> Background
> At IETF 92 we proposed a browser mechanism that users could enable to avoid disclosing their VPN IP to websites as a side effect of ICE candidate generation. When this mechanism was enabled, the browser would bind only to 0.0.0.0 and ::, and only generate candidates via STUN and TURN; because these sockets would follow the OS default routing, the only candidate addresses discovered would be the ones that the website already had access to (i.e. from the HTTP request).
> 
> The primary downsides with this mechanism were:
> a) users had to manually enable it (through some potentially non-obvious preference)
> b) when enabled, it caused trombone routing in intranet cases
> c) when enabled, it broke pretty much every simple demo page (which typically don't use STUN servers)
> 
> Proposal
> We now propose a new mechanism that attempts to address these issues. The new mechanism works like the previous mechanism, but during the candidate generation process, we call getsockname to obtain the local IP address of the interface used to talk to the STUN/TURN server. This obtains a *single* interface IP, which allows the browser to avoid trombone routing, but also minimizes the amount of IP information revealed to JS. Furthermore, the STUN traffic continues to go out the default route, meaning that if a VPN is used, the 'real' public address is still not disclosed. (Naturally, this has some performance implications, as a user may not always want their media to go out the VPN.)
> 
> For pages that don't use STUN/TURN servers (typically demo pages), there are a few options to consider:
> a) always surface localhost as a candidate when no STUN/TURN servers are provided (works with existing demos, but may have false positives with certain apps)
> b) always include some default STUN server when no STUN/TURN servers are provided (similar to above, plus complexity of choosing default)
> c) add some RTCConfiguration parameter indicating that the localhost address is desired (requires updating many demo pages)
> 
> None of these choices is ideal, but this seems like a solvable problem.
> 
> Implications for Browsers
> As this mechanism should alleviate the primary security concerns with interface enumeration, with relatively small impact on user experience, we propose that this be the default for browsers. For users that don't want to disclose any local IP information, browsers could expose a preference that prevents surfacing even the single local IP (i.e. the originally proposed behavior). For users that want to ensure maximum performance (e.g. to address the VPN issue above), a similar preference (or permissions grant) could be exposed that allows enumeration of all IPs.
> 
> FAQ
> Q: WebRTC already requires permission to access getUserMedia. Why not use that permission to control interface enumeration?
> A: Receive-only applications (e.g. streaming media) or datachannel applications don't require a call to gUM, so there are cases where that approach would not work.
> Q: Is this only for browsers, or also for native apps?
> A: This proposal is currently targeted at browsers. Native applications, especially on mobile, need to be able to access individual interfaces in order to be able to do seamless wifi-cellular call handover.
> 
> We welcome feedback on this proposal.
> 
> Guo-wei Shieh and Justin Uberti
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb