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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

It is discussed in section 4 of the draft
<snip>
   An endpoint that is not sending any application data does not need to
   maintain consent.  However, not sending any traffic could cause NAT
   or firewall mappings to expire.  Furthermore, having one peer unable
   to send is detrimental to many protocols.  Absent better information
   about the network, if an endpoint needs to ensure its NAT or firewall
   mappings do not expire, it can be done using keepalive or other
   techniques (see Section 10 of [RFC5245]<http://tools.ietf.org/html/rfc5245#section-10> and see [RFC6263<http://tools.ietf.org/html/rfc6263>]).
</snip>

-Tiru

From: rtcweb [mailto:[e-mail]] On Behalf Of Bernard Aboba
Sent: Friday, May 22, 2015 10:24 AM
To: Christer Holmberg
Cc: [e-mail]; The IESG
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

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