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.
