Re: [rtcweb] What is consent?

Martin Thomson <martin.thomson@gmail.com> Wed, 12 September 2012 15:57 UTC

Return-Path: <martin.thomson@gmail.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 F0B4421F859B for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2012 08:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 E9Q5Fw4HMMqR for <rtcweb@ietfa.amsl.com>; Wed, 12 Sep 2012 08:57:10 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A68E21F85EF for <rtcweb@ietf.org>; Wed, 12 Sep 2012 08:57:09 -0700 (PDT)
Received: by lbky2 with SMTP id y2so1378343lbk.31 for <rtcweb@ietf.org>; Wed, 12 Sep 2012 08:57:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hqKL99cfvFad8WffcylJdj5sVXHtEXLRB4w+M+klfRs=; b=U1+SCBB7WlFHWYMfRyOiijOebjnmJD9QOcRBl4Jul0eBcwjs9YwZbxdpT/R9/g2vSW kFV4oyVIKpjpbXecGDPYG7zXnUnJCJ46TnsED2xGNnfYBY0O7ZmTAj/CdBQMajlibIla 8QN0AE1VV4Jk8/OSr+k24J/LZvw/mpPHR4aH7wZIt/nJbIhHSeiY/+oKGtEn9Jcd1y+8 n6M7YLy6ON2aOPnGRwP20VOQP6yIgnKtWP7YbHGMZbtKDwouC4By24Kr+x1l595gIUxq LS25u9T7+duDkFP0vgxEoEpL/SXoaOTEqh3G0AqH0ic1uGZY6XUCqI7cvrfueMZ8hWjn 5Ilg==
MIME-Version: 1.0
Received: by 10.112.49.202 with SMTP id w10mr7587544lbn.109.1347465428778; Wed, 12 Sep 2012 08:57:08 -0700 (PDT)
Received: by 10.112.1.36 with HTTP; Wed, 12 Sep 2012 08:57:08 -0700 (PDT)
In-Reply-To: <BLU401-EAS46055078032CCFBDDFD2C2B93920@phx.gbl>
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>
Date: Wed, 12 Sep 2012 08:57:08 -0700
Message-ID: <CABkgnnUMcFx15qytVNo2G67CX84TLZ_29UMB5EzJ=WqRF5o1GQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 15:57:11 -0000

There are a number of things that concern me regarding this.

Firstly, USE-CANDIDATE can be sent on multiple pairs over time.
Particularly if the first pair fails for some reason.  Blocking
nominations after the first would prevent failover, as well as things
like multipath or confusing cases where there are multiple components
using the same set of local candidates (c.f., BUNDLE backward
compatibility scenarios).

I don't think that USE-CANDIDATE is sufficient or necessary for
consent.  Nomination is asymmetric in nature; only the controlling
peer can send it.  The controlled peer has no way to know that the
nomination check wasn't spoofed.  After all, that is the reason both
peers send connectivity checks.  The controlled peer then can't attach
any real significance to the nomination.  That isn't inherently a
problem - the controlled peer is still making checks and it is those
checks that verify that the controlling peer is willing to receive
packets at those addresses.

However, the underlying concern Bernard alludes to is a real one.  Not
only does consent indicate that I can send an arbitrary volume of data
to the checked host, as a natural consequence of ICE checking, there
is a decent chance that I get a large number of options, all of which
accept that arbitrary volume of data.

--Martin

On 12 September 2012 05:17, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> On Sep 12, 2012, at 1:51, "Lishitao" <lishitao@huawei.com> wrote:
>
> Dan Wing said:
>
>
> For ICE Mobility (draft-wing-mmusic-ice-mobility), we might want to
> keep other candidates available, but inactive.  Over those other
> candidates we would not signal USE-CANDIDATE, but we would want to
> be able to switch to the other candidate as quickly as possible
> (ideally, switch over immediately).  Similar considerations might
> apply to multipath RTP
>
> [BA] My question is whether the browser has a legitimate reason to send
> media to a destination that is not part of a valid pair for which the
> nominated flag is set to true, as per RFC 5245 Section 7.1.3.2.4.  For
> mobility you can still signal USE-CANDIDATE but not use the pair if another
> pair had higher priority.
>
>
>
>
>
> I donot think rfc 5245 allows this, it only allow only one pair with the
> USE-CANDIDATE attribute present.
>
>
> [BA] But in that case you would want to use the pair, no?
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>