Re: [rtcweb] Summary of ICE discussion

Jonathan Lennox <> Wed, 05 October 2011 14:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF39721F8E04 for <>; Wed, 5 Oct 2011 07:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 61dUW8+RHuLW for <>; Wed, 5 Oct 2011 07:25:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4720921F8DFE for <>; Wed, 5 Oct 2011 07:25:18 -0700 (PDT)
Received: from (localhost []) by (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 []) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 577BC8BF069; Wed, 5 Oct 2011 10:28:24 -0400 (EDT)
Received: from BE235.mail.lan ([]) by HUB015.mail.lan ([]) with mapi; Wed, 5 Oct 2011 10:27:51 -0400
From: Jonathan Lennox <>
To: Bernard Aboba <>, Matthew Kaufman <>
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: <> <> <BLU152-W139AA2913C1CFFDB50726193FB0@phx.gbl> <BLU152-W2342F5823933FA1F2B9F9C93FB0@phx.gbl> <> <> <snt0-eas2567EB3C48B254DA9E07FC693F80@phx.gbl>
In-Reply-To: <snt0-eas2567EB3C48B254DA9E07FC693F80@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] Summary of ICE discussion
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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" <> 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