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

[Simon Perreault <[e-mail]>]

Le 2015-07-20 15:13, Iñaki Baz Castillo a écrit :
>     > Gulp. Whilst I mostly see the logic - it is wholly unexpected behaviour
>     > to the average sys admin.
>     > Certainly not what I expected.
> 
>     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?

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.

>     > 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. 
> 
> 
> 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?

>     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?
> 
> 
> 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.

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

>     > 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) ?
> 
>     That is a valid concern, and the answer to it is MIF.
> 
> 
> 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