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

[Hadriel Kaplan <[e-mail]>]

On Jul 28, 2011, at 7:38 AM, Matthew Kaufman wrote:

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

No it's not as "safe", but it may be safe enough.  
With regards to being misinterpreted by others, since the web server javascript cannot define the actual payload of the RTP (correct?), and things like sequence numbers would also be randomly chosen by the browser, so it's not like the javascript can purposefully craft an RTP packet to immitate other protocols.  For example it would be an astronmoical coincidence for any given RTP packet to be parsable as SNMP BER for a given ASN.1 dictionary.
(Also as an aside, if I recall correctly SNMP is actually distinguishable from RTP by the first byte)


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

If we used RTCP as part of the check, the reports contain a last received sequence number which would not be known to the javascript.  (it's a hack to be sure, but if we want to handle non-RTCWEB devices, a hack's better than nothing)


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

Not when communicating with legacy voip devices and the PSTN.


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

I should probably write it up in a draft to be much more clear, but to the above point that's not an issue.  I'm not suggesting the browser be allowed to do this RTP-based verification for any and all use-cases.  I'm only suggesting it to handle the large population of legacy VoIP devices, including to the PSTN.  Video without audio, or any future data-type streams, would not apply and we don't need to handle them this way and can restrict the browser from allowing it.

-hadriel