Re: Offset Indicating option

[Libor Polčák <[e-mail]>]

Brian E Carpenter wrote:
> 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.
>

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