Last Call Review of draft-ietf-rmcat-cc-requirements-05
review-ietf-rmcat-cc-requirements-05-secdir-lc-hanna-2014-08-21-00

Resending this email because I used the wrong email address for the
<draft-name>.all address. That’s @tools.ietf.org not @ietf.org.



Thanks,



Steve





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.



This document describes a set of requirements for congestion control for
interactive, point-to-point real time multimedia.



I believe this document is “Ready with issues”.



The security considerations section of this document is brief, which is OK for
a requirements document. However, I think that one sentence should probably be
added. The section says “Attacks that increase the percieved available
bandwidth are concievable, and need to be evaluated.”  While this is true (and
disregarding the spelling errors for the moment), I believe it is the most
concerning part of the security considerations section and therefore deserves
more attention. I suggest adding a sentence reflecting on the possible impact
of such attacks. For example, this sentence could be added after the one that I
just quoted: “Such attacks could result in starvation of competing flows and
permit amplification attacks.” Adding such a sentence may provide guidance to
readers who are congestion control experts not familiar with security and
therefore not likely to understand the implications of the existing, brief text.



I also noticed some nits and typos in the document.



·



The document should expand the acronym RMCAT. I realize that RMCAT expanded in
the WG name but the WG will close at some point and the document should stand
on its own.

·



“an use” => “a use” Why? See explanation at

https://owl.english.purdue.edu/owl/resource/540/01

·



“in order allow” => “in order to allow”

·



“flows competing against at” => “flows competing against it at”

·



“heirarchy” => “hierarchy”

·



“a single queue” => “a single queue.” (missing period at end of section 2)

·



“percieved” => “perceived”

·



“concievable” => “conceivable”



Overall, I would say that the quality and readability of the document is quite
high. I am only slightly familiar with congestion control but I felt that I
completely or almost completely understood the document, including the
rationale for each requirement. I cannot speak to the appropriateness of these
requirements with any authority since I lack deep understanding of RTCWeb or
congestion control but the document seems to be a high-quality, constructive
addition to the RFC series. >From a security perspective, the only need is to
add the clarifying sentence suggested above.



And I apologize for sending this review two days after the IETF LC deadline.
Still, I expect that it is not too late to include this input. The security
area directors and the authors should find it useful.



Thanks,



Steve Hanna



Attachment:

smime.p7s

Description:

 S/MIME cryptographic signature