Federico: Mike, you wrote most of the stateful engine. How did you audit
it?

MF: Auditing is more of a continual process than one would
think. Whenever something that you never thought of before comes out, you have
to go through all your code again to make sure you're not affected. Often that
is a self sustaining process. Inspiration often strikes during the audit and
you think of more gotchas so you re-audit and think of more gotchas to audit
for. I end up staring [at] a lot of weird and funky traffic at work; corner
cases of corner cases. Most of my audits are walking those weird packets or
connections through PF's state engine to make sure we don't block a valid
packet.

Federico: Mike, you wrote most of the scrub feature. What improvements are
planned for the future? What about TCP scrubbing and
normalization?

MF: Niels Provos did the initial fragmentation and flag
scrubbing support based on Paxson and Handley's USENIX paper. My planned
improvements are in the normalization of TCP segments. The TCP protocol was
designed so that there are only two active participants in any given
connection. Making PF more active in the TCP stream will be done very gradually
since mistakes lead to massive ACK storms or connections mysteriously
freezing.

Federico: Mike, your job focuses on IDS development. Had you any ideas to make
PF capable of interacting with an IDS like Snort?

MF: There are a few levels of interaction between a
firewall and an IDS. I believe Snort has been able to do intrusion detection on
any packet logged by PF for a year or two now (PF logged packets appear on the
pflogd0 virtual interface which you can monitor with many
libpcap based programs like tcpdump or
ethereal).

There are already two ways to emulate Linux's DIVERT sockets and turn an
IDS into an IPS (Intrusion Prevention System). One could use PF to route the
packets to a tunnel device and read them there. Or one could block the packet
in PF and watch the full packet show up on the pflogd0 logging
interface.

And a passive IDS running on the firewall could easily tell PF to kill all
of an attackers connections and add his IP address to a blacklist or even
redirect any new connections from him to a honeypot.

The tools are all there. All it takes is someone to add the code to Snort.
Someone whose employer doesn't compete with Snort :-).

Federico: Are there any plans to develop application proxies for common
protocols like HTTP, SMTP and POP3?

DH: They are easily done in userland, see
ftp-proxy(8). We agree to not do it in kernel. If there is enough
demand for protocols besides FTP, someone will step up and do it, I'm sure.

HB: No.

ftp-proxy is needed due to the nature of ftp with its two
connections, the place for other proxies is in ports IMHO. That said, some
stuff is imaginable in-tree, and if somebody steps up and writes good code,
this is certainly welcome. Whether it turns into a port then or goes into the
main tree, I can't say yet.

RM: In the kernel? Certainly not, the risk for compromise
is too great. In userland, already have ftp-proxy, and there are
3rd party applications which handle many of the other protocols:
apache or squid for HTTP; MTAs such as
sendmail are basically SMTP proxies by nature.

CEA: These protocols are quite firewall friendly since they
use well defined ports. These protocols could benefit from content filtering or
caching. OpenBSD already has spamd which is a proxy for spam :)
and there are a number of http proxies in the ports tree. I am not aware of any
specific plans, but someone might just decide to write one.

CB: I've no idea.

Federico: Some OpenBSD developers wrote various tools to analyze PF logs and
statistics (pfstat, Hatchet,...). Is there any project to create a global and
unique graphical interface to work with PF?

HB: No.

RM: Not by any OpenBSD developers. Doing a good GUI
configuration tool for PF is very difficult because there are so many options,
and laying them out intuitively in a graphical interface is nearly
impossible.

Federico: Can, could you explain pftop?

CEA: It started as a text-mode realtime display tool for
active pf states. It improved quickly with feedback and patches from the
community. It now has rule and queue pages, and can compute per state
throughput. I should probably find some time to catch up with the new pf
features in 3.5 though. pftop is available in the ports tree as
sysutils/pftop.

Federico: Please, tell us the all the truth about PF performance tweaking.
What are the right settings to build a stable and network optimized
kernel?

HB: Use GENERIC.

I totally don't get that tweak tweak tweak attitude. GENERIC
works fine in almost all circumstances. If you have a real problem
with GENERIC, as in a problem that shows up during real world
usage, then post to misc@ and you'll get help.

Of course there are cases where you need to tune; I have machines where I
need to crank nmbclusters a little. BUT: the key point is, as long
as GENERIC works and doesn't show a problem that is the best you
can get. And making GENERIC work for more and more scenarios is
one of the major things we are doing since some releases, by switching from
compile time options to runtime controllable stuff (mostly sysctl)
or at least allow changing from config/ukc.

In fact, a lot of knobs should not ever be touched. This especially is true
for nkmemclusters. The myth about that being needed comes from old
days where we had a leak in the routing table code under some circumstances...
nowadays you will in almost all cases shoot yourself in the foot by mucking
with nkmemclusters. You increase it, something else needs more
kernel memory, and you run out. You will crash. So don't touch it.

OpenBSD 3.6 will come with big improvements in that area.

Federico: How will PF evolve? More features or performance tweak?

DH: I think addition of new features will slow down over
time, most things are covered by now. New features have to be justified against
the instability changes introduce. Changes have been frequent at first, I don't
mind changes settling down. That allows [us] to more carefully search for
performance improvements and plain bugs.

MF: My PF wishlist is almost empty. I imagine most of the
next big evolutions will be from spontaneous ideas someone has in the bar or us
feeding off ideas of the others during the next PF hackathon.

HB: There's ongoing work on bpf security. We
are also looking at further flexibility in the language and some internal
changes that solve little problems.

There are no "big" new features planned for pf; maybe some of the stuff we
do outside pf gets to interact with it in some way. We've been at the "pf is done" point quite a few times now, and there have been great ideas later on. pf development slowed down, and will slow down even more — not because we
don't have enough developers or something, but simply because it is, well,
pretty much done.

Compatibility becomes a much larger issue with every release that contains
pf and with each and every pf installation, that's an area where I think we
have to get better.

CB: The one thing I'd like to have for 3.6 is the ability
for firewalls working in a bridged environment to send IP packets (i.e.,
firewalls without IP address and/or routing table). Currently, features like
syn-proxy, return-icmp, return-rst don't
work on such a firewall because PF does not know how and where to send packets.
Fortunately, I think there are good 95% solutions to that problem, which is
probably the most requested feature on PF lists.

Besides that, I'm not aware of any "big" things that would come, but we've
been saying that for every past release, as far back as I remember :).

RM: Because of the very clean initial design, PF has never
had real performance problems — in the vast majority of PF deployments,
the CPU sits essentially idle. So there's not much incentive for developers to
spend long hours squeezing a bit more performance out of the code — such
efforts would likely increase the complexity and thus the chance of bugs.

With regards to new features, it is hard to say; PF is becoming fairly
feature complete and eventually development will slow down to a maintenance
mode, like many other areas of OpenBSD. On the other hand, put 2 PF developers
in a room together, and they immediately begin to come up with new crazy ideas.
So I don't see it stopping within the next few releases.

However, I think the bulk of new work being done will not be in adding new
features, but in the following 2 areas: fine tuning the features which already
exist as we learn more about how they are used in production deployments, and
making internal changes which simplify or reduce the code base. The latter is
very boring for users, but actually quite important in reducing the potential
for bugs.

CEA: I think, with the recent failover work, the feature
range is quite complete. There would definitely be some performance tweaks, and
improvements/additions to supporting userland tools before new features.

Federico Biancuzzi
is a freelance interviewer. His interviews appeared on publications such as ONLamp.com, LinuxDevCenter.com, SecurityFocus.com, NewsForge.com, Linux.com, TheRegister.co.uk, ArsTechnica.com, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.