Re: [Gen-art] Gen-ART review of draft-ietf-conex-tcp-modifications

[Suresh Krishnan <[e-mail]>]

Hi Ron,
   Thanks for your review. Please find comments inline.

On 09/08/2015 12:20 PM, Ronald Bonica wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>
> Document:                                      draft-ietf-conex-tcp-modifications-09
> Reviewer:                                        Ron Bonica
> Review Date:                                  2015-09-07
> IETF LC End Date:                          2015-08-31
> IETF Telechat Date:                      2015-10-01
>
> Summary:          This document will be ready for publication as soon as the major issue (below) below is addressed.
>
> Major Issues:
>
> This document contains a normative reference to draft-ietf-conex-destopt-09. The normative reference is appropriate, because this document doesn't work at all unless the concepts described in draft-ietf-conex-destopt-09 work.
>
> I am concerned about draft-ietf-conex-destopt-09. It uses an IPv6 Destination Option to signal CONEX state to intermediate routers. However, according to RFC 2460:
>
>     "With one exception, extension headers are not examined or processed
>     by any node along a packet's delivery path, until the packet reaches
>     the node (or each of the set of nodes, in the case of multicast)
>     identified in the Destination Address field of the IPv6 header."
>
> The exception to which RFC 2460 refers is the Hop-by-hop Extension Header. Intermediate routers don't examine Destination Options.
>
> Section 5 of draft-ietf-conex-destopt-09 attempts to address this issue, but I am not sure that the argument is acceptable.

I think we can discuss this further but in my view there are no good 
solutions to this problem. There are two probable alternatives here

Hop-by-hop options: This is arguably the right way to define information 
that is inspected on intermediate nodes. But using this implies that 
there is a huge performance penalty for conex packets that hit conex 
unaware routers (basically being punted into the slow path in the best 
case, being dropped at worst). RFC7045 section 2.2 talks about this 
explicitly but this problem has been known for much longer. This will 
break requirement R-3.

Destination options: Intended for the destination of the packet, but 
capable of being read at *consenting* conex-aware network nodes. Does 
not affect nodes that are conex unaware. This is no different than a 
router that looks at a TCP port for an enforcing an ACL, right?

Let me know what you think. (Especially, we would be grateful if you 
think there is a better solution we ought to be considering that would 
meet the requirements)

Regards
Suresh