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

From: Bob Briscoe <[email-masked]>
Date: Tue, 12 Aug 2014 00:26:01 +0100

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 13 Aug 2014 11:19:21 +0200

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?

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:
> 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.
>
> * Referred to abstract-mech for requirements, explained that it would be
> hard to satisfy them all, and explained which one wasn't satisfied
> intermediate nodes MUST NOT normalise. Also, specified to treat packets
> with invalid fields like a non-ConEx-capable packet.
>
> * 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==
>
> * Suggested the section is restructured because I believe the visibility
> problem is not related to tunnel mode, but only to ESP in tunnel mode.
>
> * Suggested optional copying of CDO to outer, but also a simpler 'Do not
> copy CDO' alternative.
>
> * 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
>
>
>
> _______________________________________________
> conex mailing list
> [email-masked]
> 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: [email-masked]
------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 13 Aug 2014 20:13:07 +0100

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
>
>to a multicast address, and it SHOULD NOT even 
>include the CDO in such a packet."
>

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