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

[Tim Panton <[e-mail]>]

> On 20 Jul 2015, at 14:26, Simon Perreault <[e-mail]> wrote:
> 
> Le 2015-07-20 14:58, Tim Panton a écrit :
>> If I understand correctly we bind to each and every interface
>> that is up and send out packets to all remote candidates down _every_ interface,
>> ignoring any preferences set by the admin in the local routing table which
>> were set to ensure (say) only critical traffic is sent down certain interfaces.
> 
> I have difficulty understanding what it is that's bugging you. Is it the
> signalling payload (i.e., sending the list of address), or is it the
> connectivity checks that are done on all candidate pairs?

I’m not worried about the signalling payload (i.e. the list of local interface addresses - 
except of course the mac-based ipv6 auto conf one).
I am worried about what can be learnt from /caused by sending packets down interfaces
when the sysadmin isn’t expecting it.

(In the end some of those learnings may end up in signalling as candidates too).

> 
>> I can think of some financial institutions who’s IDSs will go off when packets
>> to public external addresses start turning up on internal LANS . (hopefully they 
>> will get dropped at the egress router, but by then the IDS will have paged someone).
> 
> But that's not going to happen unless there's a route. I think there
> could be a misunderstanding here. For example, if there's a VPN with a
> 10.0.0.0/8 route but no default route, the ICE client will *not* send a
> request to a TURN server listening on 192.0.2.1 over the VPN interface.
> That would make no sense whatsoever.

And yet that’s what I read Martin to say : 
"> The point is that you don't even choose the interface. The OS will do for you.
The OS can - and frequently does - get that wrong. The default route can fail when another might succeed."

I read that as 'another interface’ - but if he means  ‘another route’ then I’m happier - I think.
Can @justin or @martin confirm what the browsers currently do ?


> 
>> Likewise my fantastically expensive BGAN link which is used for
>> emergencies only will suddenly start carrying STUN requests irrespective of how I configure my
>> routes ?
> 
> Only if it's possible to route the packet to the STUN server over the
> BGAN link. There must be a route.

There must be a _locally_ configured route - It doesn’t matter if the egress router at the far end of the BGAN drops 
the STUN packet I’ve still wasted my money :-(

> 
> Simon

Tim.