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

[Martin Thomson <[e-mail]>]

On 9 June 2015 at 06:50,  <[e-mail]> wrote:
> 1)      Will misbehaving or malicious endpoints obey this? If not, what’s
> the point? If only a few polite endpoints go to the trouble of obtaining
> consent to send, I don’t see how this will solve anything.

Good actors will respect this, and that has proven sufficient to stop
congestion collapse in TCP.

ICE is already the foundation of real-time communications.  This just
patches a hole.

This will be implemented in web browsers, which means that they cannot
be used as a (sustained) DoS platform.

> 2)      Section 5.1 says “An endpoint MUST NOT send data other than the
> messages used to establish consent unless the receiving endpoint has
> consented to receive data.” This seems to be a long way from the present
> reality. How many applications implement this requirement? Or will this
> feature somehow be built into the OS?

This is already the case for all real-time implementations today.  And
it will - in effect - be part of the platform of the web when it is
made part of a browser.

> 3)      The document says that “Consent expires after 30 seconds.” And
> “Implementations SHOULD set a default interval of 5 seconds” for
> retransmitting STUN binding requests (requests for consent). If I understand
> this correctly, every pair of endpoints with an active connection will now
> exchange STUN binding request and response pairs in each direction every
> five seconds. That works out to about one packet per second transit for
> every connection. That seems like a lot of overhead. Is the benefit
> adequate?

We're talking real-time communications, where 50 packets per second
each way is the baseline.  This is a negligible increase.