[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: packet filters for NetBSD in the future
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
> 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
>> 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?
"UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity." Dennis Ritchie
Main Index |
Thread Index |