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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBD9E21F87FB for <>; Tue, 26 Feb 2013 23:06:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.293
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qLKd80s+s2td for <>; Tue, 26 Feb 2013 23:06:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9E24D21F87D3 for <>; Tue, 26 Feb 2013 23:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="4.84,746,1355097600"; d="scan'208";a="181617177"
Received: from ([]) by with ESMTP; 27 Feb 2013 07:06:02 +0000
Received: from ( []) by (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 ([]) by ([]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 01:06:01 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Martin Thomson <>
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: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt
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, 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.



|-----Original Message-----
|From: Martin Thomson []
|Sent: Wednesday, February 27, 2013 5:57 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|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
|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)
|<> 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
|> 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: [] On Behalf Of internet-
|> Sent: Monday, February 25, 2013 11:57 PM
|> To:
|> 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:
|> There's also a htmlized version available at:
|> A diff from the previous version is available at:
|> Internet-Drafts are also available by anonymous FTP at:
|> _______________________________________________
|> I-D-Announce mailing list
|> Internet-Draft directories:
|> or
|> _______________________________________________
|> rtcweb mailing list