On Wed, Dec 20, 2006 at 10:24:16AM -0800, Rob wrote: > I'd like to get some feedback on the feasibility of some new features for pf > and the feasibility of them being implemented by the current pf hackers. > > For large table support, what do people think of the idea of "read only" > external tables. For instance, using CDB
Interesting... I can't think of an example where I'd want a large high-speed
table that rarely changes, but I'm sure they exist.
> The second more outlandish feature I call "The Decider" which would be
> similar to read only tables but would communicate with an external program
> which could use more complex criteria to decide if that packet was part of
> the dynamic table or not.
> Basically, a process driven dynamic table lookup:
>
> decider <tdcd1> 127.0.0.1:2727 400ms:no
>
> block drop quick log on $ext_if from {<tdcd1:spammer_chk>}
>
> pf would pass the packet details and the parameter after the decider_name:
> and would get a yes/no response, maybe an optional timeout is included in
> the decider
> declaration and if it is exceeded it defaults to whatever is specified.
> Of course, this would be painfully slow and when misused would cause people
> to bitch about pf being slow.
I have no idea if pf can hang onto a packet, especially incoming, long enough
for a call to userland, but I think anything we can do to make pf more
flexible (or to reduce the need to be skilled in kernelspace coding) would
be beneficial.
Another alternative is to upload the code into kernelspace into a sandbox.
If people are interested in this, it can be done with x86 code by re-writing
and incurs something like a < 20% penalty. The paper describing this won
best paper award recently by Usenix.
--
A: No.
Q: Should I include quotations after my reply?
<URL:http://www.subspacefield.org/~travis/> -><-
pgp4ZhmHrmVyo.pgp
Description: PGP signature
