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

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 27 February 2013 07:06 UTC

Return-Path: <mperumal@cisco.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 DBD9E21F87FB for <rtcweb@ietfa.amsl.com>; Tue, 26 Feb 2013 23:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.293
X-Spam-Level:
X-Spam-Status: No, score=-8.293 tagged_above=-999 required=5 tests=[AWL=2.307, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 qLKd80s+s2td for <rtcweb@ietfa.amsl.com>; Tue, 26 Feb 2013 23:06:02 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9E24D21F87D3 for <rtcweb@ietf.org>; Tue, 26 Feb 2013 23:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8232; q=dns/txt; s=iport; t=1361948762; x=1363158362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zr3J8uuQcu8ZEEIX+d6Kq8C/koYAkq8KkLN4B790mqY=; b=bSXmriakWa13SEzWmXhePCznMIgsZT3lfrm5sZUCW40LGnfKxakiSWv+ HWZo6NaoR3WBubni/rcORBDRZ0wCi1uvFuG+/XHxYtr2UbKKEIo0TSNz0 lbWP9TLjRbDWY1I4d86sy6/B+Ibx1YpULjE7ztX08r6/nDixWl5E/LQGK 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FACuvLVGtJV2Y/2dsb2JhbABFg3iCV7tIDXQWc4IfAQEBBAEBASAROgsMBAIBCBEEAQEDAgYdAwICAh8GCxQBBwEIAgQOBQgBEodmAw8HBawuiF8NiVqBI4sZgicWEAsHBoInMmEDkn+BZIJ7ijMDhRSDCIIn
X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; d="scan'208";a="181617177"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 27 Feb 2013 07:06:02 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1R762Fj012940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Feb 2013 07:06:02 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 01:06:01 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt
Thread-Index: AQHOE4XKyq5tIRCRdE+e+ktRkS0KtZiMOJFwgAEHPID///6IUA==
Date: Wed, 27 Feb 2013 07:06:01 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE22402509E@xmb-rcd-x02.cisco.com>
References: <20130225182705.666.1653.idtracker@ietfa.amsl.com> <E721D8C6A2E1544DB2DEBC313AF54DE224023E19@xmb-rcd-x02.cisco.com> <CABkgnnXkBSTNPDw-e=RMOU9UsucPeQyFya6w0R83CZvUqww_-A@mail.gmail.com>
In-Reply-To: <CABkgnnXkBSTNPDw-e=RMOU9UsucPeQyFya6w0R83CZvUqww_-A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.39.66.200]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 07:06:04 -0000

Hi Martin,

Thanks for the feedback. The tuning of times for consent is far from finished. You are right we had an off-the-list discussion, but didn't take it forward (I'll work with you and others who were involved).

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

In its current form, the draft uses the STUN transaction as defined in RFC5389, which implies the requests are retransmitted until a response is received, or until a total of 7 requests have been sent (assuming no hard ICMP error is received). So, reporting a consent freshness failure is sufficiently guarded against transitory network failures.

However, with the default 500 ms RTO recommended in RFC5389, it would take 39.5 sec for the transaction to timeout -- this was considered too long to declare a consent freshness failure.

One option could be to define a new STUN transaction that doesn't do the exponential backoff for retransmission, but instead retransmits at periodic intervals and declare failure if there is no response after sending a bunch of them, as you are suggesting. But, I am not sure at this point how that would be both superior compared to the transaction defined in RFC5389 and sufficiently guard against transitory network failures.

|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.

Agreed.

Muthu

|-----Original Message-----
|From: Martin Thomson [mailto:martin.thomson@gmail.com]
|Sent: Wednesday, February 27, 2013 5:57 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: rtcweb@ietf.org
|Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt
|
|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