netdev - Re: [PATCH 00/30] Netfilter/IPVS updates for net-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Mar 2018 19:38:48 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     David Miller <davem@...emloft.net>
Cc:     fw@...len.de, nbd@....name, netfilter-devel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH 00/30] Netfilter/IPVS updates for net-next

Hi David,

Just for the record, this is a summary of what we have discussed so
far:

1) The existing flowtable infrastructure provides a software fast path
   that is being useful for a valid number of usecases, in particular,
   OpenWRT/LEDE developers/users are very enthusiastic about this.
   Reason for this is that they have had no other choice rather than
   loading out of tree kernel modules to enable fast forwarding paths
   before this infrastructure has been mainlined. Fortunately, now
   they have an upstream alternative that can help them get rid of those
   modules. This fast path can be enabled very easily, actually one
   single rule to select what flows follow the alternative path is
   sufficient.

2) The software flowtable implementation is not affected by the
   problems that flow/routing cache used to have. An attacker that
   cycles through all key values by sending forged packets to fill up
   the hashtable will get no entries. Ruleset policy specifies when
   to offload entries into the flowtable, users can arbitrarily
   decide when to push the flow into the flowtable, eg.

        add rule filter forward ct status assured flow offload @x

   Worst case scenario is that users need to see two packets, one on
   each direction, to be able to place a flow in the flowtable.

3) There is no hardware offload integration yet. There's a public
   patch - waiting to have a driver - that proposes ndo hooks, this
   patch is not merged upstream. The flowtable design and the hardware
   offload patch has been the result of conversations with many vendors
   that represent a wide range of networking device classes, so it is
   an individual effort by looking at one single device. Stateful
   flowtable offload has been another main topic, pipeline is going
   to stall a bit if we cannot make incremental progress towards that
   direction.

Note that this batch was coming with a patch to reduce cache footprint
of the flowtable entries, so there is already working-in-progress
targeted at improving performance of this new software fast path.
Also, preparation works to introduce iptables support has been in the
radar while working on this.

We understand, we may have have spent more time in explaining all this
in the mailing list, we are trying to amend this now. Therefore, we
can probably convince someone here to write design documentation to be
placed on the Documentation/flowtable/ directory in the next pull
request if that makes it easier for the broader audience to understand
our effort and rise concerns, if any.

Thanks.