
Nftables – A new packet classification framework - bandrami
http://developers.redhat.com/blog/2016/10/28/what-comes-after-iptables-its-successor-of-course-nftables/
======
SwellJoe
I'll take what seems to be the contrarian view and say I really like the looks
of this. There's nothing about this implementation that isn't at least as good
as what came before, and almost every aspect of it is better (sometimes
dramatically so, as in the case where you have a lot of rules).

I'm not easy to please on firewall management questions, and consider
FirewallD a step backward from plain old iptables on most fronts (though I
understand it has value in laptops and other devices that have frequently
changing networks). FirewallD is a different class of tool, of course, but it
has some overlap...many of our customers demanded FirewallD support (our
projects have a GUI for several firewall tools across Linux and the BSDs),
even though it doesn't really make a lot of sense on a server. It seems clear
that people don't love iptables unless they've been using it for years. I
don't find iptables difficult (coming from ipchains, it was a breath of fresh
air), but I understand folks who do, and this provides a clear improvement
over iptables. So, even though I don't find iptables hard, I think I'll find
this easier in a short time.

Maybe the simplification of the "standard" firewall tool will help reduce the
propagation of big firewall scripts and rule generators; I find them
distasteful in that they generate huge lists of rules, most of which have no
relevance to the deployment. So, it's often difficult to troubleshoot problems
with the firewall because there's so much crap in there.

Anyway, as others note, it does remind me of pf, which is a good thing. pf is
quite elegant and coherent (though, AFAIK, it doesn't cover all of the use
cases of iptables).

~~~
e12e
> pf is quite elegant and coherent (though, AFAIK, it doesn't cover all of the
> use cases of iptables).

Having just set up opensmtpd on Linux, and seeing how integrated pf is in such
simple tasks on openbsd - what usecases do you have in mind that iptables is
suitable for, but not pf?

Honestly curious - I generally try to stay away from iptables as I mostly run
small, private Linux servers - and I prefer just turning off services rather
than fighting the duality of listen on port X on ip n _and_ open firewall for
service y on port X for ip n. I realize å lot of complex setups does need a
bit of filtering though.

~~~
SwellJoe
I am, by no means, an expert on pf, but I strongly suspect that many of the
iptables extensions have no comparable capability in pf. Specifically, I don't
know of any deep packet inspection extensions for pf, ipsec headers (such as
authentication info) can be used for filtering decisions in iptables, iptables
has some cluster capabilities built in, iptables has DCCP congestion control
rules, and so on. iptables, like Linux itself, just has so many people working
on it, that almost anything you can think to do with it has already been done
by someone and they've created a module for it.

If you haven't run into the missing capabilities, they probably don't matter.
I'm not suggesting people who are happy with their pf firewalls should replace
them with iptables because iptables is somehow "better". It just has a lot
more users and a lot broader ecosystem because of it. To be more clear: I
don't generally use any of those features that iptables has that pf doesn't,
and I don't think most other people to either; at least no such features come
to mind. I think I have once or twice used things like the user extension in
nearly two decades of system administration.

I'm always surprised at how strong people's aversion to iptables is. It's
really not that complicated. I mean, most of the people here are writing
software in far more complex languages daily and don't consider it a huge
endeavor. iptables is a very simple declarative language, with only a few
syntactical elements, in most cases. But, I guess it doesn't look like what
folks are used to, and networking is its own category of complexity that many
people never dive into.

------
gravypod
This seems extremely complicated. I'm glad I've got ufw to fall back on.

I have no doubt that this sort of control is needed by sysadmins and such but
we need to remember: the easier you make it to break a security tool the
inherently less effective it will be. IPTables is extremely complicated from
my experience (making sure you have everything setup correctly, saving/loading
correctly, and pulling apart the lingo to see how to actually express
something you want to do). Most of the things most people want to do with a
networking tool aren't that complicated and as such I think like tools such as
ufw (and nftables) should focus on easier user interface as well as exposing
the nitty-gritty to those who need it.

~~~
JdeBP
The article has not, then, done its job of conveying to you the important
differences between the old and the new systems, such as

* the change from data structures and algorithms that are O(N) with respect to the number of individual rules to ones that are O(log N)

* elimination of a gross race condition where multiple concurrent ruleset updates by different subsystems (as can happen at, say, system bootstrap) can end up with updates simply getting silently lost

This is not user interface changes. This is actual difference in fundamental
design and implementation.

It would be interesting to see a comparison of the nftables instruction set
with other related instruction sets. It would be interesting to see how close
it is to RISC, whether it includes things like branch registers or multiple
width registers, if there is lowering to native machine code (and where that
is), and what it does and does not take from real processor ISAs including
VLIW ones.

