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

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 03:52:20 -0400

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

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.

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

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.

-hadriel

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 28 Jul 2011 07:38:10 -0400

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

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…

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jul 2011 14:10:17 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 28 July 2011 08:52
> To: [email-masked]
> Subject: [rtcweb] Strawman for how to prevent voice-hammer without ICE
> 
> 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.  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.
> 
> 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.
> 
> 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)  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.
[JRE] The problem with requiring continued RTP receipt (or even ANY RTP receipt) is sessions where RTP is one-way, e.g., when mic muted, camera off. With many asymmetric possibilities coming out of the CLUE work, this could be a problem, although it perhaps goes away if everything is multiplexed onto the same port. It depends whether we can expect all legacy devices to behave in a way that would make this work.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

> 
> 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.
> 
> -hadriel
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 10:48:07 -0400

> [JRE] The problem with requiring continued RTP receipt (or even ANY RTP receipt) is sessions where RTP is one-way, e.g., when mic muted, camera off. With many asymmetric possibilities coming out of…

Yes, but they don't turn off RTCP (assuming they do RTCP).  I'm not suggesting that it's a 1:1 mechanism of receipt/send, nor that it even be very dynamic/real-time.  But sure there will be some cases that it won't work.  But that's no worse than the current state of things, since it won't work to begin with for such devices if ICE is mandated.  We can't achieve 100% interop regardless - I'm just trying for as much as possible.

With regards to CLUE, I don't consider their devices "legacy".  They'll be upgrading to handle CLUE's final spec, so they can be "redeemed".

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jul 2011 17:14:42 +0200

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 28 July 2011 15:48
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: Strawman for how to prevent voice-hammer without ICE
> 
> 
> > [JRE] The problem with requiring continued RTP receipt (or 
> even ANY RTP receipt) is sessions where RTP is one-way, e.g., 
> when mic muted, camera off. With many asymmetric 
> possibilities coming out of the CLUE work, this could be a 
> problem, although it perhaps goes away if everything is 
> multiplexed onto the same port. It depends whether we can 
> expect all legacy devices to behave in a way that would make 
> this work.
> 
> Yes, but they don't turn off RTCP (assuming they do RTCP).  
> I'm not suggesting that it's a 1:1 mechanism of receipt/send, 
> nor that it even be very dynamic/real-time.  But sure there 
> will be some cases that it won't work.  But that's no worse 
> than the current state of things, since it won't work to 
> begin with for such devices if ICE is mandated.  We can't 
> achieve 100% interop regardless - I'm just trying for as much 
> as possible.
[JRE] This assumes RTP-RTCP multiplexing, which not many current devices support. There are so many things that RTC-Web is proposing to use that are not widely supported on existing devices that some sort of gateway looks inevitable. Eliminating one particular instance of incompatibility might reduce the amount of adaptation the gateway needs to perform, but it looks increasingly unlikely that all adaptation can be eliminated. So is there any real value in trying to eliminate one aspect if others can't be eliminated? Probably yes, but not if it introduces other compromises, e.g., security. I think it is worth exploring this further.

John

> 
> With regards to CLUE, I don't consider their devices 
> "legacy".  They'll be upgrading to handle CLUE's final spec, 
> so they can be "redeemed".
> 
> -hadriel
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 11:30:30 -0400

On Jul 28, 2011, at 11:14 AM, Elwell, John wrote:

> [JRE] This assumes RTP-RTCP multiplexing, which not many current devices support.

No, I didn't mean to assume multiplexing.  Sorry if it was confusing.  I meant if you're worried about using RTP reception to allow transmission because in some cases RTP isn't sent from the far end for periods of time, then one could use the reception of RTCP on the odd port to allow the sending of RTP on the even.  

I was already assuming multiplexing would not likely be used with legacy voip devices, since none of them do it today.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 11:58:15 -0400

> 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 pa…

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 co…

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Jul 2011 12:58:06 -0400

Let me suggest a variation on this..

The rtcweb client can send RTP packet, voice-only, for a brief period of 
time (say, 2x the RTCP interval). It waits to receive an RTCP packet. 
The RTCP packet should have an RR which reflects back the SSRC sent by 
the client, if it does, the rtcweb client continues. If not, it stops 
sending.

The purpose of the RTCP SSRC check is to emulate what the STUN 
transaction ID provides; that there is something on the media path which 
is expecting this RTP packet. Not as good as STUN which also has the 
short term credential, but its something.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Skype Chief Technology Strategist 

[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 13:07:36 -0400

> short term credential, but its something.

I had considered using the SSRC before, but I think you're gonna have to let the javascript know the SSRC to handle some SIP/SDP usages (since there's an SSRC attribute for SDP, I assume someone needs it).  No?

-hadriel

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 28 Jul 2011 13:29:33 -0400

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

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

> Not when communicating with legacy voip devices and the PSTN.

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

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

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

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 28 Jul 2011 13:30:37 -0400

On Jul 28, 2011, at 12:58 PM, Jonathan Rosenberg wrote:

> The rtcweb client can send RTP packet, voice-only, for a brief period of time (say, 2x the RTCP interval). It waits to receive an RTCP packet. The RTCP packet should have an RR which reflects back the SSRC sent by the client, if it does, the rtcweb client continues. If not, it stops sending.
> 
> The purpose of the RTCP SSRC check is to emulate what the STUN transaction ID provides; that there is something on the media path which is expecting this RTP packet. Not as good as STUN which also has the short term credential, but its something.

Lacks both the short term credential and is not enough bits to protect against attackers who can generate a flurry of forged RTCP packets. See my previous email.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 28 Jul 2011 16:49:45 -0400

> 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,…
I think this approach is not paranoid enough.

The attacker will negotiate a channel claiming that you can reach him on 
10.0.0.2 (your server that he wants to voice-hammer), and then send you 
the five or so RTP packets you expect with a fake source address of 
10.0.0.2.

Then you, having seen exactly the packets that "authorize" sending 
traffic to 10.0.0.2, will be performing the voice-hammer attack against 
the server that the attacker otherwise couldn't reach.

You would have to send RTP packets yourself (which will correctly be 
dropped on the floor by 10.0.0.2) until the time at which you can start 
wondering about there being no RTCP packets from 10.0.0.2 in order to 
have a 2-way handshake - and that only works if the RTCP RR contains 
enough stuff the attacker can't predict that he can't just generate the 
RTCP too.

(This doesn't work with ICE, because the ICE handshake involves the 
recipient replying to your packet with some parameters that can only be 
found in the request, not in the negotiation).

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 18:55:46 -0400

> the server that the attacker otherwise couldn't reach.

Yes, that was the weakness of the model as I described in my original email: that the malicious web-server can spoof the RTP from the device being attacked.
And I proposed that instead of it being a single "authorization" phase at the beginning of the call, it could even be continuous/periodic.  Of course the web-server could continuously send spoofed RTP to the browser, but at that point it might as well do the attack directly spoofing the browser. (in other words, the malicious website isn't gaining a very useful botnet of attackers, since I assume that's the concern)

> found in the request, not in the negotiation).

Yes I know ICE solves this, but since ICE doesn't exist for legacy VoIP and PSTN, a non-existent solution isn't very useful.

-hadriel

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Jul 2011 05:45:23 -0700

[BA] Agree that it's worth exploring further, if only to document what the security requirements are, and what is required to meet them.  The problem with the gateway argument is that it can be extended too far -- it is one thing to require a gateway for signaling, and quite another to require transcoding of media, for example.  As long as we have legacy interop use cases, and aren't asserting that RTCWEB represents a "singularity", then we need to be able to handle them.