RE: Non-Last Small IPv6 Fragments

[Ron Bonica <[e-mail]>]

Erik,

Thanks for the response.

So, I understand that if I were to launch a stream of such packets at a target:


  *   The target might drop many of the attack packets (but that’s ok)
  *   The target would still process non-fragmented packets at a reasonable speed
  *   The target would still be able to reassemble fragments that are from other sources and not part of the attack

If this is the case, we have nothing to worry about.

                                                          Ron


From: Erik Kline <[e-mail]>
Sent: Thursday, January 10, 2019 2:42 PM
To: Ron Bonica <[e-mail]>
Cc: Bob Hinden <[e-mail]>; Timothy Winters <[e-mail]>; IPv6 List <[e-mail]>
Subject: Re: Non-Last Small IPv6 Fragments

On Thu, 10 Jan 2019 at 11:32, Ron Bonica <[e-mail]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc815&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=-dVqPKvvhh60cA1adnmR9mFsqrX0ADki0K4BlrOQqGc&s=6m7aXa5azbXR0bSACw5GJgOfJx06tbs_1LydP-h2aqs&e=>

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.