Re: [rtcweb] ICE and security

["Dan Wing" <[e-mail]>]

...
> So basically we're stuck with requiring ICE be used for every
> media/data session, and thus not being able to interop directly with
> devices which don't do ICE (which is most of the SIP world right now).

To work, they "just" need to do ICE-Lite.  ICE-Lite is the ability to 
respond to ICE's media path STUN messages.  ICE-Lite does not require a 
STUN server, does not require a TURN server, and does not require 
gathering IP addresses that everyone finds (oddly) difficult.

Those that don't do ICE-Lite can be front-ended with an SBC that does
ICE-Lite for them.

> One open question is if javascript will even be allowed to open a media
> channel to a peer without human/user consent. 

I'll bet a beer it'll happen without human consent, yes.

> I thought we were
> requiring per-site consent.  I guess a malicious site could still offer
> legitimate media usage, and thus get user's consent, and then sometime
> in the future the same website could turn evil; or it could offer
> seemingly legitimate service that works, while in javascript creating a
> forked stream that is the one attacking someone else.
> 
> I wonder though if even requiring ICE is sufficient.  If I'm a
> malicious javascript, I could add enough ICE candidates against a
> target that it would be the same as an RTP stream in aggregate (I
> believe ICE's throttling limit was in fact approximately the rate of
> RTP by design, if I recall correctly).

Yep, if you 0wn enough hosts, just their "can I send you a flood of
media packets" requests could, itself, be a flood of traffic.


Let's talk about DNSSEC responses being a source of attack.

-d