Re: Removing PF

[Matt Sporleder <msporleder%gmail.com@localhost>]

> On Mar 29, 2019, at 5:10 PM, Brian Buhrow <buhrow%nfbcal.org@localhost> wrote:
> 
>    hello.  My suggestion is, rather than strongly advocating for the
> removal of pf, which your message readily conceeds has more functionality
> than npf does at this time, why not marshall an effort to get the missing
> features from pf into npf?  I totally understand that the work to improve
> NPF's scalability and robustness is vitally important, but if you want to
> get consensus on removing npf, let's now get the additional functionality
> into NPF.  Once done, we can discuss removing pf again.   At the risk of
> being extremely rude, although that is not my intention, if as much effort
> had been put into improving  the functionality of NPF as has been put into
> the effort to get pf removed, I dare say, NPF would now be up to PF in
> functionality and the conversation would be easier to have.
> 
>    right now, NPF doesn't do what I need and from what I can tell in the
> documentation, I'm not sure how to write the functionality into NPF.  that
> leaves me with the task of  porting PF to a newer version of NetBSD on my
> own, with no support from fellow NetBSD users, running an older version of
> NetBSD as long as is feasible, or switching to another OS.  You say the
> effort to port   modern version of PF to NetBSD is greater than writing the
> additional functionality into NPF.  Yet, somehow, after years, that
> functionality is not in NPF.  If it were that easy, I think it would have
> been done.  And, prey tell, why is it harder to maintain a modern version
> of PF than NPF?  If, for the sake of discussion, a modern version of PF were
> imported and it were modified to scale with the new features of the network
> stack in NetBSD, what would make it harder to maintain than NPF, which has
> absolutely no market share outside of NetBSD?  If it is simply that you
> don't want to do it, that's fine, but fundamentally, I don't really see
> what's harder about maintaining one piece of code versus another.  The
> documentation for PF is much more complete than it is for NPF, and when I
> looked into the NPF source code, it looked like I would hav to grow a lot
> of features in NPF to gain parity with PF.  And, once done, all those
> features would have to be maintained going forward, not to mention that
> there would be absolutely no testing outside of the NetBSD environment with
> NPF.  And, even if the PF code in NetBSD differes from  PF under OpenBSD,
> there would be enough similarity that some cross testing and patching would
> be helpful.
>    I know you fundamentally disagree with this analysis and I understand
> you are more familiar with the specific code inn question than I am, but I
> think the fundamental problem here is that the NetBSD network stack is in
> flux as folks work to MP-ify it and, the truth is, any firewall
> implementation in the stack is going to require a lot of effort to keep up
> with those changes.  As you've noted, firewalls are hard to write and
> maintain.  NPF might be a better solution than PF or IPF, but it certainly
> doesn't have as many eyes on it and there are a lot of folks who know how
> to use one or both of the other solutions who don't have a clue about how
> NPF works or should be configured.  I think dismissing that knowledge from
> the equation is a mistake and should factor heavily in the decision about
> which way we should go.
>    I also think Core should consider funding a project to either add the
> missing functionality to NPF, along with improving the documentation,  or
> funding a project to bring PF up to modern standards of functionality and
> scalability.
> 
> -thanks
> -Brian

What features, exactly, are missing?