Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE

[Matthew Kaufman <[e-mail]>]

On Jul 28, 2011, at 3:52 AM, Hadriel Kaplan wrote:

> Howdy,
> With regard to mandating ICE, such that an RTCWEB browser cannot send RTP without doing ICE successfully first... is that restriction purely to prevent the voice-hammer attacks?  If so, then it's unfortunate because obviously it would seriously reduce interop with non-RTCWEB VoIP devices.

Agree that it limits interoperability.

>  But I think there's a way to prevent the hammer attack without using ICE, and without requiring legacy VoIP devices to change whatsoever.
> 
> One way would be to use the receipt of RTP as an indicator the far-end expects to receive it from you.  So have the browser generate RTP/RTCP packets, at a relatively slow rate, for a short duration (e.g., use the same rate/retransmit timers of STUN connectivity checks in ICE).  If the browser receives RTP/RTCP packets, then the far-end expected to receive them as well and the browser can do normal RTP from then on.

This is not as safe. There are devices/software that do things upon receipt of RTP packets (like play them out through loudspeakers, or initiate ringing of the softphone), and more important RTP packets are not carefully designed to avoid imitating other types of traffic such as SNMP, whereas STUN packets contain a relatively large header with a magic number that makes them much less likely to be misinterpreted by other protocols.

Additionally the STUN connectivity check used for ICE contains short-term credentials and a transaction ID that is unknown to the signaling layer (or Javascript) that ensure that you are in fact conducting a pairwise negotiation with the far end that you are thinking of. With RTP/RTCP packets alone you can create attacks both from the browser (by sending RTP/RTCP and using something else to spoof enough replies that the test passes) or on the browser (by sending it RTP from somewhere else).

And of course ICE, or something like it, is required anyway for doing NAT traversal.


> 
> If this was a hammer attack, this doesn't generate any more load on the target than ICE, since ICE would have sent X number of STUN packets for Y time as well, and I'm suggesting the X and Y be the same values for the initial RTP packets during the "check" phase.

Problem is that it isn't just load. Another class of attack is sending packets to things like SNMP servers behind a firewall. No matter how slow the rate, if one of the packets causes bad things to happen then you have a security problem.

> 
> The major weakness of this approach is that a malicious web-server trying to get your browser to do the voice hammer could send RTP to your browser, since it knows the address/ports of both sides, codec payload types, etc. (i.e., it can spoof being the attack target to make your browser think it's ok to do normal RTP)

Indeed. See above.

>  But we could probably play games with RTCP SR/RR or even just require continued RTP receipt to send RTP, in order to mitigate this weakness or make it of low value to exploit.

I don't believe this is the case. There's so many cases where one side sends A+V but the other side sends audio only, and sending HD-video-rate traffic to an unsuspecting endpoint is unacceptable.

This is even worse if we allow arbitrary datagrams with a relatively short header, as these will be even easier to craft into attacks on other protocols if there isn't confirmed consent.

> 
> Does anyone else care about interop-ing with legacy non-RTCWEB voip devices?  I checked draft-ietf-rtcweb-use-cases-and-requirements-01 and I don't see it, so I'm not sure.

I care, but I think that the legacy devices are going to need a way to consent. At one of our first meetings prior to forming the WG I came up with additional terminology to describe devices which are legacy and cannot be upgraded vs. devices which are legacy but which can be upgraded sufficiently to add the ICE handshake... we should probably bring that back for convenience.

Matthew Kaufman