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

[Hadriel Kaplan <[e-mail]>]

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