Re: packet filters for NetBSD in the future

[Ivo Vachkov <ivo.vachkov%gmail.com@localhost>]

Please, excuse my ignorance,

I just want to ask where to get the latest PF code from ? OpenBSD
source repositories ? FreeBSD source repositories ?

Thank you in advance.

On Sat, Feb 14, 2009 at 1:25 AM, matthew sporleder 
<msporleder%gmail.com@localhost> wrote:
> On 2/13/09, Quentin Garnier <cube%cubidou.net@localhost> wrote:
>> On Fri, Feb 13, 2009 at 10:07:09AM -0500, Thor Simon wrote:
>>  > I am curious about the future direction of NetBSD with regard to packet
>>  > filtering.  Here is why:
>>  >
>>  > 1) An intention to replace ipfilter with pf has been announced, but:
>>  >       * This appears to be largely on the ground that ipfilter is
>>  >         unmaintained in our tree, and
>>  >
>>  >       * pf is also currently unmaintained in our tree.
>>  >
>>  > 2) pf is considerably simpler than ipfilter (mostly, it seems, because it
>>  >    is much newer and has less historical portability baggage).
>>  >
>>  > 3) We have third and fourth filter engines in our tree, the ipsec security
>>  >    policy engine and the altq classification engine.  This is clearly
>>  >    redundant both in the source tree and at runtime (at runtime, doing
>>  >    PFIL_HOOKS filters and then two other kinds of filtering can slow
>>  >    things down considerably for little net gain).
>>  >
>>  >       * Itojun's intent was to unify the ipsec and altq filtering
>>  >         using pf as the engine.  This is a large part of why pf is
>>  >         currently in our tree, as I understand it.  Nobody has ever
>>  >         done the analogous work to let ipfilter serve this role.
>>  >
>>  > 4) pf is essentially subsystem-locked by the softnet lock.  On the
>>  >    other hand, ipfilter has much finer-grained locking because it can
>>  >    run in other kernels which have pushed locks down into the network
>>  >    stack.
>>  >
>>  > Given this set of facts, it's not clear to me what the right path
>>  > forward is.  #4 seems likely to be a considerable inconvenience in the
>>  > future if we go with pf.  On the other hand, ipfilter's author is a
>>  > NetBSD developer, but even he doesn't have time to maintain the version
>>  > in the NetBSD source tree (as far as I can tell) and it seems unlikely
>>  > that he or anyone else will step forward to address #3.
>>  >
>>  > Still nobody has stepped forward for the comparatively simple task of
>>  > updating and maintaining pf, either.
>>  >
>>  > What are others' opinions on this?
>>
>>  Another advantage pf had over ipfilter was binary compatibility with
>>  previous releases.  However, it is no longer true.
>>
>>  At this point I think the inconvenience is that we don't have any
>>  packet filter maintained in our tree.  Having one of them maintained
>>  would be an improvement regardless of the qualities each of them has
>>  over the other.
>>
>>  So if someone would step up and offer to maintain either one, that
>>  would be a very strong reason to keep the relevant filter instead of
>>  the other.
>>
>>  The thing that worries me is that people might be afraid to step up
>>  because they know they'll have to deal with a bunch a vocal people
>>  that will go at length explaining that the other filter is a lot more
>>  important to have in NetBSD, and that it's scandal that NetBSD is
>>  taking such a direction, etc.  Such is the reality of the NetBSD
>>  community.
>>
>>  So let me assure that if someone was to step up and show that they have
>>  the time and motivation to maintain either one, they'd receive my
>>  strongest support.
>>
>
> Doesn't a lot of this simply rehash the old arguments about generic
> interfaces for competing packet filters, classifiers, queuers,
> slowdowninators, zimbapiladors, etc?
>
> http://mail-index.netbsd.org/tech-net/2003/06/27/0013.html
> http://mail-index.netbsd.org/tech-kern/2005/07/01/0011.html
> http://mail-index.netbsd.org/current-users/2005/09/22/0021.html
>



-- 
"UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity." Dennis Ritchie