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

[Bob Briscoe <[e-mail]>]

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
>>[e-mail]
>>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: [phone]
>email: [e-mail]
>------------------------------------------

________________________________________________________________
Bob Briscoe,                                                  BT