From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Kubecek Subject: Re: [PATCH v3 23/30] ipv6: defrag: drop non-last frags smaller than min mtu Date: Fri, 11 Jan 2019 15:21:25 +0100 Message-ID: <6909509.AEfQCu2WVp@alaris> References: <20180913145902.17531-1-sthemmin@microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Timothy Winters , Eric Dumazet , Eric Dumazet , Florian Westphal , Tom Herbert , David Miller , Peter Oskolkov To: netdev Return-path: Received: from mx2.suse.de ([195.135.220.15]:43226 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730870AbfAKOV2 (ORCPT ); Fri, 11 Jan 2019 09:21:28 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Friday, 11 January 2019 14:26 Timothy Winters wrote: > Hi Eric, > > So I understand correctly the attack that you are trying to prevent is > many small fragments from different IPs? > > The 6MAN working group has had some discussion about this topic, if > you want read some IPv6 networking prospectives. > > https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=zsYUwQTt0mA > dXdk9MN4dP-uiiag I haven't read all mails in that discussion but most seem to be missing the point. The problem is not memory consumption, we have a (runtime configurable) limit for that. The problem is that by sending many small (8 bytes) fragments of a large (up to 64 KB) packet but never finishing it, an attacker can force receiving host into using quite a lot of CPU time just by looking up the fragment queue of the partially reassembled packet. Currently, IPv6 reassembly uses a simple linear list which is fine with 1280 byte long fragments (up to ~50 of them) but not with 8 byte long ones (there could be as many as ~8000). The IPv4 reassembly code (where we cannot assume minimal size of non-last fragment) switched to rbtree (with logarithmic lookup time) exactly for this reason. > What about lowering the value of accepted fragments? to something > like 1280/2? That would be probably sufficient to mitigate the DoS attacks. Michal Kubecek