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

[Martin Thomson <[e-mail]>]

On 20 November 2014 06:28, Christer Holmberg
<[e-mail]> wrote:
> I agree that we don't need to specify application behaviour. But, I think we do need to be clear regarding the impacts on the transport/ICE layer, when/if/how it can be later re-used etc.

How is my response unclear exactly?  IF NOT connectivity check, then
NO DON'T SEND.

> My question is how/if the consent lost impacts "normal" ICE (STUN keep-alives etc), transport layer heartbeats etc.

I don't understand this concern.  You can't use the credentials (see
above), and you can't send anything else.  That's a terminal
condition.

> Also, as the entity may still receive media on the 5-tuple, that also means it still have to respond to incoming STUN requests etc.

This is one of those "application layer" things.  If you want to cease
your own consent in response to losing consent, that's your choice.
We already say that connectivity check responses (connectivity checks
as a whole, actually) aren't subject to consent.

Though there is a real mistake in the draft here:

OLD:
   An endpoint MUST NOT send paced STUN connectivity checks toward any
   transport address unless the receiving endpoint consents to receive
   data.  That is, no application data (e.g., RTP or DTLS) can be sent
NEW:
   An endpoint MUST NOT send data other than paced STUN connectivity
checks or responses toward any
   transport address unless the receiving endpoint consents to receive
   data.  That is, no application data (e.g., RTP or DTLS) can be sent

I'll generate a PR if my co-authors don't get to it.  I don't know how
that happened.

> What about DTLS heartbeats, and other information sent on the transport layer? I ASSUME the entity will maintain those, as it still may receive media

That is unquestionably application-layer data.

The upshot here is that you will probably break RTP because you can't
generate an RR.  You can't generate SCTP acknowledgements either.
Fact is, virtually all protocols are bidirectional and will break if
one party can't send.