Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt

Martin Thomson <martin.thomson@gmail.com> Wed, 27 February 2013 00:26 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 C4DA621F86CE for <rtcweb@ietfa.amsl.com>; Tue, 26 Feb 2013 16:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.069
X-Spam-Level:
X-Spam-Status: No, score=-7.069 tagged_above=-999 required=5 tests=[AWL=-3.470, 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 TR6v2ei7YV96 for <rtcweb@ietfa.amsl.com>; Tue, 26 Feb 2013 16:26:53 -0800 (PST)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id E688621F86B2 for <rtcweb@ietf.org>; Tue, 26 Feb 2013 16:26:49 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id 15so3815932wgd.4 for <rtcweb@ietf.org>; Tue, 26 Feb 2013 16:26:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Yfd/830dADpSRM0VVzoxX5o9ffpt56zZPRwFrpBH+mQ=; b=gx8wE2qjep+GAi7jo4LdPsiymIhRhZgRRjZTmn7MOPlGLKs4wgguEJjdhFNvFhfcwl tEZSGO4texyJYmwg2sAY0wuwIjYgmWK5aUuviLHTemZxs9xUsrG4Nygk5VwLX0YCcnQ4 wKdIgxcgd6CzoAZxyTbC0DWrQjl2S9rgw7tu1EJbZq7Kn1pMBc2FUkeyclBk8x+TYQ7B BfTY6zBiXFjkBCIPmAXJl1npD3y7CGaDYlIHwWqaQ+tJzZ4r6kFS5tn4Ip27obwioom3 ZS1cb1c7dDYZgiuC2laPlIsLRpMlbVVl96aK1thTMOZCWOitrn+/8eS4nqBYiKSl58IB yo7A==
MIME-Version: 1.0
X-Received: by 10.194.76.37 with SMTP id h5mr379865wjw.21.1361924809138; Tue, 26 Feb 2013 16:26:49 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Tue, 26 Feb 2013 16:26:49 -0800 (PST)
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE224023E19@xmb-rcd-x02.cisco.com>
References: <20130225182705.666.1653.idtracker@ietfa.amsl.com> <E721D8C6A2E1544DB2DEBC313AF54DE224023E19@xmb-rcd-x02.cisco.com>
Date: Tue, 26 Feb 2013 16:26:49 -0800
Message-ID: <CABkgnnXkBSTNPDw-e=RMOU9UsucPeQyFya6w0R83CZvUqww_-A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt
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, 27 Feb 2013 00:26:54 -0000

Hi Muthu,

There's a little too much economy in the draft: the draft doesn't
define precisely what a 'STUN Transaction' entails.

I can't remember if this was discussed much, but we did discuss the
effect of just having Tc with respect to routing flaps (maybe it was
off-list).  Because we are winding timers for ICE down and shortening
the overall process to just a few seconds (or less for consent), there
is a real chance that a transitory failure could accidentally trigger
consent failure handling unnecessarily.

In any case, the suggested solution to that was to not send a
controlled burst of STUN Binding requests, but to instead send them
continuously at a measured interval.  Several missed responses would
be required in order to fail the flow.  As an example, with Tc = 32s,
sending a new request every 10 seconds would make the flow far more
reliable.

Similarly, the application-requested interval needs to send just a
single packet, lest more "robust" transaction handling cause
overlapping.  Any API that is specified (none yet!) should make it
clear that applications need to expect the occasional missed packet
and not do anything drastic as a result.

On 26 February 2013 07:06, Muthu Arul Mozhi Perumal (mperumal)
<mperumal@cisco.com> wrote:
> WG,
>
> This draft was presented in RTCWEB during IETF 83.5 and 84 and was discussed earlier in the BEHAVE and RTCWEB mailing lists. Most of the comments received and consensus reached so far have been incorporated (as a result the draft has been trimmed). It now also has a section on the W3C API implications.
>
> Is the draft heading in the right direction? Given that it just describes a STUN usage for performing consent freshness and liveness test and provides recommendations for the W3C APIs, would RTCWEB be a better home for this draft?
>
> Comments welcome.
>
> - Authors
>
> -----Original Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Monday, February 25, 2013 11:57 PM
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-muthu-behave-consent-freshness-03.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>         Title           : STUN Usage for Consent Freshness
>         Author(s)       : Muthu Arul Mozhi Perumal
>                           Dan Wing
>                           Ram Mohan Ravindranath
>                           Hadriel Kaplan
>         Filename        : draft-muthu-behave-consent-freshness-03.txt
>         Pages           : 7
>         Date            : 2013-02-25
>
> Abstract:
>    Verification of peer consent before sending traffic is necessary in
>    WebRTC deployments to ensure that a malicious JavaScript cannot use
>    the browser as a platform for launching attacks.  A related problem
>    is session liveness.  WebRTC applications may want to detect
>    connection failure and take appropriate actions.  This document
>    describes a STUN usage that enables a WebRTC browser to perform the
>    following on a candidate pair ICE is using for a media component
>    after session establishment:
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-muthu-behave-consent-freshness-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-muthu-behave-consent-freshness-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb