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

Jonathan Rosenberg <jdrosen@jdrosen.net> Thu, 28 July 2011 16:58 UTC

Return-Path: <jdrosen@jdrosen.net>
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 C44F721F8BB4 for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 09:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.645
X-Spam-Level:
X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, 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 csM0H5NILwLV for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 09:58:07 -0700 (PDT)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.48.15]) by ietfa.amsl.com (Postfix) with ESMTP id 14CC321F8BB3 for <rtcweb@ietf.org>; Thu, 28 Jul 2011 09:58:07 -0700 (PDT)
Received: from dhcp-133f.meeting.ietf.org ([130.129.19.63]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <jdrosen@jdrosen.net>) id 1QmTuQ-0008WU-Ea for rtcweb@ietf.org; Thu, 28 Jul 2011 12:58:06 -0400
Message-ID: <4E31951E.1080108@jdrosen.net>
Date: Thu, 28 Jul 2011 12:58:06 -0400
From: Jonathan Rosenberg <jdrosen@jdrosen.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <B6527F21-4DE2-46B1-AE2E-891D56461313@acmepacket.com>
In-Reply-To: <B6527F21-4DE2-46B1-AE2E-891D56461313@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
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 16:58:07 -0000

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.

On 7/28/11 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.  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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


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

jdrosen@skype.net                              http://www.skype.com
jdrosen@jdrosen.net                            http://www.jdrosen.net