Nftables: a new packet filtering engine

Posted Mar 25, 2009 11:31 UTC (Wed) by job (guest, #670)
Parent article: Nftables: a new packet filtering engine

An excellent article, as always. Nftables is one of those things I really wanted to take a look at "any day now".

As a user/sysadmin, these are the main problems I have with iptables and friends:

It's too modular. There are about a gazillion modules, one can hardly know about them all. Sometimes they do common operations with slightly different syntax.
The iptables syntax can be improved. Compared to pf it is much harder to read configuration files, and to update them run-time. With tc you pretty much have to use the u32 classifier, which is sparsely documented.
Speaking of tc, the integration between traffic management and packet filter must improve. Preferably using the same classifiers and managed with the same tools.

It would also be desirable to use table lookups for large rulesets to improve performance. Nftables seems to be an interesting development. My immediate worries are that Using a byte code interpreter in the kernel is a very dangerous path. It's like a do-everything-syscall, opaque and hard to understand.

Also, what about the connection trackers such as FTP, SIP etc.? Shall they be called from bytecode or reimplemented? They also contribute to duplicated code.

Nftables: a new packet filtering engine

Posted Mar 26, 2009 1:37 UTC (Thu) by gdt (subscriber, #6284) [Link] (5 responses)

My immediate worries are that Using a byte code interpreter in the kernel is a very dangerous path. It's like a do-everything-syscall, opaque and hard to understand.

I think a byte code interpreter would be more secure than the current situation, where people who want to get a particular protocol supported have to write a netfilter module. If you think the user-space documentation for iptables hasn't been maintained for years, well the netfilter documentation is much worse. Compared with new kernel authors writing modules which can access any kernel memory or service using under-documented APIs -- a byte code interpreter looks sane: it limits the memory accessed, it talks the language of networking rather than the kernel, it has a limited API, and it has no locking or other kernel-specific difficulties.

Sure, a byte code interpreter makes it possible to do the wrong thing with a syscall. But that wrong thing can't do anything but access and manipulate packets. It can't cause the kernel to crash and die like a poor netfilter module.

Nftables: a new packet filtering engine

Posted Mar 26, 2009 17:06 UTC (Thu) by samroberts (subscriber, #46749) [Link] (4 responses)

BPF as used by tcpdump is already a byte-code interpreter in the kernel,
and pre-existed iptables. It does matching, but doesn't have actions.

I find it interesting that the lwn article and what little info I saw
about nftables doesn't either. It seems sufficiently similar, why isn't
it being used as a basis for the opcode interpreter? NIH?

And why the firewalling didn't take a BPF-like approach with an opcode
interpreter and user-space compiler from the start is beyond me.

Nftables: why it isn't based on BPF

Posted Mar 27, 2009 6:55 UTC (Fri) by speedster1 (guest, #8143) [Link]

From Patrick's blog entry (mentioned in article)
http://people.netfilter.org/kaber/weblog/2008/08/20/

A very important feature, one that is missing from all other filters that are built similar in the kernel (like BPF, TC u32 filter, ...), is reconstruction of high level constructs from the representation within the kernel. TC u32 for example allows you to specify "ip daddr X", but when dumping the filter rules it will just display an offset and length.

Nftables: a new packet filtering engine

Posted Mar 27, 2009 18:14 UTC (Fri) by kaber (guest, #18366) [Link] (1 responses)

The BPF interpreter isn't too useful for this case since you can't update an BPF program incrementally and the filter size is limited to 64k. Its also too limited in many other aspects.

Nftables: a new packet filtering engine

Posted Mar 28, 2009 17:21 UTC (Sat) by yoduh (guest, #38527) [Link]

Can you elaborate on these differences for us fresh readers of the bpf-usenix93 paper? Your VM sounds close enough to BPF++ to perhaps describe it in those terms. Both limitations you cite (no incremental update, 64k) sound like implementation decisions made when the goal was picking 1 in 100000 packets, not disposition of every one of them; ie not hard limits.

Nftables: a new packet filtering engine

Posted Apr 3, 2009 18:22 UTC (Fri) by trasz (guest, #45786) [Link]

Actually, at least in FreeBSD, bpf is not just a bytecode interpreter - it employs JIT.