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

Sorry for the late reply. It's a busy time right now.

In message <53D0239D.1050906_at_a1poweruser.com>, Fbsd8 writes:
> Cy Schubert wrote:
> >> On 20.07.2014 18:15, Maxim Khitrov wrote:
> >>> In my opinion, the way forward is to forget (at least temporarily) the
> >>> SMP changes, bring pf in sync with OpenBSD, put a policy in place to
> >>> follow their releases as closely as possible, and then try to
> >>> reintroduce all the SMP work. I think the latter has to be done
> >>> upstream, otherwise it'll always be a story of diverging codebases.
> >>> Furthermore, if FreeBSD developers were willing to spend some time
> >>> improving pf performance on OpenBSD, then Henning and other OpenBSD
> >>> developers might be more receptive to changes that make the porting
> >>> process easier.
> >> Even if you just drop current PF from FreeBSD, there is nobody, who want
> >> to port new PF from OpenBSD. And this is not easy task, as you may
> >> think. Gleb has worked on rewriting PF more than half year. So, return
> >> back all improvements after import will be hard enough and, again,
> >> nobody want to do it. :)
> > 
> > One way or another something needs to be done and agreed it would be a lot 
> > of work. Our options are,
> > 
> > a) Import OpenBSD pf thereby throwing away our current investment in pf. 
> > All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would
>  
> > be all for naught. We do get a new pf though. Won't be a quality port 
> > though. Personally, not my #1 option.
> > 
> > b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we
>  
> > do save the work we put into our pf. Once again a lot of work. We'd be 
> > introducing incompatibility.
> > 
> > c) Do nothing. It goes without saying that pf would suffer rot and 
> > eventually we would need to do something.
> > 
> > d) Yank pf from tree. An option but probably not a great one. We do have 
> > two other packet filters in the kernel (ipfw and ipfilter) however they are
>  
> > different beasts with different capabilities. I think the reason we have 
> > the packet filters we do have is for the capabilities they bring to the 
> > table. I for one have run more than one in the same kernel because each has
>  
> > different capabilities.
> > 
> > e) We could add capability to pf on a piecemeal basis. Option (b) but as 
> > time permits. Remember, people have jobs and commitments. Funding would 
> > help address this.
> > 
> > f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more 
> > compatible with our IP stack? Could this be an option?
> > 
> > Anything we do should work with VIMAGE and be able to handle nat66 as well.
> > 
> > 
> 
> Hello Cy;
> Finally a voice I recognize. If I remember correctly you stepped up to 
> the plate earlier this year and did for ipfilter the same kind of things

Last autumn.

> this thread is talking about for pf. IE; apply upstream maintenance and 
> convert to FreeBSD standards. I think your work was a BSD fork of 
> Darrow's ipfilter which from this point on all upstream maintenance must 
> be hand merged into the BSD fork. I am a long time ipfilter user and 

Actually we did not fork ipfilter. It's simply included into our tree, with 
a few modifications.

> thank you for your dedication and work ethics getting the updated 
> ipfilter into 10.0 and 9.3 so quickly.

You're welcome. I too am a long time ipfilter user (Solaris and FreeBSD).

> 
> So as someone who has been there and done that already you have unique 
> experience to really know the size of the task in hours to accomplish a 
> pf upgrade. Could you list the tasks and hours it took you to perform 
> the ipfilter upgrade so readers can have a real insight into what they 
> are asking for?

The experience is not unique. Every developer pretty much follows the same 
process when importing code into the tree. As for tasks, the ipfilter 
import was relatively simple compared to some others. Remember, ipfilter 
was designed to be run on any of the BSDs, SunOS, Solaris, and HP/UX, IRIX, 
and Tru64 UNIX. That made upgrading from 4.1.28 to 5.1.2 simpler than pf 
which is written only for OpenBSD and its stack.

> 
> I agree with your option "e" above, but I would re-word it this way.
> Using the pf fork we already have in place, hand merge upstream 
> differences in piecemeal chunks as time permits. The openbsd new syntax 
> being the first chunk, closely followed by VIMAGE awareness.

Personally I would choose option "e" because of $JOB and $FAMILY 
commitments.

Adding the new OpenBSD syntax may be more difficult than we might think. 
The new syntax may be related to a new internal structure of pf. If the new 
pf is a rewrite (ipfilter 5.1.2 was a rewrite of large chunks of code), 
then you have no option but to do a wholesale import and retrofit our mods 
back into it, if they would even fit at all.

I think the first task for anyone taking this on would be to familiarize 
oneself with the current pf code in FreeBSD and what was done to make it 
fit and to enhance it, then familiarize oneself with the new pf to get a 
feel for what work would be involved.

> 
> When it comes to someone volunteering to do the work, many of us would 
> step up, but the fact is only a very very few people have the coding and 
> kernel knowledge to even consider doing this.

Understanding the FreeBSD kernel helps but if a person doesn't have 
intimate knowledge of the FreeBSD kernel, you can always learn. There are 
some good books out there to help along the way. The Design and 
Implementation of the FreeBSD Kernel and Writing FreeBSD Device Drivers are 
two good examples. Of course having intimate knowledge is better but having 
worked on other kernels and understanding the nature of the beast goes a 
long way to working on any systems programming project, not just FreeBSD. 
If you understand how kernels generally operate you're more than half way 
there to volunteering and help out -- submit code and someone more senior 
on
the project can take it from there and help out with the effort. (Once 
again, many hands make light work.) I don't think people should feel afraid 
of systems programming (kernel programming).

The reason Linux gets so much more traction in any particular area of 
development is because they have many more people working on it. I would 
like to see more people pitch in and help out.


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_komquats.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.