Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions

"Ram Mohan R (rmohanr)" <> Wed, 12 November 2014 16:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 32F341A8716 for <>; Wed, 12 Nov 2014 08:16:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2Dn9MW54e6fU for <>; Wed, 12 Nov 2014 08:16:23 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDCF71A86F6 for <>; Wed, 12 Nov 2014 08:16:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6172; q=dns/txt; s=iport; t=1415808983; x=1417018583; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eoBesrnqAy8ZxF4mrQMzZcK7+/xQbTPBAazQRmWgxrM=; b=itUcxczjs3LAbE5ZkVnCohAEVziki+PthNPvF4t8IWsH3kqygKGLrpDi VxWQVEVtDngh9lbgHZ2QF4XGf3OC5MhMmYRKh4RVEftd7W1rPDfqzKu2Q N4l8ncY1wFPTDR+0qsCmsaqNCAH+i/ZX5su2LUE2U6lBHCnc/lnm0ezV+ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="95941055"
Received: from ([]) by with ESMTP; 12 Nov 2014 16:16:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id sACGGMcO012833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 16:16:22 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 10:16:21 -0600
From: "Ram Mohan R (rmohanr)" <>
To: Christer Holmberg <>, "" <>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
Thread-Index: AQHP/pP/dBCMjI/UmUKzOsZcpo+Fkg==
Date: Wed, 12 Nov 2014 16:16:21 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="euc-kr"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
X-Mailman-Version: 2.1.15
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, 12 Nov 2014 16:16:26 -0000

Hi Christer,

Thanks for your review. Please see inline

-----Original Message-----
From: Christer Holmberg <>
Date: Monday, 27 October 2014 11:40 pm
To: Cisco Employee <>, "" <>
Subject: RE: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions

>Thanks for putting together the new version! It makes a number of things
>more clear :)
>I do still have a few comments/questions (hopefully editorial ones),
>I think it would be good to explicitly clarify that, when consent expires
>on a 5-tuple/candidate pair, it does not affect other 5-tuples within the
>session. I have received questions on that, so I think some words would
>be useful to make it more clear.
>(Of course, one CAN choose to terminate the whole session if consent
>expires on a candidate pair, but that depends on application policy).

Section 4.1 5th paragraph currently has this text:

"if a valid STUN binding response
   corresponding to any STUN request sent in the last 30 seconds has not
   been received from the remote peer's transport address, the endpoint
   MUST cease transmission on that 5-tuple.²

When Consent expires it is up to the application policy to decide on what
to do. As you said it can choose to terminate the whole session or
continue sending data on other 5-tuples. In this draft we should just say
that the endpoint stops transmission on that 5-tuple for which consent
failed which is what the above text in the draft says. IMO that is

>If consent expires, and I stop sending application data, will I still
>send STUN keep-alives etc, to keep the candidate pair, NAT bindings etc
>There IS text saying:
>	"An endpoint that is not sending any application data does not need to
>   	maintain consent.  However, the endpoint needs to ensure its NAT or
>   	firewall mappings persist which can be done using keepalive or other
>   	techniques (see Section 10 of [RFC5245] and see [RFC6263])."
>However, that seems to be more related to cases where I don't intend to
>send application data to begin with.
>So, perhaps the text above can be modified, to clarify that keepalives
>etc will still be sent if consent expires.

Applications can continues to do what they were doing as part of STUN/ICE
sending STUN binding indications for NAT/FW keepalives or whatever).
 If some application wants to act on Consent expiry and do some thing it
can do so however such a thing
is not in the scope of this draft. So IMO this is outside scope of this
draft and is a application policy.

>Section 4.1. says:
>	"If the endpoint wants to send application data, it needs to first obtain
>   	consent if its consent has expired."
>If my consent has expired, is the a time period before I can try to
>obtain consent again? Can I just continue sending STUN binding requests
>even if my consent expires, and wait to obtain consent again?

After consent fails, browser notifies the java script and there should be
no mechanism available for java script to again tell the browser to start
all over again (consider a malicious java script); IMO consent can be only
be re-started with ICE-restart.

>(I obviously won't send any application data until I obtain consent
>When my consent expires, is it considered an error if I also choose to
>not receive any data? If not, I think it would be good to indicate that
>one may choose to also stop receiving data in case consent expires.

Consent check only deals with whether to send media or not. If Consent
fails it is up the application to decide on what other actions it need to
take (like stopping receiving media e.t.c)

>Assuming I send RTP and RTCP on separate 5-tuples, and consent expires on
>one of the 5-tuples. I assume that will impact both 5-tuples, and in that
>case I think it would be good to clarify.

Again this is application specific behaviour. If consent fails for one
the application can choose to stop data on related 5-tuples as well. Don’t
a need to have such a text in this draft. We will have to document several
such application behaviours
 if we start to do.