OpenBSD PF Developer Interview, Part 2by Federico Biancuzzi
OpenBSD celebrated release 3.5 on 1 May 2004. In honor of this release, Federico Biancuzzi interviewed the developers of OpenBSD's PF, a powerful and flexible packet filtering interface. This is the second half of an interview that began in PF Developer Interview, Part 1.
Federico Biancuzzi: A recent research by Paul Watson entitled Slipping in the Window: TCP Reset Attacks caused a lot of rumors in the media. After the public presentation at the CanSecWest conference, we understood that the real situation was not so terrible for every OS. How does OpenBSD reduce the risk of this type of attack?
Henning Brauer: OpenBSD is not vulnerable to these attacks. We use random ephemeral ports since 1996. We require RSTs to be right in the edge of the window since 1998.
Federico: How can PF protect a vulnerable server from this type of attack?
HB: The scrubber has just been modified to drop RSTs which are not right on the edge of the window. A special form of NAT where only the src port is modified is beeing worked on.
Federico: During the end of April most PF developers flew to Ryan McBride's house to start a short PF hackathon. (See Figure 1 for a photo from Ryan himself.) What are the new features and enhancements that were planned or already committed for the next release?
Figure 1. OpenBSD hackers hard at work at a recent hackathon.
HB: We had an extremely productive four-day hacking party at Ryan's house in the woods near Sechelt (British Columbia, Canada — about 2 hours from Vancouver), yes.
It was really a network hackathon, not limited to pf. Besides a lot of smaller things, the stuff we hacked on includes:
- IPv6 transport for
- neighbor cloning for
pfctlinstead of sharing a lot of code with it, which was a bit fragile
- capabilities announcement in
- ipsec integration for
- altq fixes
- rx/tx buffer allocation at
ifconfigrather than attach time for
sis(4), others to follow. This reduces the number of mbuf clusters sitting around unused.
- when enqueueing small packets, copy them to a mbuf and free the cluster, also for saving mbuf(-cluster) memory
- route refresh support for
- scrub enforces exact matches, not window matches, for RSTs now when full reassembly is enabled
- IPv6 support for
return-rstnow works on IPless bridges
authpfnow loads the autheticated users IP addresses into a table too
Ongoing work includes a rework of how anchors work — they can be nested soon, and the ruleset name (which is really just one level of nesting) will go away.
Federico: What type of platform do you use for PF development? Has the code any optimization for a particular architecture, like 64bit (Athlon64, Sparc64, G5, Prescot)?
HB: I mostly hack pf on my i386 notebook and, less often, my sparc workstation. Tests on sparc64 are mandatory as this is the most picky platform, especially due to its memory alignment requirements. I occasionally test on alpha, hppa, amd64, mvme68k, mvme88k, mac68k and VAX as well.
pf operates completely in MI (Machine Independent) land, there is no MD (Machine Dependent) code whatsoever.
Ryan McBride: I develop on sparc64 and i386. sparc is used for testing, and I have VAX and cats boxes sitting here waiting to be set up for testing (too slow for real development)
Cedric Berger: Mostly i386 gear. When doing big changes, I usually try to compile the code on a Sparc64 box since unlike i386, it uses 64-bit, big-endian, and gcc3. If PF code works on Sparc64 and i386, it has good chances to work well on the other architectures.
Federico: Which platform would you suggest to deploy an OpenBSD based firewall for various scenarios (home, office, enterprise)?
HB: Well, basically, any.
Vax may not be a good choice for filtering Gigabit speeds, obviously. From
the modern archs, sparc64, alpha, and amd64 are all good choices. i386 and
powerpc less so, I like
W^X purity, but should not impose
performance problems either.
RM: For small sites, the Soekris 4501 or 4801 make
excellent devices. For bigger links, an AMD64 based system is an excellent
choice. Even if you're only dealing with 100Mbit links, using gigabit cards
sk(4) will improve performance as these
cards are designed to handle much higher numbers of packets per second than
Federico: Reading the pf@ mailing list I found that the code has some limit regarding the hardware usage. What type of limits does PF present in the 3.5 release? How many concurrent states and how much RAM can PF handle?
HB: That thread is full of lies and uninformed guesses. Ignore it.
pf itself doesn't impose many limits. We have the settable state and fragment limits to prevent pool exhaustion, the amount of memory available for the pools used by pf varies depending on the hardware.
I don't have exact numbers; but 50,000 state entries are not a problem on a i386 with 128 MB.
That said, there is ongoing work which changes the way OpenBSD handles kernel memory used for the network stack — pf is not special here. This will allow for both more efficient usage, backpressure when needed, and more total memory available to the network stack including pf, thus allowing for much bigger state stables etc.
CB: With this patch by Mike Frantzen, you can use up to 768MB of RAM on i386 to store table entries, versus 64MB previously. We're looking for a similar improvement for the state table, but that's a bit more difficult.
Federico: PF is going to be ported to other BSDs. Daniel, are you proud of this? Are you working on these portings?
Daniel Hartmeier: I've been working with Pyun YongHyeon and Max Laier who do the FreeBSD port. They did all of the work, I merely tried to answer questions and sometimes aid in debugging. This has proven valuable to the base source, several bugs were found and fixed in the process. Maintaining several ports will cause additional work, of course, but the additional user base producing feedback makes it worth the effort.