Last Call Review of draft-ietf-rtcweb-stun-consent-freshness-11
review-ietf-rtcweb-stun-consent-freshness-11-secdir-lc-hanna-2015-06-10-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.



In my view, this document is Ready with Issues.



The purpose of the document is to reduce flooding attacks by defining a
standard method for WebRTC endpoints to obtain “consent to send” before sending
traffic to another endpoint and continuously while sending. I have a few
questions:



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.



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?



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?



Other than these issues, the document seems ready.



Thanks,



Steve



Attachment:

smime.p7s

Description:

 S/MIME cryptographic signature