netdev - Re: [PATCH net-next 00/23] netfilter: flowtable enhancements

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:   Thu, 11 Mar 2021 22:45:05 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netfilter-devel@...r.kernel.org, davem@...emloft.net,
        netdev@...r.kernel.org, Felix Fietkau <nbd@....name>
Subject: Re: [PATCH net-next 00/23] netfilter: flowtable enhancements

On Thu, Mar 11, 2021 at 12:47:05PM -0800, Jakub Kicinski wrote:
> On Thu, 11 Mar 2021 01:35:41 +0100 Pablo Neira Ayuso wrote:
> > The following patchset augments the Netfilter flowtable fastpath to
> > support for network topologies that combine IP forwarding, bridge,
> > classic VLAN devices, bridge VLAN filtering, DSA and PPPoE. This
> > includes support for the flowtable software and hardware datapaths.
> > 
> > The following pictures provides an example scenario:
> > 
> >                         fast path!
> >                 .------------------------.
> >                /                          \
> >                |           IP forwarding  |
> >                |          /             \ \/
> >                |       br0               wan ..... eth0
> >                .       / \                         host C
> >                -> veth1  veth2  
> >                    .           switch/router
> >                    .
> >                    .
> >                  eth0
> > 		host A
> > 
> > The bridge master device 'br0' has an IP address and a DHCP server is
> > also assumed to be running to provide connectivity to host A which
> > reaches the Internet through 'br0' as default gateway. Then, packet
> > enters the IP forwarding path and Netfilter is used to NAT the packets
> > before they leave through the wan device.
> > 
> > The general idea is to accelerate forwarding by building a fast path
> > that takes packets from the ingress path of the bridge port and place
> > them in the egress path of the wan device (and vice versa). Hence,
> > skipping the classic bridge and IP stack paths.
> 
> And how did you solve the invalidation problem?

The flowtable fast datapath is entirely optional, users turn it on via
ruleset. Users also have full control on what flows are added to the
flowtable datapath and _when_ those flows are added to the flowtable
datapath, *it's highly configurable*. The main concern about the
previous caches that have were removed from the kernel (such as the
routing table cache) are that:

1) Those mechanisms were enabled by default.
2) Configurability was completely lacking, you can just enable/disable
   the cache.

If a user consider that the invalidation problem is a real concern,
then they can just opt out from adopting the flowtable solution by
now. Cache invalidation is not a requirement in the scenarios where
this is planned to be deployed at this stage.

I can extend the documentation to describe the invalidation problem in
a follow up patch and to explicit state that this is not addressed at
this stage.