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

[Matthew Kaufman <[e-mail]>]

On Jul 28, 2011, at 11:58 AM, Hadriel Kaplan wrote:

> 
> On Jul 28, 2011, at 7:38 AM, Matthew Kaufman wrote:
> 
>> 
>> 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.  

I disagree. You need both 1) a large number of bits of transaction ID (on the order of the 128 bits provided by STUN), and 2) a shared secret passed out of band between the two ends (for example, the short term credentials used by STUN connectivity checks).

Failing to provide both of the above opens possibilities for attacks that I believe will not be acceptable to browser vendors due to the relative danger of exposing this capability "behind the firewall."

> With regards to being misinterpreted by others, since the web server javascript cannot define the actual payload of the RTP (correct?)

If datagrams are also allowed, a remarkable amount of the data being sent can be chosen from the Javascript. The datagram proposals assume that ICE is used to get consent ahead of time.

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

I don't believe this is enough bits, and it lacks the shared secret mechanism.

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

Correct, but my point is that the ICE implementation must exist.

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

Again, I don't think it provides adequate protection to the other devices on the network behind the firewall that the browser is on. But do please write your proposal up in more detail.

Matthew Kaufman