netdev - [PATCH net-next,RFC 0/8] connection tracking support for bridge

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-next>] [day] [month] [year] [list]

Date:   Wed,  3 Apr 2019 17:39:53 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     netfilter-devel@...r.kernel.org
Cc:     fw@...len.de, eric.dumazet@...il.com, davem@...emloft.net,
        netdev@...r.kernel.org
Subject: [PATCH net-next,RFC 0/8] connection tracking support for bridge

Hi,

This patchset provides native connection tracking support for bridge,
*this is work-in-progress RFC*.

ebtables has a very limited feature-set compared to iptables, among them
no connection tracking support. Long time ago, to overcome this
limitation, someone came up with the bridge netfilter infrastructure -
the `br_netfilter' kernel module. This module steals frames from bridge
prerouting hook, mangle them to make them look like IPv4 packets to
make iptables happy, eg. by attaching a fake dst object, then inject
them into the IP hooks, then take them back into the bridge frame layout
to call the bridge routines. Going back and forth through all the
netfilter IP and bridge hooks, not nice. In turn, this `br_netfilter'
infrastructure has been allowing users to use iptables, conntrack and
NAT for bridged frames, instead of ebtables. An iptables extension
called 'physdev' was introduced at the time to match on the bridge
interface as a way to expose some of the semantics behind this emulation
layer.

However, along time, many design problems uncovered with this
`br_netfilter' emulation, becoming a common topic of discussion.

This patchset is an initial step to introduce a replacement for this
`br_netfilter' emulation layer by introducing one of the missing
features that makes users turn on this `br_netfilter' emulation layer.

This patchset includes updates to expose two new refragmentation APIs in
order to reuse them from the bridge. The existing ip_do_fragment() calls
rely on dst objects that are not available from there, this function
also triggers refragmentation where the maximum fragment size is larger
than the device MTU, altering fragments geometry in that case, something
that a bridge should not do, among other things. I think this new
refragment infrastructure could be reused by folks with codebase away
from the classic IP stack, eg. OVS.

Comments welcome, thanks.

Pablo Neira Ayuso (8):
  net: use kfree_skb_list() from ip_do_fragment()
  net: ipv4: add skbuff fraglist split iterator
  net: ipv6: add skbuff fraglist split iterator
  net: ipv4: split skbuff into fragments transformer
  net: ipv6: split skbuff into fragments transformer
  net: ipv4: place cb handling away from fraglist iterator
  net: ipv4: place cb handling away from fragment transformer
  netfilter: bridge: add basic conntrack support

 include/net/ip.h                           |  39 +++
 include/net/ipv6.h                         |  44 +++
 net/bridge/br_private.h                    |   2 +-
 net/bridge/netfilter/Kconfig               |  14 +
 net/bridge/netfilter/Makefile              |   3 +
 net/bridge/netfilter/nf_conntrack_bridge.c | 411 +++++++++++++++++++++++++++++
 net/ipv4/ip_output.c                       | 314 +++++++++++++---------
 net/ipv6/ip6_output.c                      | 315 +++++++++++++---------
 8 files changed, 884 insertions(+), 258 deletions(-)
 create mode 100644 net/bridge/netfilter/nf_conntrack_bridge.c

-- 
2.11.0