AddThis Social Bookmark Button


OpenBSD PF Developer Interview, Part 2
Pages: 1, 2, 3, 4

Federico: Now that PF has been imported into the FreeBSD base system, do you think that some people will consider moving from OpenBSD to FreeBSD for its SMP support and better performance?

HB: Not at all. First, the performance advantages of FreeBSD, that is largely a myth. All BSDs are rather close to each other with respect to general performance.

Second, I don't expect any OpenBSD/pf user to switch, as pf on OpenBSD will always have some advantages — as we develop pf here, we can embed it much deeper. What I expect is FreeBSD users switching to pf from ipf and ipfw.

RM: On most firewalls, the CPU is not the bottleneck, so adding a second one will not help (and may even slow things down). That being said, SMP support is being worked on actively for OpenBSD, and will likely appear in 1 or 2 releases, depending on how long it takes to get it right.

CB: Competition is good. If FreeBSD is better than OpenBSD for some application, I will use FreeBSD for that application. If OpenBSD performance lacks in some areas, we will try to fix it. That being said, I believe OpenBSD is clearly the best choice for a firewall now, for various reasons.

Federico: Why does PF still miss one basic feature like IPFilter return-icmp-as-dest?

HB: Because nobody thought it was needed? There were no requests for this whatsoever, nobody of us had a need to, so nobody wrote that. That nobody requested it after, what is it now, 2.5 years?, is a strong sign it is not needed at all.

CB: Because nobody in the developer or user community cared enough to send a working patch.

Implementing that functionality is not easy, but I'm now looking at implementing return-icmp for pure bridges, when there is no routing table (return-rst for bridges has just been committed). It is very likely that once I've return-icmp working on bridges, adding return-icmp-as-dest support will be trivial.

Federico: Why doesn't PF come with an internal version number to track various updates typical of -stable branches?

HB: what for?

OpenBSD 3.5 is OpenBSD 3.5 is OpenBSD 3.5, period.

Can Erkin Acar: Since the kernel and userland is always synchronized, there is not much point in adding a version identifier. For external utilities, such as pftop (which still compiles on OpenBSD 3.0) the OpenBSD release numbers are usually sufficient.

Federico: What type of support does PF provide for IPv6? Are there any interesting features specifically for IPv6? What features are still missing?

HB: PF has full IPv6 support — there's nothing really special or different opposed to v4.

RM: We're missing IPv6 fragment reassembly support, but this is being worked on actively and will probably be included in 3.6. pfsync does not support IPv6 as a transport.

Federico: Since the ALTQ merge in the 3.3 release, a lot of people enjoyed shaping the bandwidth with PF rules. Is there anything new for ALTQ, like other types of queues?

HB: Kenjiro and myself added HFSC for 3.4 and polished things a little, and I rewrote the ID allocator. No real changes were done after that in the queueing arena, and there are no planned currently. In our eyes the current state is quite fine.

Federico: How do PF and IPSEC interact? What type of problems have you resolved and what stills need to be solved?

DH: pf sees IPsec encapsulated traffic both encapsulated on the real interface as well as decapsulated on enc(4). Filtering and translation can be done on either, with various effects. Apart from that, pf doesn't treat IPsec traffic differently from other protocols. It doesn't filter on SPI or other IPsec specific fields. UDP encapsulation for NAT traversal have recently been added, but that's outside of pf, in IPsec/stack code.

Several special requirements, like static source ports for isakmpd, have been addressed, so pf basically works at least as well with IPsec as any other packet filter not doing IPsec protocol inspection.

HB: They do not interact more than pf interacts with anything else network related — pf passes or blocks ipsec traffic.

CB: They interact pretty well. You can filter ESP packets on the real interface or decrypted packet on enc0. Nat/rdr is possible on enc0, but that's tricky. What I'd like to do for next release is to remove the need for the pass on enc0 proto ipencap all rule, that is just wrong.

Federico: WiFi network are becoming widely (and wildly) used. What can PF do for a wireless network? Is there any new idea specific for wireless filtering?

HB: I don't see wireless much different than wired networks with respect to pf. authpf can be especially neat in wireless networks, but it already is neat in wired ones too.

Federico: If I'm not wrong, tools that use raw access to network data bypass PF because the filtering happens after. How can this be solved? Is this a behavior you want to change?

HB: This is not true.

It is true that bpf is outside pf. This is actually very good for debugging.

We might add a possibility for bpf-based tools to request to be hooked in before pf. It might be useful for the dhcp programs. But then, that is not a real-world problem — I have privilege revoked dhcpd and dhcrelay so that they don't run as root anymore, and canacar@ helped out with bpf write filters (we have read filters already) and lock the bpf device so that no changes in those filters are possible anymore. Especially for dhcpd that means that one very worrysome piece of code is now locked away that nicely that you don't have to worry much anymore. And of course besides the privdrop and bpf security work, we cleaned that mess up big time...

The most worrysome of those programs is now dhclient which is scary, huge and still runs as root — even given we cut about half of its code out already. I have it running privilege separated on my machine already...

RM: I don't see this as a problem, and don't think that this will be changed.

CEA: This is by design, and I do not want/see this behavior changing. We have introduced bpf security extensions to solve this problem on a case-by-case basis. We are going through every program in the tree and modify them to use the security extensions and drop/separate privileges. At some point we may also start looking at critical applications in the ports tree.

Pages: 1, 2, 3, 4

Next Pagearrow