Re: Non-Last Small IPv6 Fragments

[Tom Herbert <[e-mail]>]

On Thu, Jan 10, 2019 at 10:55 AM 神明達哉 <[e-mail]> wrote:
>
> 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.
>
The patch for this in Linux was submitted Aug. 3, 2018 ("ipv6: defrag:
drop non-last frags smaller than min mtu"). The commit log or
discussiosn doesn't mention the security advisory and seems to
indicate this is more of an optimization with the assumption that
intermediate fragments must be at least 1280. It might just be a bug
that is easily reverted. I can take it up on the netdev list.

Tom

> --
> JINMEI, Tatuya
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------