Netfilter maintainer Patrick McHardy recently announced a first alpha-release of nftables, slated to eventually replace iptables as the standard Linux packet filtering engine. Nftables aims to simplify the kernel ABI, reduce code duplication, improve error reporting, and provide more efficient execution, storage and updates of filtering rules. Patrick began with a high level overview of the three pieces that comprise the firewall, "the kernel provides a netlink configuration interface, as well as runtime ruleset evaluation using a small classification language interpreter. libnl contains the low-level functions for communicating with the kernel, the nftables frontend is what the user interacts with." An insightful overview can be found on lwn.net.
Patrick explained that data is represented internally in a generic fashion, "meaning it's possible to use any matching feature (ranges, masks, set lookups etc.) with any kind of data." He went on to add, "the kernel doesn't have a distinction between matches and targets anymore, operations can be arbitrarily chained, fixing a common complaint that multiple rules are required to f.i. log and drop a packet. Terminal operations will stop evaluation of a rule, even if further operations are specified." Speaking about the the userspace frontend, he noted, "the classification language is based on a real grammar that is parsed by a bison-generated parser (currently, it might have to be replaced) and converted to a syntax tree." Patrick continued, "the frontend supports both dealing with only a single rule at a time for incremental operations, as well as parsing entire files. In the later case verification is performed on all rules and changes are only made after full validation. Currently not implemented, but planned, is transactional semantic where changes are rolled back when the kernel reports an error."
"I have a question for the PF/ALTQ masters out there," Matthew Dillon began on the DragonFlyBSD kernel mailing list, having recently switched from using a Cisco router to a DragonFlySD server running PF. "I am trying to configure PF in a manner similar to what Cisco's fair-queue algorithm does. Cisco's algorithm basically hashes TCP and UDP traffic based on the port/IP pairs, creating a bunch of lists of backlogged packets and then schedules the packets at the head of each list." He went on to explain that he was unsuccessfully trying to configure the same thing with PF, "neither CBQ nor HFSC seem to work well. I can separate certain types of traffic but the real problem is when there are multiple TCP connections that are essentially classified the same, and one is hogging the outgoing bandwidth. So the question is, is there a PF solution for that or do I need to write a new ALTQ mechanic to implement fair queueing?"
Not finding a solution, he followed with a series of patches implementing what he needed. He explained the resulting logic noting, "unless something comes up I am going to commit this to DragonFly on Friday and call it done. I would be pleased if other projects picked up some or all of the work":
"The queues are scanned from highest priority to lowest priority; if the packet bandwidth on the queue does not exceed the bandwidth parameter and a packet is available, a packet will be chosen fro that queue; if a packet is available but the queue has exceeded the specified bandwidth, the next lower priority queue is scanned (and so forth); if NO lower priority queues either have packets or are all over the bandwidth limit, then a packet will be taken from the highest priority queue with a packet ready; packet rate can exceed the queue bandwidth specification (but will not exceed the interface bandwidth specification, of course), but under full saturation the average bandwidth for any given queue will be limited to the specified value."
Ryan McBride works full time on OpenBSD development. His first contribution was adding IPv6 support to PF, OpenBSD's stateful packet filter. More recently he was the primary developer of CARP, the Common Address Redundancy Protocol, a patent-free alternative to HSRP and VRRP.
The upcoming release of OpenBSD 3.3 on May 1'st will include, among many other improvements, a notably enhanced version of PF, OpenBSD's stateful packet filter. Some of the more significant enhancements to PF include: 'queues', allowing for per-rule bandwidth control [story]; 'pool options', allowing one to utilize multiple uplinks and to intelligently redirect traffic to multiple servers; 'anchors', which allow one to divide packet filtering rule lists into logical pieces; 'tables', efficiently allowing for very large lists; and other parser improvements that make an already friendly syntax more human readable.
PF replaced its predecessor, IPF, with the release of OpenBSD 3.0 in December of 2001. Since that time, this impressive and relatively new packet filter has grown a faithful following (myself included), and continues to evolve rapidly with each new OpenBSD release. Perhaps the greatest compliment, developers have begun to port PF to other operating systems. Back in January, Joel Wilsson announced his effort to port PF to NetBSD. And more recently, Pyun YongHyeon announced his port for FreeBSD.
I approached Pyun to learn more about his recent porting efforts. In the following article he explains why he began working on this port, and what FreeBSD users can expect from the project. Additionally, I spoke with PF creator Daniel Hartmeier [interview], PF developer Henning Brauer, and OpenBSD creator Theo de Raadt [interview]. They all reflect on these recent porting efforts, as well as the exciting new features found in OpenBSD's PF.
Henning Brauer announced today that "altq's functionality has been merged into pf." The ALTQ project page explains that Alternate Queueing "provides queueing disciplines and other QoS related components required to realize resource-sharing and quality of service." Thus PF, the OpenBSD project's state
Daniel Hartmeier is the original author of pf, the stateful packet filter that has been part of the OpenBSD project since the release of OpenBSD 3.0 in December of 2001. Living in Switzerland, Daniel continues to actively support and improve pf.