Hi Alexey, On Apr 30, 2013, at 11:51 PM, "Alexey E. Suslikov" <alexey.susli...@gmail.com> wrote:
> 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, Franco
