On Fri, Jan 11, 2019 at 04:27:24AM -0800, Eric Dumazet wrote:

On Fri, Jan 11, 2019 at 4:21 AM Michal Kubecek [off-list ref] wrote:

quoted

On Fri, Jan 11, 2019 at 02:57:39AM -0800, Eric Dumazet wrote:

quoted

On 01/10/2019 02:22 PM, Florian Westphal wrote:

quoted

Tom Herbert [off-list ref] wrote:

quoted

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