Hi Alexey,

On Apr 30, 2013, at 11:51 PM, "Alexey E. Suslikov" <alexey.susli...@gmail.com> 

> Franco Fichtner <slashy83 <at> gmail.com> writes:
>> so I have been working on a BSD licensed DPI engine.  It's a
>> very lightweight, non-intrusive approach and I know that teasers
>> are boring, but I'd like to know if it's worth the time to
>> work on inclusion for pf(4).  So far I have about 25 supported
>> applications and the necessary hooks for the pf.conf(5) parts.
> If DPI stands for Deep Packet Inspection, than (afaik)
> it was discussed before: this kind of inspection is too
> complex to put into a kernel.

Yes, I am proposing a lightweight approach: hard-wired regex-like
code, no allocations, no reassembly or state machines.  I've seen
far worse things being put into Kernels and I assure you that I do
refrain from putting in anything that could cause segmentation
faults, sleeps, or other non-suitable behaviour.

> relayd already supports L7 filtering at least for http,
> so if something is to be improved in this area, relayd
> is better place, imo.

Would a protocol like BGP have a bright future in relayd(8)?
I don't know enough, maybe Reyk can clear this up?

L7 filtering is cute, but ipfw-classifyd isn't maintained, DPI in
Linux netfilter is not hitting it off, and there really is no
BSD DPI.  Franky, I don't care which way to go, but I believe
that pf(4) is a suitable candidate.  I especially like the one-
rule-to-rule-them-all approach.  Adding a keyword "app" to
pf.conf(5) seems like the simplest solution -- much like "proto"
does deal with IP types.

And talking about complexity: 1000 LOC for 25 protocols.  I'm afraid
it can't be simplified any more than this.

Thanks for your input,

Reply via email to