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

Bob Briscoe <> Wed, 17 September 2014 14:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AAA9D1A0494; Wed, 17 Sep 2014 07:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.253
X-Spam-Status: No, score=-4.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GY4Uprrk20qS; Wed, 17 Sep 2014 07:32:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DD501A0489; Wed, 17 Sep 2014 07:32:48 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 17 Sep 2014 15:33:02 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 17 Sep 2014 15:32:46 +0100
Received: from ( by ( with Microsoft SMTP Server id; Wed, 17 Sep 2014 15:32:46 +0100
Received: from ([]) by (8.13.5/8.12.8) with ESMTP id s8HEWiw4030083; Wed, 17 Sep 2014 15:32:44 +0100
Message-ID: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 17 Sep 2014 15:32:42 +0100
To: Donald Eastlake <>
From: Bob Briscoe <>
In-Reply-To: <CAF4+nEHEs_9fB1NR6DRoetOirJ7=NS_=SrWnzkCp85+r+0-41w@mail.g>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on
X-Mailman-Approved-At: Wed, 17 Sep 2014 07:33:57 -0700
Cc: "" <>,, "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-conex-abstract-mech
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Sep 2014 14:32:51 -0000


Thx for the overall positive sec review, the comment and the nits 
(sorry for delay replying - I hope you can re-load state).

one response inline...

At 21:36 01/09/2014, Donald Eastlake wrote:
>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.
>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.

You've identified an ambiguity, which I think is down to the word 
'earlier'. We meant earlier in time, but I think you've 
(understandably) taken it to mean earlier in the flow along the path.

I think this will fix it:
    "This document describes an abstract mechanism by which senders inform
    the network about congestion recently encountered by packets in
    the same flow as they traversed the network."

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

OK, will do. We used the hanging indent construction in xml, but had 
to manually add blank lines, and we clearly missed some.



>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA

Bob Briscoe,                                                  BT