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

> -----Original Message-----
> From: rtcweb-bounces@ietf.org 
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan
> Sent: 28 July 2011 08:52
> To: rtcweb@ietf.org
> 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: john.elwell@siemens-enterprise.com
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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 