[secdir] secdir review of draft-ietf-rmcat-cc-requirements-05

<Steve.Hanna@infineon.com> Fri, 15 August 2014 11:24 UTC

Return-Path: <steve.hanna@infineon.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3F51A8A4C; Fri, 15 Aug 2014 04:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.568
X-Spam-Level:
X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEpSX0qQVf72; Fri, 15 Aug 2014 04:24:03 -0700 (PDT)
Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614BD1A8A4B; Fri, 15 Aug 2014 04:24:02 -0700 (PDT)
X-SBRS: None
Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Aug 2014 13:24:01 +0200
Received: from MUCSE604.infineon.com (mucltm02.eu.infineon.com [172.23.8.249]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Fri, 15 Aug 2014 13:23:59 +0200 (CEST)
Received: from MUCSE604.infineon.com (172.23.7.105) by MUCSE604.infineon.com (172.23.7.105) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 15 Aug 2014 13:23:58 +0200
Received: from MUCSE592.eu.infineon.com (172.23.7.81) by MUCSE604.infineon.com (172.23.7.105) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Frontend Transport; Fri, 15 Aug 2014 13:23:58 +0200
Received: from MUCSE503.eu.infineon.com ([169.254.4.21]) by MUCSE592.eu.infineon.com ([172.23.7.81]) with mapi id 14.03.0174.001; Fri, 15 Aug 2014 13:23:58 +0200
From: <Steve.Hanna@infineon.com>
To: <iesg@ietf.org>, <secdir@ietf.org>, <draft-ietf-rmcat-cc-requirements.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-rmcat-cc-requirements-05
Thread-Index: Ac+4bxM+fJONFVq7SleKDBCPx2Xp/AAC/ctw
Date: Fri, 15 Aug 2014 11:23:57 +0000
Message-ID: <A7E2001450CF0F418D9517358C5A1D7AA7F941@MUCSE503.eu.infineon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [172.23.7.102]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_06A1_01CFB859.DECAB360"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YZP9ncng3JhPI63iS89hmmyjIjE
Subject: [secdir] secdir review of draft-ietf-rmcat-cc-requirements-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Aug 2014 11:24:06 -0000

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