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

From: Donald Eastlake <[email-masked]>
Date: Mon, 1 Sep 2014 16:36:03 -0400

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
 [email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 17 Sep 2014 15:32:42 +0100

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

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

>result. I suggest having a blank line before such sub-headings in

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

>Donald

________________________________________________________________
Bob Briscoe,                                                  BT