[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I am a bit curious about what OpenBSD specific changes have
been made and if they have been passed on to Mr. Reed.
I usually built ipf anyway, and the lack of an OpenBSD target isn't
a problem, but it would be nice.
I don't get the impression the relationship between the people who
have contributed the effort towards OpenBSD mods to ipf and Mr.
Reed has been soured- or has it?
From: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of
Sent: Tuesday, May 29, 2001 10:48 PM
To: Michael Samuel; firstname.lastname@example.org
Subject: Re: ipf
*thud thud thud*
Christ, people. A packet filter, the evening's topic of conversation,
filters based on TCP, UDP, and IP headers. In the more complicated
revision, it also maintains TCP connection state, and pseudo-state for
If you want to do Layer 7, or pseudo-Layer 7 inspection of packets,
then you are talking about an application proxy firewall, more or
less. In which case YES, you can have the target of a packet rule be a
socket to a user-mode daemon upon certain criteria (ie, connection
setup or teardown or for all packets).
But I would _still_ advise people in search of that functionality to
look at FWTK.
Yes, context switches ARE that expensive, when you get over a certain
number of packets per second.
We are still speaking, correct, of a packet filter? One that must work
with saturated 100mbit links? At the _very_ least?
As for SMB in the kernel, remember that some idiots  strapped HTTP
into a linux kernel. That is MUCH closer an analogy. Anything for
performance tests, right?
 I say idiots, because the concept is mind-boggling to me, but by
all accounts you have to be pretty clever to pull that off. So lets
On Wed, May 30, 2001 at 03:27:01PM +1000, Michael Samuel wrote:
> On Wed, May 30, 2001 at 12:10:52AM -0500, Jeff Bachtel wrote:
> > What would be the security advantage? Packet filters don't parse
> > strings, or execve() programs, they filter. And thats it.
> Well, in this day in age, people like to do other things than just
> block according to the ip header details. Searching a packet data is
> a popular request nowadays for people in search of a filewall.
> > The reason you _don't_ put a packet filter in userspace is that a
> > context switch is added for each packet that traverses the firewall.
> Is the overhead of a context switch that much nowadays? If so, then
> that's another area of work. The only real problem I see is the extra
> copy of the packet in memory, which could be solved with an mmap()ed
> interface (right??).
> > And the only language to choose for a BSD packet filter is C. That is,
> > if you want it to be capable of handling linespeed.
> [ I won't bite on the language flamewar ]
> > (in short, the only thing userland about a firewall should be the
> > control programs)
> I understand where you're coming from, but then again, your reasoning
> is the same as Microsoft's reasoning for putting SMB into the NT kernel.
- Re: ipf
- From: obecian <email@example.com>
- Re: ipf
- From: Jeff Bachtel <firstname.lastname@example.org>