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

"Elwell, John" <john.elwell@siemens-enterprise.com> Thu, 28 July 2011 12:10 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978C321F85EE for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 05:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.575
X-Spam-Level:
X-Spam-Status: No, score=-103.575 tagged_above=-999 required=5 tests=[AWL=-0.976, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUxm5E+609pX for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 05:10:28 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3221F8514 for <rtcweb@ietf.org>; Thu, 28 Jul 2011 05:10:28 -0700 (PDT)
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 8AD721EB842D; Thu, 28 Jul 2011 14:10:27 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Jul 2011 14:10:19 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Thu, 28 Jul 2011 14:10:17 +0200
Thread-Topic: Strawman for how to prevent voice-hammer without ICE
Thread-Index: AcxM+0gr6MSbGksHRW+4C5EDW5aSMgAI3yIw
Message-ID: <A444A0F8084434499206E78C106220CA08F1D75CF6@MCHP058A.global-ad.net>
References: <B6527F21-4DE2-46B1-AE2E-891D56461313@acmepacket.com>
In-Reply-To: <B6527F21-4DE2-46B1-AE2E-891D56461313@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Strawman for how to prevent voice-hammer without ICE
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 12:10:29 -0000

 

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