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

[Christer Holmberg <[e-mail]>]

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


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

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

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


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

Regards,

Christer