Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09

Mirja Kühlewind <> Tue, 22 September 2015 12:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EDECF1A6FFE; Tue, 22 Sep 2015 05:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pPCkXXq5-wgU; Tue, 22 Sep 2015 05:46:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51FF31A6FEE; Tue, 22 Sep 2015 05:46:35 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF8D9D9314; Tue, 22 Sep 2015 14:46:33 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 5kbmlc3C2GSf; Tue, 22 Sep 2015 14:46:33 +0200 (MEST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by (Postfix) with ESMTPSA id 6A733D930A; Tue, 22 Sep 2015 14:46:33 +0200 (MEST)
To: Robert Sparks <>, General Area Review Team <>,,
References: <>
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <>
Message-ID: <>
Date: Tue, 22 Sep 2015 14:46:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Sep 2015 12:46:47 -0000


regarding M1:

I don't think we can say much more in this doc than what is already said in the 
abstract mechanism doc as we simply don't know which protocol will be used on 
top of it. What we can do is to add one sentence saying that there must be a way 
in the higher layer protocol to provide feedback about congestion (loss and/or 
ECN) and that the specification for the higher layer protocol must discuss how 
an audit function in the network can access information on congestion on the 
forward path (e.g. monitoring seq#).

Further regarding the abstract mechanism doc, it says the following:

"The general goal of an auditor is to make sure that any ConEx-enabled
    traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit
    signals.  A concrete definition of the ConEx protocol MUST define
    what sufficient means."

I'm not sure if this is a correct usage of normative language, but I will 
double-check with the author of this document. However, I don't think we can say 
more about what sufficient means that it is already described in the abstract 
mechanism doc (further down in section 5.5).

It might also be the case that the authors actually meant to say here something like

"A transport that uses the ConEx protocol MUST define
    what sufficient means."

which would probably me more sensical. I'll check with them.

However, while writing these documents, we figured that we actually would need 
another document on auditing because there are some assumption that must be 
taken in the protocol design. The main purpose of that doc is/was to give 
guidance how to design an audit without caring of all the details in the 
tcp-mods doc. There is an (expired) draft (draft-wagner-conex-audit-01) which we 
did not follow because there was no energy in the wg and it was not in the 
original milestone list. We should definitely consider to revisit this draft if 
we plan further experimentation on ConEx.

Does this makes sense to you?


On 26.08.2015 22:19, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-conex-destopt-09
> Reviewer: Robert Sparks
> Review Date: 26 Aug 2015
> IETF LC End Date: 31 Aug 2015
> IESG Telechat date: 1 Oct 2015
> Summary: On the right track with open issues
> Major issues:
> M1) This document claims to specify "the ConEx wire protocol in IPv6".
> But it reads more like "this document just defines an option, other
> documents will talk about how and when the option is used".  The
> abstract-mech document requires that concrete ConEx specifications
> discuss the audit function explicitly, with several requirements for
> detail scattered through that document. In particular, it asks for a
> discussion of how the concrete protocol defends against a set of
> likely attacks against the audit function.  This document is silent,
> and I think a side-effect of being processed in parallel with
> tcp-modifications, and suspect most of the thinking on meeting the
> requirements for discussing the audit function has concentrated there.
> However, nothing in _this_ document restricts its use to other
> transport extensions that have talked about these things.  Should
> there be a statement that this option must not be used unless by a
> transport extension that's discussed how to use it?  If not, then
> shouldn't this document talk about what happens if there's no
> transport header below to inform audit function behavior?
> Minor issues:
> m1) Figure 1 isn't right. I think what you want is:
> 0                   1                   2
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  Option Type  | Option Length |X|L|E|C|  res  |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> m2) There is confusion in two places in the document where you discuss
> where to put the CDO (at the end of page 5 and the end of page 7). The
> current text says the option MUST be the first option in whatever
> destination options block it appears in. That seems problematic. What
> if some other option also declares it MUST be the first option? I
> wonder if instead of trying to say "must be the first option in the
> block" you are trying only to say "If you use a CDO, use it in the
> destination options block that comes before an AH block, not the one
> that might come after".
> m3) Third paragraph of section 6: Should the last sentence end with
> "in a given stream." ?
> Nits/editorial comments:
> Introduction: Should "Due to space limitation" be "Due to space
> limitations in the IPV4 header"?
> Section 4: Right after the definition of Reserved, there is a line
> that says "foo". What should it say instead?
> The last sentence on page 6: I don't think it's the network node that
> you are saying must be aware. Perhaps you mean designers of network
> nodes?
> At the top of page 7, you have "They MAY log". You shouldn't use a
> 2119 MAY here - it's not part of the protocol. Similarly, in section
> 6, "MAY compare the two, and MAY log" should not use 2119.
> First paragraph of section 6: "natively" is not clear. Perhaps
> replacing "will not natively copy" with "will not normally copy"?
> Second paragraph of section 6: I suggest replacing "ignore any
> CDO" with "ignore any CDO in the outer header".
> Consider moving the description of the bits in the option type field,
> particularly the chg bit, earlier in the document. Right now, the
> first mention is in the security consideration section, and most
> of the definition doesn't happen until the IANA considerations.
> It would help if it were clear what that bit was going to be before
> you ever mention AH.

Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932