Re: [RFC Draft PATCHv2 net-next] Doc: update bridge doc

[Hangbin Liu <liuhangbin@gmail.com>]

Thanks Florian, very appreciate for your comments. I'm not familiar with
the bridge netfilter history and usage. I will summary and update the doc
with your comments in next version(with the other's comments).

Hope you could review it again.

Regards
Hangbin

On Fri, Oct 27, 2023 at 02:31:30PM +0200, Florian Westphal wrote:
> Hangbin Liu <liuhangbin@gmail.com> wrote:
> 
> [ cc nf-devel ]
> 
> > The current bridge kernel doc is too old. It only pointed to the
> > linuxfoundation wiki page which lacks of the new features.
> 
> Indeed, thanks for taking time to improve the documention.
> 
> > +Netfilter
> > +=========
> > +
> > +The bridge netfilter module allows packet filtering and firewall functionality
> > +on bridge interfaces. As the Linux bridge, which traditionally operates at
> > +Layer 2 and connects multiple network interfaces or segments, doesn't have
> > +built-in packet filtering capabilities.
> 
> No, this is not what this module does.  br_netfilter module should NEVER
> be used.  I'd love to remove it, but its very popular unfortunately.
> 
> Suggestion:
> 
> The bridge netfilter module is a legacy feature that allows to filter bridged
> packets with iptables and ip6tables.  Its use is discouraged.  Users
> should consider using nftables for packet filtering.
> 
> The older ebtables tool is more feature-limited compared to nftables, but
> just like nftables it doesn't need this module either to function.
> 
> The br_netfilter module intercepts packets entering the bridge, performs
> minimal sanity tests on ipv4 and ipv6 packets and then pretends that
> these packets are being routed, not bridged.  br_netfilter then calls
> the ip and ipv6 netfilter hooks from the bridge layer, i.e. ip(6)tables
> rulesets will also see these packets.
> 
> br_netfilter is also the reason for the iptables 'physdev' match:
> This match is the only way to reliably tell routed and bridged packets
> apart in an iptables ruleset.
> 
> Side note:
> 
> You might want to somehow massage the bits below, perhaps it would be
> good to have the historical context as to why br_netfilter exists in the
> first place.
> 
> > +With bridge netfilter, you can define rules to filter or manipulate Ethernet
> > +frames as they traverse the bridge. These rules are typically based on
> > +Ethernet frame attributes such as MAC addresses, VLAN tags, and more.
> > +You can use the *ebtables* or *nftables* tools to create and manage these
> > +rules. *ebtables* is a tool specifically designed for managing Ethernet frame
> > +filtering rules, while *nftables* is a more versatile framework for managing
> > +rules that can also be used for bridge filtering.
> 
> ebtables and nftables will work fine without the br_netfilter module.
> 
> iptables/ip6tables/arptables do not work for bridged traffic because they
> plug in the routing stack.
> 
> nftables rules in ip/ip6/inet/arp families won't see traffic that is
> forwarded by a bridge either, but thats very much how it should be.
> 
> br_netfilter is only needed if users, for some reason, need to use
> ip(6)tables to filter packets forwarded by the bridge, or NAT bridged
> traffic.
> 
> Historically the feature set of ebtables was very limited (it still is),
> so this module was added to pretend packets are routed and invoke the
> ipv4/ipv6 netfilter hooks from the bridge so users had access to the
> more feature-rich iptables matching capabilities (including conntrack).
> 
> nftables doesn't have this limitation, pretty much all features work
> regardless of the protocol family.
> 
> > +The bridge netfilter is commonly used in scenarios where you want to apply
> > +security policies to the traffic at the data link layer. This can be useful
> > +for segmenting and securing networks, enforcing access control policies,
> > +and isolating different parts of a network.
> 
> See above, for pure link layer filtering, this module isn't needed.