Re: Future of pf / firewall in FreeBSD ? - does it have one ?

In freebsd-questions Digest, Vol 530, Issue 5, Message: 1
On Thu, 31 Jul 2014 22:02:22 +1000 Da Rock <freebsd-questions_at_herveybayaustralia.com.au> wrote:
 > On 07/29/14 20:35, Gleb Smirnoff wrote:
 > > On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote:
 > > M> |> imho, the root problem here is that an effort to implement a
 > > M> single
 > > M> |> feature improvement (multi-threading) has caused the FreeBSD
 > > M> version
 > > M> |> of pf to apparently reach a near-unmaintainable position in the
 > > M> |> FreeBSD community because improvements from OpenBSD can no longer
 > > M> be
 > > M> |> ported over easily.   FreeBSD's pf has been put in a virtual
 > > M> |> isolation chamber due to the multi-threaded enhancement.
 > > M> |>
 > > M> |> Was it worth it?
 > > M> |
 > > M> |Yes.  This happened *three times* in BSD land now.  How much more
 > > M> |proof does it take to make that clear?
 > > M> |[snip]
 > > M>
 > > M> In this instance, more proof would consist of pf development not
 > > M> wallowing in inactivity.
 > > M>
 > > M> imo, tactical changes were implemented in pf without the strategic
 > > M> negative consequences affecting the decision process guiding the
 > > M> implementation of those tactical features.    And that's backwards.
 > > M> Strategies direct tactics, not vice versa.
 > >
 > > I would strongly disagree with you. I would claim that directions
 > > I've put in pf in 2012 are strategically correct, while previous
 > > life of pf in FreeBSD was not.
 > >
 > > History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already
 > > outdated. It isn't possible otherwise. While Max spent time on porting
 > > some stable version, the OpenBSD moved forward. It was later updated
 > > again by Max, and again right after update it was outdated. I mean
 > > that people who a) believe that OpenBSD pf is the one true b) eager
 > > for bleeding edge version, these people simply cannot be satisfied.
 > > A porter needs to take latest stable version from OpenBSD and spend
 > > some time working on it. So, pf in FreeBSD was always "outdated",
 > > even before my SMP work on it.
 > > Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped.
 > > In 2004 we've got 10 years of diverging developement between FreeBSD
 > > and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in
 > > 9.x is again outdated and introduces a number of bugs that were not
 > > present in 8.x (regressions). Most regressions didn't came from OpenBSD,
 > > but were artifacts of porting. Also, the number of #ifdefs in code
 > > became so unbearable that no one would want to go through code
 > > fixing bugs.
 > >
 > > In 2012 for me it was obvious that following this route is strategically
 > > incorrect. You are never "up to date". You need more efforts to port
 > > pf, and you yield in a port of worse and worse quality over time.
 > >
 > > So, in 2012 I put a lot of efforts to not only bring pf out of a
 > > single mutex, but also make it more native to FreeBSD. You can
 > > read this through commit logs.
 > >
 > > The net result is that we got our own pf, that can be maintained
 > > further. Unfortunately, still no person is seen on horizon who can
 > > take maintainership.
 >
 > That explains it rather well. Thank you for the enlightenment on this.

Indeed.  This potted history covers a lot of ground, and work, to most 
of which I've been largely oblivious.  I've used ipfw since '98; it well 
suited my assembler background and perhaps overly orthogonal tendencies, 
and I found dummynet hugely useful for herding small networks of unruly 
cats, so I've felt no need to explore pf, nor ipfilter.

 > Without diminishing your efforts so far, what do you think about 
 > pitching all efforts into IPFW to combine effort and reduce overhead of 
 > maintaining separate firewalls in the core? Is there an advantage to 
 > having our own pf?

Quoting Gleb's response from a later message:

 > Is there any disadvantage keeping it? It is a plugin. It is optional
 > and loadable. I removed most additions to the network stack that live
 > outside netpfil/pf.
 >
 > Some people like it and use it.
 >
 > It is also the only tool to configure ALTQ now.

I think each of those is sufficient reason for existence, as long as 
there's ongoing people - at least a few - who care enough about it.  
Maybe it needs to become 'fpf' and be happy to complete its forking?

I can't imagine pf or ipfilter people deciding to work on ipfw.  For one 
thing, ipfw has quite a few people working on aspects, development is 
conservatively ongoing, with no discernable shortage of volunteers.

For another, I feel that there are distinct philosophical differences at 
the level of rule definition languages.  From my little reading, pf uses 
more high-level symbolic language, where ipfw is relentlessly linear and 
closer to bare metal.  Different people will be attracted to, and will 
be able to work most efficiently with, such different approaches.

I've no idea how pf works at the kernel level, as compared with ipfw's 
virtual machine opcode execution; I daresay each has its strengths and 
weaknesses.  However it's the ruleset configuration language that is the 
main concern of most packet filter users, not kernel level operation.

I believe in ecosystem strength through diversity, as much in projects 
like FreeBSD as anywhere in the 'real' world.  It could even discourage 
(for example) ongoing ipfw development if there were no other options.

cheers, Ian