Re: Non-Last Small IPv6 Fragments

[神明達哉 <[e-mail]>]

At Thu, 10 Jan 2019 10:33:20 -0500,
Timothy Winters <[e-mail]> wrote:

> The fix was to reject IPv6 fragments less than 1280 that aren't last
> fragment.  Section 4.5 of RFC 8200 allows for sending any fragment for
> fragments as long they add up to the original packet.  This means that an
> implementation that generates a non-last fragments with a size then 1280,
> will be dropped by the updated kernel.
>
> I'm willing to write a draft about the expected behavior, but before I do
> that I wanted to get the working group feedback on if we think an
> implementation should drop non-last fragments less then 1280.

I don't see a reason why an implementation can drop such fragments.
As you pointed out, the standard protocol doesn't prohibit it.  I
would even consider it "reasonable" (not just "allowed by the
standard") if an implementation divides a 1300-octet packet into two
650-octet fragments (ignoring common header overhead for brevity)
instead of 1280 + 20, even if there's currently no implementation that
actually does that.

Looking at the description about CVE-2018-5391 in
https://lists.debian.org/debian-lts-announce/2018/08/msg00014.html
my guess is that "the attack" is to send many small fragments (perhaps
also in random order?) in an attempt of increasing the management
overhead to the level of denial of service.  If I'm correct, I see
that such a possibility of attack allows an implementation to
introduce some implementation-specific limitation, but I think
dropping non-last fragments smaller than 1280 octets goes too far for
that purpose.

--
JINMEI, Tatuya