Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

[Christer Holmberg <[e-mail]>]

Hi,

...

>> After consent is lost for any reason, the same ICE credentials MUST 
>> NOT be used on the affected 5-tuple again. That means that a new 
>> session, or an ICE restart, is needed to obtain consent to send.
>>
>> [BA] The second sentence does not follow from the first. RFC 5245 
>> enables sending of media once a successful ICE connectivity check has been received.
>> If multiple successful candidate pairs have been identified, why 
>> should failure of consent on one candidate pair require an ICE restart 
>> if another operational candidate pair exists?
>
>... is needed to obtain consent to send *on that candidate pair*.
>
>There was a long discussion about this point, the conclusion of which was "use it or lose it".  This captures that >conclusion.  I can't remember the details of the discussion, but I think that it wasn't a security concern but a >robustness one.

A while ago, we agreed that consent does not need to be maintained on candidate pairs that aren't currently used. That should not be seen as lost consent (i.e. if the UA wants to start sending data on the candidate pair it should not have to do ICE restart or create a  new session).

So, consent is lost if the UA sends consent requests, and does not receive a response. Consent is NOT lost if the UA stops sending consent requests (and therefor obviously will not receive a response).

Perhaps that is clear in the draft, but if people have a different understanding it may need to be clarified :)

Regards,

Christer