Re: [rtcweb] What is consent?

Harald Alvestrand <harald@alvestrand.no> Wed, 12 September 2012 23:40 UTC

Return-Path: <harald@alvestrand.no>
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 45AAD21F861C for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2012 16:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 zI0CTQfFSMcs for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2012 16:40:02 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 078BE21F85B4 for <rtcweb@ietf.org>; Wed, 12 Sep 2012 16:40:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B3F8E39E1B9 for <rtcweb@ietf.org>; Thu, 13 Sep 2012 01:40:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZMSDjokUhJq for <rtcweb@ietf.org>; Thu, 13 Sep 2012 01:39:59 +0200 (CEST)
Received: from [172.22.79.234] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E236A39E1AC for <rtcweb@ietf.org>; Thu, 13 Sep 2012 01:39:58 +0200 (CEST)
Message-ID: <50511D4C.9040805@alvestrand.no>
Date: Wed, 12 Sep 2012 16:39:56 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnXAPZ5BN=CUwYdEpHKbCLBxctqpONL==QWf_WwgrNEK_A@mail.gmail.com> <CABcZeBNnoQwJu1MYSW=6q6pkrgXSPSUtVyOsngrPP6b8GaegdQ@mail.gmail.com> <CABkgnnUNhka8OJsiNCV5iOvU_cGyvt_y8=DN6qnud3Xr-dy1iQ@mail.gmail.com> <CABcZeBNddHgHnkZ5b2N4i-np3WuY51f6WHkBdT5mHBsieLMDow@mail.gmail.com> <BLU169-DS48211D4056CB291285DD4393930@phx.gbl> <08c301cd9076$a2405c40$e6c114c0$@com> <BLU401-EAS3820748E547AD9D27E1220893920@phx.gbl> <DA165A8A2929C6429CAB403A76B573A5146A00B9@szxeml534-mbx.china.huawei.com> <BLU401-EAS46055078032CCFBDDFD2C2B93920@phx.gbl> <CABkgnnUMcFx15qytVNo2G67CX84TLZ_29UMB5EzJ=WqRF5o1GQ@mail.gmail.com> <0c2301cd910d$7f4bd150$7de373f0$@com> <CABkgnnUMsoOT954Jgd=jq6jjrhLV0uqSL6R4148mYtFMPG-JaQ@mail.gmail.com>
In-Reply-To: <CABkgnnUMsoOT954Jgd=jq6jjrhLV0uqSL6R4148mYtFMPG-JaQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] What is consent?
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, 12 Sep 2012 23:40:03 -0000

On 09/12/2012 10:55 AM, Martin Thomson wrote:
> On 12 September 2012 10:39, Dan Wing <dwing@cisco.com> wrote:
>> The volume of data is separate from USE-CANDIDATE, though.  ICE does
>> not currently have a way to indicate bandwidth.
> Yes.
>
>> There was a bandwidth extension for TURN, but it did not achieve
>> working group consensus and is not in the TURN RFC.  There is
>> a bandwidth extension to ICE that Microsoft documents and I believe
>> use in their products, http://msdn.microsoft.com/en-us/library/cc339480,
>> MS-ICE2BWM and MS-TURNBWM.
> There are two bandwidth-related things in use.  One is related to
> bandwidth estimation and not really pertinent to this.  The other
> potentially relevant one is the bandwidth parameter (the one that
> never reached consensus) is used to manage bandwidth for relay
> allocations.
>
> The latter is interesting to me, particularly if that parameter can be
> applied to ICE.  There are some gotchas that need careful
> consideration, particularly around this area of having consent on
> multiple valid candidate pairs.
I may be hopelessly naive here, but isn't the b= parameter of the SDP 
negotiation supposed to give an upper limit on how much data the 
recipient expects to receive on a connection?

RFC 3264 section 5.1 (unicast offer):

    If the bandwidth attribute is present for a stream, it indicates the
    desired bandwidth that the offerer would like to receive.

Section 6.1 (unicast answer):

    The answerer MAY include a bandwidth attribute for any media stream;
    this indicates the bandwidth that the answerer would like the offerer
    to use when sending media.

(note that "media stream" here is != MediaStream)

The browser being used to stage an attack will of course not know this 
value, since its signalling is controlled by the attacker, but the 
browser being attacked will be able to tell the difference between a 
within-contract amount of data and an out-of-contract amount of data.

               Harald