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

On 07/28/11 03:52, 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.  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.
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).
> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>