Re: [rtcweb] Summary of ICE discussion

Jonathan Lennox <jonathan@vidyo.com> Wed, 05 October 2011 14:25 UTC

Return-Path: <jonathan@vidyo.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 BF39721F8E04 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 07:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Level:
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61dUW8+RHuLW for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 07:25:18 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4720921F8DFE for <rtcweb@ietf.org>; Wed, 5 Oct 2011 07:25:18 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id ECF138BF1B9; Wed, 5 Oct 2011 10:28:25 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB015.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 577BC8BF069; Wed, 5 Oct 2011 10:28:24 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 5 Oct 2011 10:27:51 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, Matthew Kaufman <matthew.kaufman@skype.net>
Date: Wed, 5 Oct 2011 10:28:03 -0400
Thread-Topic: [rtcweb] Summary of ICE discussion
Thread-Index: AcyDaBf7WyJ6QPMyRCqvtx9Eu6jUUAAAWXOQ
Message-ID: <C3759687E4991243A1A0BD44EAC823034C42AAD6BD@BE235.mail.lan>
References: <4E8B192E.80809@ericsson.com> <CALiegfmnxO+BrfycOmL=hptBFdcEpsLeBn=zsJTX=ivKBBumWw@mail.gmail.com> <BLU152-W139AA2913C1CFFDB50726193FB0@phx.gbl> <BLU152-W2342F5823933FA1F2B9F9C93FB0@phx.gbl> <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> <4E8BC56E.40306@skype.net> <snt0-eas2567EB3C48B254DA9E07FC693F80@phx.gbl>
In-Reply-To: <snt0-eas2567EB3C48B254DA9E07FC693F80@phx.gbl>
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
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Summary of ICE discussion
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: Wed, 05 Oct 2011 14:25:18 -0000

Bernard Aboba wrote:
> On Oct 4, 2011, at 7:49 PM, "Matthew Kaufman" <matthew.kaufman@skype.net>; wrote:
> > I think what he's concerned about is that a device might consent (using ICE) to receive audio and unexpectedly receive multiplexed video on the same RTP port.
> >
> > Not sure this really matters, as there's not much difference between low-frame-rate low-res video and 16-bit linear stereo PCM at 48 kHz (which might indeed be an audio codec you can choose).
>
> Right, that's the attack I had in mind, but with high bandwidth video.

This sounds to me like the congestion control mechanism needs to be part of the browser-enforced security properties, and transported in a secure manner that an attacker can't spoof (which probably means over DTLS-SRT(C)P).

Once congestion control has indicated that a receiver has consented to a certain bitrate, how an application choses to fill it isn't so important as a security property.  Sending a consenting peer (e.g.) 48 kHz L16 audio instead of low-res video (or vice versa) would be kind of pointless, but not really a DoS attack if the peer has already agreed to receive that much bandwidth.

-- 
Jonathan Lennox
jonathan@vidyo.com