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

Bob Briscoe <bob.briscoe@bt.com> Wed, 17 September 2014 14:32 UTC

Return-Path: <bob.briscoe@bt.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 AAA9D1A0494; Wed, 17 Sep 2014 07:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.253
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY4Uprrk20qS; Wed, 17 Sep 2014 07:32:49 -0700 (PDT)
Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD501A0489; Wed, 17 Sep 2014 07:32:48 -0700 (PDT)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 17 Sep 2014 15:33:02 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 17 Sep 2014 15:32:46 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 17 Sep 2014 15:32:46 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s8HEWiw4030083; Wed, 17 Sep 2014 15:32:44 +0100
Message-ID: <201409171432.s8HEWiw4030083@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 17 Sep 2014 15:32:42 +0100
To: Donald Eastlake <d3e3e3@gmail.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <CAF4+nEHEs_9fB1NR6DRoetOirJ7=NS_=SrWnzkCp85+r+0-41w@mail.g mail.com>
References: <CAF4+nEHEs_9fB1NR6DRoetOirJ7=NS_=SrWnzkCp85+r+0-41w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wJ6rvXUTfYEQJu1l1lUEJz5DwFA
X-Mailman-Approved-At: Wed, 17 Sep 2014 07:33:57 -0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-conex-abstract-mech.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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: Wed, 17 Sep 2014 14:32:51 -0000

Donald,

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

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



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

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

Cheers



Bob


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

________________________________________________________________
Bob Briscoe,                                                  BT