Re: Non-Last Small IPv6 Fragments

[Erik Kline <[e-mail]>]

On Thu, 10 Jan 2019 at 11:32, Ron Bonica <[e-mail]> wrote:

> > I read some of the reports on the link, but am still not clear what the
> > underlying problem is.   Why does Linux have a problem with receving
> > intermediate fragments less than 1280?
> >
>
> Hi Bob,
>
> Might we be defending against an attack in which a packet contains:
>
> - An IPv6 header (40 bytes)
> - A Fragment Header (8 bytes)
> - A TCP header (20 bytes)
> - TCP Payload (1200 bytes)
>
> This packet doesn't need to be fragmented at all because the total length
> is only 1268 bytes. However, a mischievous source node divides the packet
> into 1200 fragments. The first fragment contains an IPv6 header, a fragment
> header, the TCP header, and one byte of the TCP payload. Each subsequent
> fragment contains the IPv6 header, a fragment header, and one byte of TCP
> payload.
>
> Are reassembly algorithms clever enough to protect against such attacks?
> If so, I don't see the problem either. But if not, we may have a problem.
>

I'm recently familiar with an IPv6 fragment reassembly implementation, as
it turns out.  The core implementation uses/makes liberal reference to:

    https://tools.ietf.org/html/rfc815

It works generally in terms of managing a hole descriptor list.  It would
successfully reassemble the sequence of packets you describe.  Whether
that's an "attack" or not, I don't really see it.  With local policy caps
on the lifetime of unreassembled fragment bits and so on, it seems possible
to limit and manage the total resources allocated to reassembly.