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

[Christer Holmberg <[e-mail]>]

Hi,

>>"A while ago, we agreed that consent does not need to be maintained on candidate pairs that aren't currently used."
>
>[BA] If the specification were to say that consent is required once media is sent, then this would logically follow.

Or, WHILE media is sent :) Because, if you stop sending media on a pair (e.g. because you switch to another pair), you can also stop doing consent, but that doesn’t mean consent will be lost.

>>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).
>
>[BA] I agree. As long as it can obtain consent on the new pair (without having to update the ufrag/pwd), it should be fine.

It could even be an old pair, on which the UA previously sent media, but then switched to another pair (for whatever reason).

>>So, consent is lost if the UA sends consent requests, and does not receive a response.
>
>[BA] Consent is lost for that candidate pair, and that pair alone.

Correct.

>If connectivity checks are being done on an unused candidate pair (as advocated in Justin's nombis draft), the
>consent mechanism does not apply until media is sent on that pair.  So you can't revoke consent on a candidate
>pair if media isn't being sent on the pair.

Correct.

Of course, if you want to maintain the pair, you still have to send keep-alives, but that’s a separate story :)

Regards,

Christer



On Thu, May 21, 2015 at 8:55 PM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
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