~~~
gravypod
You shouldn't need to retcon an entire stack just because the implementation
behind some things weren't optimal. Why could this not have been done under
IPTables while maintaining compatibility with the old, already known,
command/rule set?

~~~
aseipp
> You shouldn't need to retcon an entire stack just because the implementation
> behind some things weren't optimal.

Apparently, you should. This is what the designers of iptables considered, and
did -- because, you know, they also implemented nftables.

I'm sure you are capable of lecturing them on the right way to do it, however.

> Why could this not have been done under IPTables while maintaining
> compatibility with the old, already known, command/rule set?

You should re-read the article. Almost every change adds up to a completely
different UI in the aggregate. E.g. nftables supports concepts like maps and
sets, things like rule deletion becomes simpler for users, you can have
multiple actions in rules, the kernel/userland interface is different (which
fundamentally will change how applications use it), and you have features like
rule monitoring. Why would you go through the effort of retrofitting this
stuff onto iptables UI? If anything it just adds tons of complexity to the
iptables userland implementation, which really isn't necessary at all.

There's a fairly reasonable argument to both not rock the iptables boat too
much (it's stable and well tested), and that abandoning its interface for
something more powerful and coherent, a clean slate, is the right way forward.

Furthermore, why would you do this retrofit nonsense _when iptables still
exists_? They're different stacks. If you don't want to use nftables, iptables
will still exist for a long time. It isn't going anywhere, and its
deficiencies are well known and understood. That's its own advantage, in its
own right.

------
nwmcsween
I never understood why firewall rules weren't simply a fs like procfs as most
if not all rules are tree based.

------
Hello71
It seems to me that the downside of this is that it (at least the default
output) is even harder to read than iptables.

~~~
Alupis
I think it does make a stab at making the rules a bit more "human friendly".

    
    
        iptables -A FORWARD -p tcp --dport 22 -j LOG 
        iptables -A FORWARD -p tcp --dport 22 -j DROP
    

vs:

    
    
        nft add rule filter forward tcp dport 22 log drop 
    

Less random-looking flags/switches, and more meaning to a human.

~~~
loeg
The hyphens gave a nice visual separation before.

~~~
bandrami
Agreed; I assume it would be more or less trivial to write an input filter so
you can keep your old rules.

~~~
Alupis
nftables has a built-in compatibility layer for iptables and ipv6tables rules.

------
minitech
My pointless complaint of the day: that’s a terrible title, even after you fix
the “it’s”. Just use “nftables: a successor to iptables” and stop trying to…
well, I don’t know what they were going for there.

~~~
deno
Reading your title I expect to see a dry academic article. Their title sounds
like, well… a blog post.

I would propose this title instead:

> What comes after iptables? Meet nftables.

~~~
minitech
Sure, anything that’s not “What comes after iptables? The thing that comes
after iptables that I won’t name”.

~~~
angry_octet
Obviously nothing should come after iptables because the last rule should be
drop all.

------
jonathonf
Surely it should be `jqtables` ?

(Yes, it's netfilter...)

------
api
Sooner or later they'll get around to integrating this into systemd.

/jk

...hopefully...

~~~
Alupis
It's actually well integrated into the kernel (just like iptables).

Any userland applications that manage nftables could, I suppose, integrate
with systemd. However, I don't see how that's really a downside.

~~~
bandrami
The downside will be if the only interface the kernel exposes for it is some
dbus thing because that's all systemd needs.

~~~
Alupis
I guess I just don't see why it would be any different than current-day
iptables.

nftables is made by the same people as iptables, and both are heavily
integrated into the kernel (this is what prevented nftables from becoming the
defacto linux firewall before; was waiting on kernel integration, I think it
first made it in sometime around 3.18 if memory is serving well).

~~~
bandrami
Let's just say after the past few years I'm not brimming with eagerness to
give the benefit of the doubt. That said in this case I actually do see the
problem the new system is trying to solve, and think it's got a lot of cool
stuff to offer.

------
JdeBP
There are _lots_ of errors in this, starting with the incorrect "it's" in its
title and things like "a wel!l" instead of "as well!", the mis-spelling
"propert", missing definite and indefinite articles, and disagreement in
number between subjects and verbs. Some errors are far more major than those.

The "Inet family" section has entire pieces missing. It discusses examples
that aren't there, and at one point stops in the middle of a sentence.

The bulleted list in the "Getting started" section confusingly splits things
in the wrong places and several bulleted items read as gibberish as a
consequence.

This article is in sore need of some proof reading and editing.

~~~
angry_octet
For those not aware, this is satire.

