back on nf_tables (plus compatibility layer)

Hi,

I've been working for a while to recover nf_tables kernel patches and to implement a compatibility layer so it can be used with existing x_tables target/match extensions. These are the main reasons that motivated me to follow this approach:

1) nf_tables already provides a netlink interface, which has been a longstanding demand from users.

2) Provide a fast path to merge this into mainstream. We'll have both iptables and nftables interfaces during some time in the Linux kernel, then remove iptables infrastructure at some point. iptables scripts would not break as we'll have the iptables emulation over nftables.

3) Regarding the compatibility layer: To provide a working command line utility with the same syntax of iptables. The idea is that users don't notice that they are working with the nf_tables kernel infrastructure. We did that during the transition from ipchains to iptables.

4) Several extensions for x_tables still need to be ported to nf_tables. With the compatibility layer, we can use non-native x_tables extensions with nf_tables until it fully provides a replacement for all existing features.

5) The compatibility layer provides a way to hook existing x_tables matches/targets with nftables. So we can use all existing features from nftables until we provide native nftables expressions / user-space code that replace them.

The compatibility layer has limitations to emulate struct ipt_entry, hookmask, protocol and inversion passed to xt->checkentry(). But this can be mostly workaround by relaxing some of the checking in kernel-space that prevent users from doing stupid things (like trying to use the TCPMSS target for non-TCP traffic / non-syn packets). In my list, the affected targets are ECN, CLUSTERIP, TCPMSS, REJECT and CT. I have some proposals on how to workaround those.

You can access the preliminary iptables over nftables code from:

http://1984.lsi.us.es/git/iptables-nftables/

The name of the utilities are xtables, xtables-save and xtables-restore.

There are several missing features in that iptables over nftables
code: -Z, -R, -E, rule insertion at position and -f are not yet working. IPv6 support is also still missing.

It requires this user-space library:

http://1984.lsi.us.es/git/libnftables/

And the following Linux kernel code with several experimental patches of mine:

http://1984.lsi.us.es/git/nf-next/log/?h=nf_tables-experiments

I see several things that need to be improved in the nftables kernel side:

1) Improve rule addition and deletion timing, currently it is not very good compared to iptables. To improve deletions I think we have to modify the current locking approach based on RCU. To improve additions, we have to improve the unique handle allocation (probably using a 64-bits handle number so we forget about wrap-arounds and we just incrementally assign new handles).

2) No built-in nat and route tables. Better allow from user-space configure one table with the nat / route property. If we provide documentation on how to use them appropriately, I would not worry too much if the user uses wrongly.

3) Add operation to obtain chain counters, following the same approach of iptables (iterate over the entire rule-set and accumulate packets and bytes, like in get_counters()).

4) Add native support for TRACE, it seems to be missing in nf_tables.

5) Changes to allow to add rules at positions and replace them, since iptables allows this.

6) To speed up packet matching, we can compile nftables expressions to some internal bytecode (that could be even compiled to native assembly instructions like Eric Dumazet did for BPF).

Several of these things can be improved while we already have this in mainline.

One final thing: nftables does not support atomic table commit. The point here is if we really need this for the emulation utility or we can live without that. Implementing atomic table replacement in nftables is not trivial. I have hard time to find this commit table feature useful.

That's all by now. By resolving most of these things and having the compatibility layer ready, we should get nftables into mainstream anytime soon IMO.

Comments welcome.

Regards.

Meanwhile, I am on xtables2 that actually reproduces the set of _really important_ features that currently are in the setsockopt iptables, like atomic table replace and atomic dump.

I have updated to the newest tree, and the first set is available in the git repository at:
git://git.inai.de/linux xt2-20121025
----------------------------------------------------------------
netfilter: xtables2: initial table skeletal functions
netfilter: xtables2: initial Netlink interface
netfilter: xtables2: chain creation and deletion
netfilter: xtables2: chain renaming support
netfilter: xtables2: transaction commit operation
netfilter: xtables2: table replace support
netfilter: xtables2: transaction abort support
netfilter: xtables2: redirect writes into transaction buffer
netfilter: xtables2: supply a revision number

 include/net/netfilter/xt_core.h                  |   48 ++
 include/uapi/linux/netfilter/Kbuild              |    1 +
 include/uapi/linux/netfilter/nfnetlink.h         |    3 +-
 include/uapi/linux/netfilter/nfnetlink_xtables.h |   52 ++
 net/netfilter/Kconfig                            |    8 +-
 net/netfilter/Makefile                           |    2 +
 net/netfilter/xt_core.c                          |  204 ++++++++
 net/netfilter/xt_nfnetlink.c                     |  602 ++++++++++++++++++++++
 net/netfilter/xt_nfnetlink.h                     |    7 +
 9 files changed, 925 insertions(+), 2 deletions(-)
 create mode 100644 include/net/netfilter/xt_core.h
 create mode 100644 include/uapi/linux/netfilter/nfnetlink_xtables.h
 create mode 100644 net/netfilter/xt_core.c
 create mode 100644 net/netfilter/xt_nfnetlink.c
 create mode 100644 net/netfilter/xt_nfnetlink.h

---snip---

with userspace
available in the git repository at:
git://git.inai.de/libnetfilter_xtables master

which contains a test utility xtnl-test to try the code paths that have been added so far on the kernel side.

Getting the locking right is sort of a time killer; I hope Eric Dumazet might get interested to have a look on that part, since he has done so much w.r.t. locking in ip_tables already :)

If you think this feature is important, checkout nf_tables and think how to integrate this prototype code that provides atomic table replacement to it.

I'd rather tinker with xt2.

You're are free spend your time on your pet project, but I warn you:
it will *extremely hard* to justify its inclusion into mainline.

As said, I don't think it makes sense to add two firewall engines/interfaces for the same thing. And the compatibility layer provides an utility with similar syntax and semantics to iptables.

You make it sound like you have already made up your mind and will not consider xtnl because you are having nft as your pet project. That would be really sad.

So, what xt2 has of this hour.

(- netlink interface obviously)
- netns support
- single table sufficiency
- is RCU'd
- atomic whole-table replace
- atomic chain-level multi-rule replace
(less to transfer over netlink between kernel<->user)
- chain-level dump (also relates to transfer size)
- packed ruleset for cache efficiency
- already has had some review from community members when it was last posted
- in-code and external documentation

Certainly there is still something to do - but so would there be for nft.