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

["Ram Mohan R (rmohanr)" <[e-mail]>]

Hi Christer,

Please see inline

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

>Hi,
>
>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),
>>>though:
>>>
>>>Q1:
>>>-----
>>>
>>>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."


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


> 
>
>
>>>Q2:
>>>-----
>>>
>>>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
>>>alive?
>>>
>>>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.
>
>
>>>Q3:
>>>-----
>>>
>>>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 :)

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 http://tools.ietf.org/html/rfc5245#section-9.1.1.1 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.



>
>>>Q4:
>>>-----
>>>
>>>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?

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

>
>
>>>Q5:
>>>-----
>>>
>>>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”.

Regards,
Ram


>
>Regards,
>
>Christer
>