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

[Christer Holmberg <[e-mail]>]

Hi Ram,

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

See my reply to Martin's e-mail.

Regards,

Christer