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

[Christer Holmberg <[e-mail]>]

Hi,

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

So, we need to add text explicitly saying that the credentials can no longer be used, once consent has expired. That makes it clear that one cannot simply "wait for a while", and then start sending media again...

> 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

Looks good.

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

So, adding a few words about that would be useful, to inform people. Because, as you say, expired consent for sending media will often cause trouble also for received media.

Regards,

Christer