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

[Martin Thomson <[e-mail]>]

Please see https://github.com/Draft-Mafia/IETF-drafts/pull/8

On 20 November 2014 15:33, Martin Thomson <[e-mail]> wrote:
> 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.