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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
