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

On 7/29/2014 3:18 AM, Gleb Smirnoff wrote:
>    Darren,
>
> On Sat, Jul 19, 2014 at 09:36:06PM -0700, Darren Pilgrim wrote:
> D> Never mistake silence for consent.
> D>
> D> The vast majority of people don't know pf is outdated and broken on
> D> FreeBSD because they don't know what they're missing and likely aren't
> D> using IPv6 yet.  The moment you turn on IPv6 and restart a validating
> D> unbound, you run full-speed into pf's broken behaviour.  Make an
> D> EDNS0-enabled query for a signed zone and you'll get a fragmented UDP
> D> packet that will never make it through unless you tell pf to allow all
> D> fragments unconditionally.  They'll simply think something is wrong with
> D> unbound, turn off EDNS0 and/or validation, hurt peformance and/or
> D> security in the process, and never realize their firewall is doing
> D> literally the worst possible thing it could do.
> D>
> D> All because over half a decade ago some folks got all butthurt over a
> D> config file format change.
>
> Do I understand you right, that you propose a tens thousands lines of
> untrivial code bulk update in order to fix a particular bug, that can be
> nailed down separately?

No.  I believe pf should be removed from FreeBSD and efforts refocused 
on keeping ipfw up to date and feature complete.  It makes more sense to 
look at what pf, ipf, nbtables, etc. are all doing as a source of ideas 
for what we can do with ipfw.  A decade ago, there was justification for 
adding pf: at the time, ipfw lacked some major features.

Ipfw has since caught up.  I see no remaining value in having more than 
one packet filter in the base.  Ipfw is more mature and less broken, so 
we should keep it and ditch the rest in the name of survival efficiency.

> Do you also say that breaking configuration
> files for a large number of people is okay if the update is expected
> to fix a bug unrelated to configuration?

Yes.  Loss of configuration file backward compatibility is a fact of 
progress.  Here are some examples of places where FreeBSD broke backward 
compatibility of a configuration file:

- rc.conf (with every major version change)
- resolv.conf
- kernels
- make.conf vs. src.conf
- the ports collection
- pkg vs. pkgng
- pkgng changes within pkgng 1.x

On top of that, we also have whole chunks of the OS where compatibility 
was broken (e.g., the toolchain, switch to unbound, etc.).


> For me sounds like hunting a sparrow with a cannon.

The whole thing, to me, was an example of lobbyist politics: a vocal 
minority had the resources and access to stop progress.  Now we are all 
suffering for their ignorance and arrogance.

If anything, we should rename pf to tppf (short for "Tea Party Packet 
Filter").