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

Christer Holmberg <> Tue, 18 November 2014 16:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E6651A1A92 for <>; Tue, 18 Nov 2014 08:41:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E2tLDuURxwmY for <>; Tue, 18 Nov 2014 08:41:02 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8224D1A1A4E for <>; Tue, 18 Nov 2014 08:41:00 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-32-546b769ad0af
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C6.7A.24955.A967B645; Tue, 18 Nov 2014 17:40:58 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Tue, 18 Nov 2014 17:40:58 +0100
From: Christer Holmberg <>
To: "Ram Mohan R (rmohanr)" <>, "" <>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions
Thread-Index: Ac/yEUlFgzg9keX0RtqfGQOICUeeIwMelQGAAS/qitA=
Date: Tue, 18 Nov 2014 16:40:57 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6ssuwQgz2ntC2Wd+1gtFj7r53d gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4+76DraBFp+Lrv6WsDYx/lLoYOTkkBEwk Nkz+zAZhi0lcuLceyObiEBI4wigxY2k/I4SzhFGicdpuli5GDg42AQuJ7n/aIA0iAmES008s YAGxhQXyJVqPTmKHiBdInG44wwhhW0lM/XcPzGYRUJVoeNYLZvMK+EpcePkPbLGQQJHEzhfN YDangL7Eml//weYwAh30/dQaJhCbWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK4StJNG45Akr RL2exI2pU9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYn5aYb GeulFmUmFxfn5+nlpZZsYgTGycEtv1V3MF5+43iIUYCDUYmH12BbVogQa2JZcWXuIUZpDhYl cd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAMv2lZJZhXZJPEs/SfRO66yI/vJF4v Za7OeJmS6ekgvYGzPmj95qwvjswrNmdMWsO6ZPUUk/vq5W3eJZUmjwRZ7zgF/xXZdkl+ev2H lB2L1u48wx8U2P9ot0Yh85HF/b/iqw64+wdnKK0wW3Ks5qeDy44w84fP6m79UYzZYhlkf1tc XWmub4ASS3FGoqEWc1FxIgB4M3+NdAIAAA==
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: Tue, 18 Nov 2014 16:41:04 -0000


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

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

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

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

First, Consent can be used by other devices than browsers :)

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

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

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