Re: Non-Last Small IPv6 Fragments

[Tom Herbert <[e-mail]>]

On Mon, Jan 14, 2019 at 9:04 AM Fernando Gont <[e-mail]> wrote:
>
> On 14/1/19 12:18, Tom Herbert wrote:
> >>
> >> * a stateful operation for anotherwise stateless protocol
> >>
> > Fernando,
> >
> > There is no fundamental problem with fragmentation. The core problem
> > is that some intermediate nodes are processing headers and data beyond
> > the IP and Hop-by-Hop options header.
>
> If you need to reassemble fragments in the network, or at an end system,

Fernando,

I don't know what it means to "reassemble fragments in the network".
Reassembly is specified as an operation at destination end points.
Unless there's a specification for in-network reassembly that
describes the requirements and procedures, I see no point in
considering it.

> and you're receiving packets at a very high data rate, you just cannot
> keep up with fragments. that's the Inherent problem. Yo need to keep
> packets in memory without even knowing whether they have been spoofed.
>
This has been know since fragmentation was first defined.  Host
implementations have implemented several mitigations including
lowering reassembly timeout, limiting number of reassembly states,
etc. This isn't a unique problem either, SYN attacks have many similar
characteristics, and we've learned over time how to deal with those as
well. As we learn more and identify attack vectors, such as the
aforementioned non-last tiny fragments, we can adapt the
implementation accordingly.

Tom

>
>
> > That is non-conformant with
> > RFC8200: "Extension headers (except for the Hop-by-Hop Options header)
> > are not processed, inserted, or deleted by any node along a packet's
> > delivery path". This becomes a material interoperability problem when
> > intermediate nodes take invasive action, such as dropping packets or
> > degrading the service, when they encounter protocols they don't
> > understand. This problem applies not only to fragmentation, but also
> > other extension headers, non-TCP transport protocols, and other
> > protocols outside some narrow set of typically used protocols. To fix
> > this, either non-conformant implementations should be changed to
> > conform to the standard, or the standard should be changed to conform
> > to the implementation.
>
> Please look at draft-gont-v6ops-ipv6-ehs-packet-drops. There are
> operational reasons for that. So, you need to look into the packet, but
> you cannot do it in the fast path. Hence you just drop them.
>
> Operators need to do their thing. And nobody is going to pay extra money
> to do it on the past path -- even then, it would take time for all
> current boxes to be phased out.
>
> Your argument would be on the same line with my own regarding why there
> shouldn't be any people under the line of poverty. -- that doesn't
> change facts.
>
>
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>