Re: [conex] Review: draft-ietf-conex-destopt-06

Bob Briscoe <> Wed, 13 August 2014 19:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 20DFB1A048D for <>; Wed, 13 Aug 2014 12:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.969
X-Spam-Status: No, score=-2.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Khjvo6sRz8II for <>; Wed, 13 Aug 2014 12:13:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DF131A0489 for <>; Wed, 13 Aug 2014 12:13:11 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 13 Aug 2014 20:13:10 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 13 Aug 2014 20:13:09 +0100
Received: from ( by ( with Microsoft SMTP Server id; Wed, 13 Aug 2014 20:13:09 +0100
Received: from ([]) by (8.13.5/8.12.8) with ESMTP id s7DJD87W029606; Wed, 13 Aug 2014 20:13:08 +0100
Message-ID: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 13 Aug 2014 20:13:07 +0100
To: Mirja Kühlewind <>
From: Bob Briscoe <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.56 on
Cc: Carlos Ucendo <>, ConEx IETF list <>
Subject: Re: [conex] Review: draft-ietf-conex-destopt-06
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: Wed, 13 Aug 2014 19:13:16 -0000


At 10:19 13/08/2014, Mirja Kühlewind wrote:
>Hi Bob,
>one more question: you added one paragraph on 
>multicast. I would propose to even say
>"A ConEx sender MUST NOT send a packet with the CDO to a multicast address."
>instead of
>"A ConEx sender MUST NOT send a packet with X = 1 (ConEx-capable)
>to a multicast address, and it SHOULD NOT even 
>include the CDO in such a packet."
>as you proposed. Or is there a reason to have a SHOULD?

The only reason I had was that there might in 
future be other things in a CDO (in the field 
that is currently Reserved) that are applicabile 
to multicast. If any security device vendors read 
every IETF spec, I thought it would be best not 
to cause them to programme their kit to drop 
multicast packets if they carry CDO, which would constrain evolvability.

I guess, if it is a SHOULD, it ought give an 
example of where the SHOULD does not apply, and 
my example is a bit subtle to have to explain. Up to you.


>Original I wrote the document from the point of 
>view of someone how wants to implement a 
>ConEx-aware network node. So I believe a never 
>said anyway how an end node should act. So this 
>sentence introduces a MUST for end nodes. But i 
>guess it is still needed in this document, right?
>On 12.08.2014 01:26, Bob Briscoe wrote:
>>Suresh, Mirja, Carlos,
>>As promised at the authors mtg in Toronto, I have reviewed
>>At this late stage, I prefer to suggest text, not just criticise. But
>>pls don't take this to mean I expect you to use my suggested text.
>>I had a lot of nits, so I thought it easiest to deal with these by
>>annotating the draft (using MS Word, but also supplied as PDF output):
>>I have also included all my more substantial concerns in the above
>>annotations - highlighted in yellow.
>>I've listed the major items here, as hooks if mailing list discussion is
>>needed on any of them (but see the annotations for detail before
>>My most controversial disagreement is around IPsec compatibility, which
>>we ought to spin into a separate thread if you want to discuss/argue.
>>Most of the other additions are because conex-abstract-mech says a
>>concrete protocol spec has to address specific aspects, which weren't
>>* Added scoping in Intro (solely wire protocol; specific transport
>>protocol specs will determine when specifically to set each marking,
>>e.g. conex-tcp-modifications)
>>* Standards Track -> Experimental
>>* Added subsection of intro on experiment goals: criteria for success
>>and duration
>>* Referred to abstract-mech for requirements, explained that it would be
>>hard to satisfy them all, and explained which one wasn't satisfied
>>(visibility in outer), referring to section on fast-path performance.
>>* For any text about ignoring invalid fields, explicitly said that
>>intermediate nodes MUST NOT normalise. Also, specified to treat packets
>>with invalid fields like a non-ConEx-capable packet.
>>* Specified precisely which IP header is included in the byte count.
>>* Suggested deleting example of Not-ConEx-capable packets (see separate
>>thread to conex-tcp-modifications authors about TCP pure ACKs).
>>* CDO as first destination option: changed from MUST to SHOULD (with an
>>example of when not to).
>>==Config & Management==
>>* Added section, mainly to say there is no config & mgmt (required by
>>==IPsec compatibility==
>>* Suggested ConEx counts the AH header, and the outer tunnel mode
>>header, with reasoning.
>>* Suggested the section is restructured because I believe the visibility
>>problem is not related to tunnel mode, but only to ESP in tunnel mode.
>>* Added a para about the possibility of implementing a ConEx proxy
>>(without breaking e2e authentication).
>>* Section added, to generalise from just IPsec to any IP-in-IP
>>tunnelling (particularly relevant to mobile scenarios).
>>* Suggested optional copying of CDO to outer, but also a simpler 'Do not
>>copy CDO' alternative.
>>==Security Considerations==
>>* Added lots, all pointers to where security issues are discussed in
>>other places (which is what security directorate reviewers need).
>>* I think the act bits need to be 00 not 10 to avoid ConEx packets being
>>dropped by non-ConEx nodes (including by non-ConEx receivers)? But I'm
>>willing to be corrected.
>>Bob Briscoe,                                                  BT
>>conex mailing list
>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

Bob Briscoe,                                                  BT