[secdir] SECDIR review of draft-ietf-conex-abstract-mech

Donald Eastlake <d3e3e3@gmail.com> Mon, 01 September 2014 20:36 UTC

Return-Path: <d3e3e3@gmail.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 1E2491A06FC; Mon, 1 Sep 2014 13:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.95
X-Spam-Level:
X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 idXxblIiPbEL; Mon, 1 Sep 2014 13:36:25 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E602F1A06F7; Mon, 1 Sep 2014 13:36:24 -0700 (PDT)
Received: by mail-oi0-f53.google.com with SMTP id i138so3862695oig.12 for <multiple recipients>; Mon, 01 Sep 2014 13:36:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=cHBzdflNh0rHtNmU3ZJV5SCTMw+lHTLS1KQQhTPIrs4=; b=yQs30pqqcP6lLD2ewIyTrX+aV6V3MRLTIz+FcxELnUD6FmvgK6cBU+CdBzwg0+FKET j5l0r+ACQuUqLkHWadzNN9NRPxVyRMQEd5wbx/C5NRUstt91iNSPY7XJL/duLhVYf9Q0 eV3tR2ULGxmnzHR6fIIJBTPJni+Lec/a/uC81otStErYshlSQvWsjmZ/UjQFor18FYfP Z52xujuj8QOSeZWQPkiT+IPJ9eCSM0HGyknmeKpXtoyGqVfnHvBHRoRuUZDZ2T7E74F0 JUmd7frtb/IDyHp/nSonaZcEPdevJbC319goqx/jsAyBetpdOpFUPx43SB3IyAgfmM9v Xrhg==
X-Received: by 10.60.135.233 with SMTP id pv9mr3874359oeb.75.1409603784140; Mon, 01 Sep 2014 13:36:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.20.148 with HTTP; Mon, 1 Sep 2014 13:36:03 -0700 (PDT)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 01 Sep 2014 16:36:03 -0400
Message-ID: <CAF4+nEHEs_9fB1NR6DRoetOirJ7=NS_=SrWnzkCp85+r+0-41w@mail.gmail.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-conex-abstract-mech.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/w9QReHAjCbrnFK9sIlkRMtGTVsg
Subject: [secdir] SECDIR review of draft-ietf-conex-abstract-mech
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: Mon, 01 Sep 2014 20:36:26 -0000

Hi,

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

This document describe an abstract mechanism for senders to inform a
network about congestion encountered by packets over a flow by adding
ConEx (Congestion Exposure) Signals. It is part of a set of documents
for which the entry point is RFC 6789.

Security Considerations (Ready):

>From a security considerations point of view, I think this document is
Ready for publication. It correctly identifies the main security
considerations as the robustness of congestion marking and auditing so
that malefactors cannot gain advantage from cheating. While real
security details are necessarily deferred to specific ConEx
specifications, this abstract specification document in my opinion
does a good job of discussing, in general terms, the threats and a
number of strategies to defend against them.

Comment:

I found some of the wording to be a bit confusing. For example, the
first sentence in the abstract is as follows:
   "This document describes an abstract mechanism by which senders inform
   the network about the congestion encountered by packets earlier in
   the same flow."
and the first sentence of the Introduction is very similar. But, if I
understand Figure 1 correctly, what is abstractly specified is the
addition to data flowing from from A to B of information about
congestion encountered over the entire A to B path, not "earlier in
the same flow". Perhaps my understanding is confused, but that would
also indicate a lack of clarity.

Nits:

Section 2, bottom of page 4: "... to be able apply sufficient ..." ->
"... to be able to apply sufficient ...".

In a number of Sections there are what are, in effect, sub-heading
indicated by a word or two followed by a colon and then text indented
by three spaces. In some cases, this is used with no blank lines,
which is fine. However, in other cases this indented text is has
multiple paragraphs separated by a blank line. In most such instances,
there is also a blank line before each such "sub-heading", for example
Section 5.5. But not in Section 6, which looks odd in some places as a
result. I suggest having a blank line before such sub-headings in
Section 6.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com