Subject: Offset Indicating option

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Sep 2011 15:10:02 +1300

Hi,

draft-zhang-6man-offset-option-01 proposes an idea for how to make it
easier for a node that needs to skip over an IPv6 header chain to do
so quickly, for example for flow classification or flow logging,
or (perish the thought) for payload inspection. The idea is to
avoid overhead. If you read the -00 draft, please forget about it
and read the -01 draft, which is significantly different.

-- 
Regards
   Brian Carpenter

---

From: Libor Polčák <[email-masked]>
Date: Mon, 26 Sep 2011 13:06:26 +0200

> and read the -01 draft, which is significantly different.

Hello,

I read only the -01 draft. I worked on a hardware IPv6 parser and I 
encountered the problems mentioned in the draft (jumping through the 
chain, future extension headers etc.) and I appreciate the effort of 
simplifying the processing.

However, I think that benefits of this draft might be lower than the 
security issues it will introduce. Consider a passive monitoring device 
and a case when the NH after Jump lists another protocol number than 
Next Header in the last extension header. The value in the Offset field 
can also point to incorrect location in the data (to the middle of 
extension header chain or somewhere inside the IPv6 payload).

The passive monitoring device cannot drop the packet and can only guess 
that the packet is going to be dropped by some security device or 
destination device. But what if there is no security device and the 
destination device is prepared for such packets and it will accept such 
packets? An attacker could hide connections from the probe.

If the probe is smart it may at least detect the ambiguous connections. 
In such cases the workload for processing of one packet will be higher 
than it is in present.

Unfortunately, I believe that if we want to fix extension headers we 
have to obsolete the current model and introduce a new one. For example 
allow only L4 protocol numbers in IPv6 header or a special value 
indicating that extension headers are present. Then, after IPv6 header, 
something like the data structure proposed in the I-D will follow. So 
the special header would list next extension header type, L4 protocol 
type and IPv6 payload offset. After the special header, current 
extension headers will follow in the same manner as they are constructed 
in present. The only exception will be the last header which will not 
list any next header.

I see two downsides of my example. 1) It is incompatible with current 
devices. 2) What if the length of the chain is bigger than the Offset value?

However, my proposal has also the benefit of specifying exact location 
of the fields (number of bytes behind IPv6 header). The I-D  allows 
placement of the option behind another options and consequently, the 
search for the option could be more expensive than jumping the chain. 
See for example Packet Processing at 100 Gbps and Beyond - Challenges 
and Perspectives 
(http://www.ikr.uni-stuttgart.de/printable/Content/Publications/Archive/Hg_packetprocessingat100gbps_36830.pdf).

If we continue with the draft I propose listing ACL processing as 
another application which will benefit from this mechanism.

Cheers,

Libor Polčák

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 26 Sep 2011 14:27:07 +0200

> in present. The only exception will be the last header which will not 

Hello Libor,

ich published a I-D: "IPv6 Extension Headers Reserved Space"

http://tools.ietf.org/html/draft-pfeifer-6man-exthdr-res-01

which try to address some of the problems. Introducing a new "number
model" don't work, but maybe a solution somewhere between - as presented in
the I-D - may address the problem adequate.

Cheers, Hagen

---

From: John Leslie <[email-masked]>
Date: Mon, 26 Sep 2011 10:38:49 -0400

Brian E Carpenter <[email-masked]> wrote:
> so quickly...

   Alas, Brian, this strikes me as a rather bad idea -- introducing
ambiguity and almost inviting gaming the system so that the same packet
looks different to a DPI device and the actual destination.

   IMHO, any node interested in such details of the payload should be
prepared to run at wire speed -- with a dedicated pipeline element if
anyone were so foolish as to perform this in the "backbone".

--
John Leslie <[email-masked]>

---

From: Libor Polčák <[email-masked]>
Date: Mon, 26 Sep 2011 17:09:00 +0200

> the I-D - may address the problem adequate.

Hello Hagen,

we are probably hijacking the thread little bit, but I support your 
draft. Minor correction though:

sec 1, 2nd paragraph

One exception is is the hop-by-hop -> One exception is the hop-by-hop

I am not sure if you can request IANA for specific range (someone else 
might want the same numbers at the same time). Maybe, it will be safer 
if you request 8 consecutive protocol numbers and rephrase IANA 
Considerations to something like:

This document includes a request to IANA.  The editors of this draft 
request the 8 consecutive protocol numbers IP6_EXTHDR_RESERVED_MIN till 
IP6_EXTHDR_RESERVED_MAX be reserved for uniform formated IPv6 extension 
header.

Additionally, replace numerical constants in the text with these names.

Best wishes,

Libor

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Sep 2011 09:08:45 +1300

> looks different to a DPI device and the actual destination.

I don't understand that comment. There's no ambiguity in the
packet - it may contain the option, but if it does, the option
isn't ambiguous. Any node is at liberty to ignore it, including
a DPI device that wants to inspect all the headers (which a
paranoid firewall presumably would).

> anyone were so foolish as to perform this in the "backbone".

Why? It's a design tradeoff, and the option suggests a different
tradeoff point.

    Brian

---

From: John Leslie <[email-masked]>
Date: Mon, 26 Sep 2011 18:00:44 -0400

Brian E Carpenter <[email-masked]> wrote:
>> ambiguity and almost inviting gaming the system so that the same
>> packet looks different to a DPI device and the actual destination.
> 
> isn't ambiguous.

   Isn't it? What if it points somewhere other than the actual "end of
the header chain"? Doesn't that make the packet look different to
middleboxes that use this option?

   (I'd rather not, of course, argue whether that makes the _option_
ambiguous -- IMHO it certainly makes _something_ ambiguous.)

> Any node is at liberty to ignore it, including a DPI device that
> wants to inspect all the headers (which a paranoid firewall
> presumably would).

   Absolutely -- but that doesn't "cure" ambiguity. :^(`

> Why? It's a design tradeoff, and the option suggests a different

   IMHO, tradeoffs which introduce ambiguity are _bad_ tradeoffs.

   (YMMV, I suppose, but I _really_ hope it doesn't!)