[RFC] back on nf_tables (plus compatibility layer)

[RFC] back on nf_tables (plus compatibility layer)

[Pablo Neira Ayuso]

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.

Re: [RFC] back on nf_tables (plus compatibility layer)

[Jan Engelhardt]

On Thursday 2012-10-25 19:06, Pablo Neira Ayuso wrote:

>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. [...]
>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.
>[...]
>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.

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 :)

Re: [RFC] back on nf_tables (plus compatibility layer)

[Pablo Neira Ayuso]

On Fri, Oct 26, 2012 at 12:02:56AM +0200, Jan Engelhardt wrote:
> On Thursday 2012-10-25 19:06, Pablo Neira Ayuso wrote:
> 
> >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. [...]
> >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.
> >[...]
> >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.
> 
> 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

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.

Re: [RFC] back on nf_tables (plus compatibility layer)

[Jan Engelhardt]

On Friday 2012-10-26 13:04, Pablo Neira Ayuso wrote:
>> 
>> 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
>
>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.

Re: [RFC] back on nf_tables (plus compatibility layer)

[Pablo Neira Ayuso]

On Wed, Oct 31, 2012 at 02:50:27PM +0100, Jan Engelhardt wrote:
> 
> On Friday 2012-10-26 13:04, Pablo Neira Ayuso wrote:
> >> 
> >> 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
> >
> >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.

Re: [RFC] back on nf_tables (plus compatibility layer)

[Jan Engelhardt]

On Wednesday 2012-10-31 16:42, Pablo Neira Ayuso wrote:
>> >> 
>> >> 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
>> >
>> >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.

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.