Nftables: Not addressing VJ channels or userspace tcp

Posted Mar 28, 2009 0:04 UTC (Sat) by Nelson (subscriber, #21712)
In reply to: Nftables: Not addressing VJ channels or userspace tcp by dlang
Parent article: Nftables: a new packet filtering engine

on just about every real-world ruleset I've needed to deal with I was able to split the ruleset up through multiple tables/chains and not only speed up the processing, but make the ruleset smaller and easier to understand.

That's only partially true. Every maintained, real-world firewall, that is run by a more programmery type admin is this way. Just about all the others are complete cluster-Fs.

I've seen more than a few firewalls where people started adding special rules for things, with no documentation and then it changes hands, and after a while it's big, ugly, and nobody knows why it does what it does and they're afraid to change it.

FWIW, a compiler can optimize those big ugly ones down to the minimal set and they can also optimize them for efficiency. It's just about a perfect compiler problem from a textbook or something.. Since that's the case, while it's nice to let the programmer configure the tables and define why packets should flow through the rules of different ones, but it seems like there is a good case to build that compiler and just solve it for everyone.

I've developed a number of products that make use of netfilter in different ways. I like the goals of NFtables. Some of the netfilter plugins are kind of calcified, some are useless, not all are IPv6 compliant; it's worth cleaning it all up and setting a new benchmark.

to post comments

Nftables: Not addressing VJ channels or userspace tcp

Posted Apr 6, 2009 8:14 UTC (Mon) by dlang (guest, #313) [Link]

note that I didn't claim that the rulesets _were_ split up cleanly, just that they _could_ be split up cleanly to multiple tables/chains.

the point being that you don't have to throw out the current system to get that, you 'just' need to create the tools to analyse the rulesets and optimize them.

nftables may have some real benefits, but a lot of what's being claimed for it could be done with iptables today, and doing it requires verylimilar tools be written in either case (the difference being if it compiles down to iptables commands or to nftables commands)

it has been commented that iptables was intended to be the assembly language level with the expectation that higher level languages would be written to compile down to it. In practice it is used directly.

it looks like nftables is intended to be the machine language level, making it unsuitable (and effectivly unusable) for admins directly with the expectation that higher level languages will be written to compile down to it.

since the higher level tools were never created for iptables I am concerned that they won't be for nftables, which is why I was calling for the minimum to be a compiler for the existing iptables functions.

people talk a lot about the need for 'high level' firewall/router controls, but as far as I know, nobody has ever produced a usable set of such 'high level' controls. every attempt that I have seen ends up oversimplifying things to the point that they are usable for a very small set of tasks, and as soon as you need _anything_ outside of that set, you have to throw out the 'simple' tool and go back to the low-level tool.