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

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Simon Perreault
> Sent: Sunday, July 19, 2015 2:29 AM
> To: Iñaki Baz Castillo; Roman Shpount
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Please require user consent for data channels
> 
> Le 2015-07-18 06:01, Iñaki Baz Castillo a écrit :
> > 2015-07-18 11:38 GMT+02:00 Roman Shpount <roman@telurix.com>:
> >> Sending data to a particular destination over an interface that is
> >> not supposed to be used based on the local routing is definitely
> >> something that goes against the local policy and should be
> >> discouraged. For instance on a mobile device, not being able to reach
> >> a particular STUN/TURN server over WiFi, should not give the browser
> >> an automatic permission to send media over cell data interface and
> >> generate a huge bill for the customer. Forcibly overwriting default
> >> route is something that should need user consent. I understand that
> >> we want the call to succeed in as many cases as possible, but blindly
> >> assuming that the local routing policy exists for no reason whatsoever is
> somewhat dangerous.
> >
> > +1
> 
> -1
> 
> Justin and Martin are right.
> 
> This is a concept that was explained during the ICE tutorial that was presented
> at IETF 92.
> 
> Imagine the following multihomed host with three interfaces:
> 
> - Wi-fi interface with default route.
> - Wired interface with default route.
> - VPN interface with default route.
> 
> Which one should you use to talk to the STUN/TURN server? If you bind to
> 0.0.0.0 then the kernel *will* pick one, but only because it *has to.
> All three interfaces are equivalent: they all have a default route and can a priori
> be used to talk to the server.
> 
> Being multihomed means multiple interfaces with a default route. There's no
> "going against the local policy" in this case when sending packets on any
> interface.
> 
> The point is that in this case, all three interfaces can potentially yield different
> server-reflexive candidates, which is why they must be gathered separately. As
> for relayed candidates, they also need to be gathered separately because some
> interfaces may be faster for talking to the TURN server and it is useful to
> compare the candidates gathered on all 3 interfaces. Also nothing guarantees
> that you're allowed to reach the server server on any interface that has a
> default route, so you need to try them all.

This will change in the future with multiple provisioning domains (PVD) defined in MIF WG, new socket API will be provided to allow applications to learn about each PVD and use them separately, and as discussed in https://tools.ietf.org/html/rfc7556#section-6.3 application may not override hard set selected by the user.

-Tiru

> 
> Simon
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb