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
Request | Review of | draft-ietf-rtcweb-stun-consent-freshness |
---|---|---|
Requested revision | No specific revision (document currently at 16) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2015-06-09 | |
Requested | 2015-05-04 | |
Authors | Muthu Arul Mozhi Perumal , Dan Wing , Ram R , Tirumaleswar Reddy.K , Martin Thomson | |
I-D last updated | 2015-06-10 | |
Completed reviews |
Genart Last Call review of -12
by Meral Shirazipour
(diff)
Genart Last Call review of -13 by Meral Shirazipour (diff) Genart Last Call review of -15 by Meral Shirazipour (diff) Secdir Last Call review of -11 by Steve Hanna (diff) Opsdir Last Call review of -11 by David L. Black (diff) |
|
Assignment | Reviewer | Steve Hanna |
State | Completed | |
Request | Last Call review on draft-ietf-rtcweb-stun-consent-freshness by Security Area Directorate Assigned | |
Reviewed revision | 11 (document currently at 16) | |
Result | Has issues | |
Completed | 2015-06-10 |
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