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

Bob Briscoe <bob.briscoe@bt.com> Wed, 13 August 2014 19:13 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DFB1A048D for <conex@ietfa.amsl.com>; Wed, 13 Aug 2014 12:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.969
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Khjvo6sRz8II for <conex@ietfa.amsl.com>; Wed, 13 Aug 2014 12:13:12 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF131A0489 for <conex@ietf.org>; Wed, 13 Aug 2014 12:13:11 -0700 (PDT)
Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 13 Aug 2014 20:13:10 +0100
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 13 Aug 2014 20:13:09 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Wed, 13 Aug 2014 20:13:09 +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 s7DJD87W029606; Wed, 13 Aug 2014 20:13:08 +0100
Message-ID: <201408131913.s7DJD87W029606@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 13 Aug 2014 20:13:07 +0100
To: Mirja =?iso-8859-1?Q?K=FChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <53EB2D99.1070101@tik.ee.ethz.ch>
References: <201408112326.s7BNQ6Gd022734@bagheera.jungle.bt.co.uk> <53EB2D99.1070101@tik.ee.ethz.ch>
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 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/IzuqhAagYX6DZVwwKCNy1XANo6Y
Cc: Carlos Ucendo <ralli@tid.es>, ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] Review: draft-ietf-conex-destopt-06
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 19:13:16 -0000

Mirja,

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.


Bob


>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?
>
>Mirja
>
>
>On 12.08.2014 01:26, Bob Briscoe wrote:
>>Suresh, Mirja, Carlos,
>>
>>As promised at the authors mtg in Toronto, I have reviewed
>>draft-ietf-conex-destopt-06.
>>
>>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):
>><http://www.bobbriscoe.net/projects/conex/draft-ietf-conex-destopt-06-rvw-bb.doc>
>>
>><http://www.bobbriscoe.net/projects/conex/draft-ietf-conex-destopt-06-rvw-bb.pdf>
>>
>>
>>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
>>discussing).
>>
>>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
>>addressed.
>>
>>==Intro==
>>* 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
>>
>>==Requirements==
>>
>>* 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.
>>
>>==CDO==
>>
>>* 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).
>>
>>==Fast-path==
>>
>>* 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
>>abstract-mech).
>>
>>==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).
>>
>>==Tunnelling==
>>
>>* 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).
>>
>>==IANA==
>>
>>* 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.
>>
>>
>>Regards
>>
>>
>>
>>
>>Bob
>>
>>
>>
>>________________________________________________________________
>>Bob Briscoe,                                                  BT
>>_______________________________________________
>>conex mailing list
>>conex@ietf.org
>>https://www.ietf.org/mailman/listinfo/conex
>>
>
>--
>------------------------------------------
>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
>email: mirja.kuehlewind@tik.ee.ethz.ch
>------------------------------------------

________________________________________________________________
Bob Briscoe,                                                  BT