Re: [PATCH nft] src: ingress inet support

[Pablo Neira Ayuso <pablo@netfilter.org>]

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

On Wed, Oct 14, 2020 at 08:47:25PM +0200, Pablo Neira Ayuso wrote:
> Hi Arturo,
> 
> On Wed, Oct 14, 2020 at 05:54:13PM +0200, Arturo Borrero Gonzalez wrote:
> > On 2020-10-13 13:38, Pablo Neira Ayuso wrote:
> > > Add support for inet ingress chains.
> > > 
> > >  table inet filter {
> > >         chain ingress {
> > >                 type filter hook ingress device "veth0" priority filter; policy accept;
> > >         }
> > > 	chain input {
> > > 		type filter hook input priority filter; policy accept;
> > > 	}
> > > 	chain forward {
> > > 		type filter hook forward priority filter; policy accept;
> > > 	}
> > >  }
> > 
> > This sound interesting, thanks.
> > 
> > I could see some questions coming from users:
> > 
> > * where are the docs on which packet/traffic sees this nft family vs netdev?
> > * what are the added benefit of this nft family vs netdev?
> 
> See patch update for documentation, let me know if this addresses
> these two questions. I can extend it further, let me know.
> 
> > * is the netdev family somehow deprecated?
> 
> I don't think so. The netdev family is still useful for filter packet
> of any possible ethertype that are entering through a given device
> (for instance ARP, 802.1q, 802.1ad among others). The only difference
> between inet ingress and netdev ingress is that the sets and maps that
> are defined in a given inet table can be accessed from the ingress
> chain, note that it is not possible to access inet sets and maps from
> the netdev ingress chain.
> 
> If your ruleset if focused on traffic filtering for IPv4 and IPv6,
> then inet ingress should be enough.
> 
> The ingress netdev chain also comes with hardware offload support,
> which allows you to drop packets from the NIC, which might be useful
> in DoS scenarios to save CPU cycles. You only have to check if your
> NIC is supported.

Forgot attachment to update documentation, I can possibly include this
information I mentioned above too.

[-- Attachment #2: x.patch --]
[-- Type: text/x-diff, Size: 2728 bytes --]

diff --git a/doc/nft.txt b/doc/nft.txt
index 5326de167de8..02aefb1589e6 100644
--- a/doc/nft.txt
+++ b/doc/nft.txt
@@ -217,6 +217,10 @@ Packets forwarded to a different host are processed by the forward hook.
 Packets sent by local processes are processed by the output hook.
 |postrouting |
 All packets leaving the system are processed by the postrouting hook.
+|ingress |
+All packets entering the system are processed by this hook. It is invoked before
+layer 3 protocol handlers, hence before the prerouting hook, and it can be used
+for filtering and policing. Ingress is only available for Inet.
 |===================
 
 ARP ADDRESS FAMILY
@@ -242,15 +246,18 @@ The list of supported hooks is identical to IPv4/IPv6/Inet address families abov
 
 NETDEV ADDRESS FAMILY
 ~~~~~~~~~~~~~~~~~~~~
-The Netdev address family handles packets from ingress.
+The Netdev address family handles packets from the device ingress path. This
+family allows you to filter packets of any ethertype such as ARP, VLAN 802.1q,
+VLAN 802.1ad (Q-in-Q) as well as IPv4 and IPv6 packets.
 
 .Netdev address family hooks
 [options="header"]
 |=================
 |Hook | Description
 |ingress |
-All packets entering the system are processed by this hook. It is invoked before
-layer 3 protocol handlers and it can be used for early filtering and policing.
+All packets entering the system are processed by this hook. It is invoked after
+the network taps (ie. *tcpdump*), right after *tc* ingress and before layer 3
+protocol handlers, it can be used for early filtering and policing.
 |=================
 
 RULESET
@@ -373,7 +380,7 @@ This allows to e.g. implement policy routing selectors in nftables.
 |=================
 
 Apart from the special cases illustrated above (e.g. *nat* type not supporting
-*forward* hook or *route* type only supporting *output* hook), there are two
+*forward* hook or *route* type only supporting *output* hook), there are three
 further quirks worth noticing:
 
 * The netdev family supports merely a single combination, namely *filter* type and
@@ -381,6 +388,10 @@ further quirks worth noticing:
   to be present since they exist per incoming interface only.
 * The arp family supports only the *input* and *output* hooks, both in chains of type
   *filter*.
+* The inet family also supports the *ingress* hook, to filter IPv4 and IPv6
+  packet at the same location as the netdev *ingress* hook. This inet hook
+  allows you to share sets and maps between the usual *prerouting*,
+  *input*, *forward*, *output*, *postrouting* and this *ingress* hook.
 
 The *priority* parameter accepts a signed integer value or a standard priority
 name which specifies the order in which chains with same *hook* value are