Re: Death by extension header

[Tom Herbert <[e-mail]>]

On Mon, Jul 13, 2020 at 1:02 PM Fernando Gont <[e-mail]> wrote:
>
> Hello, Tom,
>
> On 13/7/20 15:53, Tom Herbert wrote:
> [....]
> >
> > Fernando,
> >
> > draft-ietf-6man-icmp-limits-08 defines the ICMP errors for limits of
> > number of options, length of extension headers, length of extension
> > header chain, etc. However, I don't believe any default limits are
> > suggested other than the RFC8504 limits.
>
> Yep, that's what I meant.
>
>
>
> > Wrt byte length, the most interesting limit with regards to routers is
> > when the aggregate length of the header chain exceeds the size of the
> > parsing buffer in the device.
>
> Indeed.
>
>
> > As I understand it common lengths of
> > parsing buffers are 128, 256, or 512 bytes. That might suggest the
> > default minimum should be 128 bytes or maybe 256 bytes. That is, we
> > would expect that routers should be able to process IP header,
> > extension headers, and first four bytes of transport header (e.g. to
> > get ports for ECMP) fit in the parsing buffer in the first N bytes of
> > the packet. We can narrow this down if the standard is followed such
> > that routers only process the IPv6 and HBH headers, intermediate
> > destinations in a routing header only process headers through the
> > routing header, and end hosts process all options.
>
> Please see:
> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03 .
> Folks need to look deeper. SO unless the entire length of the EH chain
> is limited, this problem will be faced.
>
Fernando,

Yes, the practical limit is probably to be able to parse all IP
headers and at least four bytes of transport layer headers. There is
some ambiguity when encapsulation is present since packets may have
multiple transport layer headers in the presence of encapsulation and
whether network devices should be parsing into encapsulations (which
may not even be possible in many cases).

One comment about draft-gont-v6ops-ipv6-ehs-packet-drops-03:

"However, we note that for a long time many IPv6 implementations
failed to set the Flow Label, and ECMP and Hash-based Load-Sharing
devices also did not employ the Flow Label for performing their task."

I believe the first part of this statement has been addressed, all
major OSes set the flow label AFAIK. Hopefully, devices are migrating
to use flow labels for ECMP.


> Indeed, the longer the EH-chain length, the higher the chances of
> packets being dropped -- as per RFC7872 and others.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>