On Fri, Jan 11, 2019 at 04:27:24AM -0800, Eric Dumazet wrote:
> On Fri, Jan 11, 2019 at 4:21 AM Michal Kubecek <mkube...@suse.cz> wrote:
> >
> > On Fri, Jan 11, 2019 at 02:57:39AM -0800, Eric Dumazet wrote:
> > > On 01/10/2019 02:22 PM, Florian Westphal wrote:
> > > > Tom Herbert <t...@herbertland.com> wrote:
> > > >> I couldn't find any mention of the advisory in the commit logs or
> > > >> netdev discussion, and apparently there's no protocol requirement that
> > > >> intermediate fragements need to be at least minimal MTU. Maybe this
> > > >> patch should be reverted?
> > > >
> > > > Currently ipv6 reasm doesn't use rbtree infrastructure, so it would
> > > > have to be converted first.
> > >
> > > <quote>
> > > Section 4.5 of RFC 8200 allows for sending any fragment for
> > > fragments as long they add up to the original packet.
> > > </quote>
> > >
> > > I do not believe we need an rbtree to implement this idea.
> >
> > IMHO Florian meant that allowing arbitrarily small fragments would harm
> > resistance against FragmentSmack type attacks so that we might need
> > rbtree based queues to be reasonably safe.
> >
>
> I fail to see why.
>
> Adding a fragment to the tail of the list is O(1), whatever of its size.
>
> If we ever receive a 'too small for IPv6' fragment not at the tail,
> we would immediately discard the whole datagram in O(1) as well.
>
> rbtree was needed because we assumed that we needed to allow IPv4 to
> receive arbitrary fragments.
My understanding of the original e-mail was that our assumption that
only last IPv6 fragment is allowed to be shorter than 1280 bytes (which
commit 0ed4229b08c1 ("ipv6: defrag: drop non-last frags smaller than min
mtu") is based on) was wrong and we should probably revert that commit.
How do you understand it?
Michal Kubecek
