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

[Martin Thomson <[e-mail]>]

It is really hard following these threads, but it looks like this is being
over-thought.

"This document defines what it takes to obtain, maintain, and lose consent
to send. Consent to send applies to a single 5-tuple. What applications
choose to do with this information is not described in this document."

Add that to the introduction perhaps. We run the risk of expanding scope
otherwise.

As for the question of re-acquisition of consent, I think that we should
keep it simple. For this:

"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 at least, is needed to obtain consent to send."

Better to keep the rule simple, and we don't want to leave an option open
for a packet-drop-based attack here.

And one more thing ...

On Nov 19, 2014 6:41 PM, "Ram Mohan R (rmohanr)" <[e-mail]> wrote:
> >>>
> >>>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.

I think that we should consider akeep alive as application data, and
subject to to rules of consent.

The text should note that firewall and NAT bindings could be lost, instead.