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

[Bernard Aboba <[e-mail]>]

Christer said:

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

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.

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

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

[BA] I agree with your perspective, but I do think it could be made more
clear in the document.

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