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

"Ram Mohan R (rmohanr)" <> Thu, 20 November 2014 04:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 76EEC1A0043 for <>; Wed, 19 Nov 2014 20:41:08 -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 GSnNNQYQrFfJ for <>; Wed, 19 Nov 2014 20:41:05 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1408F1A0041 for <>; Wed, 19 Nov 2014 20:41:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9538; q=dns/txt; s=iport; t=1416458465; x=1417668065; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vQqENM9aua4FxOWHE11VwC5W9HVBQe/NBJU+JPJbrTY=; b=fCGCOrXxsIqgWitb2SV70nXyGPZguJU0ZJb2c8ZkoyXCf9d1LNLmuKkB i9w8NRuhaWXvg7jJCPcyKEngbuwEC4IjIqO5RUgGEYps00IpPaZgAbF1D RQtDCaMZ951h7fm5HX6LVaJzUIxEMF2Qk3eOHCziIRxY0BrfOjfVASfk9 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="373747804"
Received: from ([]) by with ESMTP; 20 Nov 2014 04:41:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id sAK4f3rh005995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Nov 2014 04:41:03 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 19 Nov 2014 22:41:02 -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: AQHQBHwvJjfjOKAbZ06T7Mg5VhaLYw==
Date: Thu, 20 Nov 2014 04:41:02 +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: Thu, 20 Nov 2014 04:41:08 -0000

Hi Christer,

Please see inline

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

>In general, it seems like you want to leave out text just because it is
>"application specific". In my experience, if something is application
>specific, it should be stated. Otherwise people will argue in future
>about who is right and wrong.
>Please see inline for more.
>>>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
>I think it would be good to have some text regarding the impact on other
>5-tuples. Something like:
>"When consent expires for data sent on a given 5-tuple, the impact on
>data sent on other 5-tuples
>associated with the session is application specific. Applications might
>choose to send data on other 5-tuples,
>or they might choose to stop sending media on all 5-tuples associated
>with the session (and possibly
>terminate the session."

Sure. I will update the above text in the next revision.

>>>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 (like 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.
>Below (Q3) you say that ICE restart would be required after consent
>expiration, so I guess that means that one should NOT send keep-alives
>>>Section 4.1. says:
>>>	"If the endpoint wants to send application data, it needs to first
>>>   	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.
>First, Consent can be used by other devices than browsers :)

Sure. Agree

>Second, IF ICE-restart is required, I think the draft should state so.
>Third: IF ICE-restart is required, then I don't think keep-alives etc
>would be needed once consent expires (see Q2 above).

I take back that. It should not be ICE-restart I guess, since as per the
explanation in for
ICE-restart an endpoint may continue to send media on previously selected
5-tuple which is not the case here. In our case once Consent fails we just
stop sending media on that 5-tuple.
I guess brand new media session is required and the application has to do
offer/answer and do ICE again for that tuple.  If we go by that no
Keepalives are needed. We can add some text for that.

>>>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)
>Again, I think all these "application decisions" should be stated in the
>draft :)
>Also, if ICE restart is required in order to start sending media again,
>it seems a little strange that one would still continue to receive media.

I don’t think we can mandate applications to stop receiving media as well
if consent fails. Consent is for only sending data.

>>>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
>>5-tuple, the application can choose
>> to stop data on related 5-tuples as well. Don't see a need to have such
>>a text in this draft. We will have to
>> document several such application behaviours  if we start to do.
>See above regarding application decisions.

So I can add the below line:

"If consent fails for one 5-tuple, the application can choose
to stop data on related 5-tuples as well or continue”.