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
- [secdir] SECDIR review of draft-ietf-conex-abstra… Donald Eastlake
- Re: [secdir] SECDIR review of draft-ietf-conex-ab… Bob Briscoe