From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:47574 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933751AbeCMPeg (ORCPT ); Tue, 13 Mar 2018 11:34:36 -0400 Date: Tue, 13 Mar 2018 11:34:34 -0400 (EDT) Message-Id: <20180313.113434.1173466843045633114.davem@davemloft.net> To: fw@strlen.de Cc: nbd@nbd.name, pablo@netfilter.org, netfilter-devel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 00/30] Netfilter/IPVS updates for net-next From: David Miller In-Reply-To: <20180313134139.GD31828@breakpoint.cc> References: <4521f7bd-c63a-9d2d-bdb3-5f4db58a7ba1@nbd.name> <20180312.160119.1610465393660409111.davem@davemloft.net> <20180313134139.GD31828@breakpoint.cc> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Florian Westphal Date: Tue, 13 Mar 2018 14:41:39 +0100 > David Miller wrote: >> From: Felix Fietkau >> Date: Mon, 12 Mar 2018 20:30:01 +0100 >> >> > It's not dead and useless. In its current state, it has a software fast >> > path that significantly improves nftables routing/NAT throughput, >> > especially on embedded devices. >> > On some devices, I've seen "only" 20% throughput improvement (along with >> > CPU usage reduction), on others it's quite a bit lot more. This is >> > without any extra drivers or patches aside from what's posted. >> >> I wonder if this software fast path has the exploitability problems that >> things like the ipv4 routing cache and the per-cpu flow cache both had. > > No, entries in the flow table are backed by an entry in the conntrack > table, and that has an upper ceiling. > > As decision of when an entry gets placed into the flow table is > configureable via ruleset (nftables, iptables will be coming too), one > can tie the 'fastpathing' to almost-arbitrary criterion, e.g. > > 'only flows from trusted internal network' > 'only flows that saw two-way communication' > 'only flows that sent more than 100kbyte' > > or any combination thereof. > > Do you see another problem that needs to be addressed? Ok, that seems to constrain the exposure. We should talk at some point about how exposed conntrack itself is.