On 2013/05/01 00:16, Franco Fichtner wrote: > 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.
Would it be fair to describe it as a bit more complex than osfp, but not hugely so? > > 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. What sort of protocols do you think could be reasonably handled by this approach, and what would be too complicated? There is definitely something appealing about being able to say, for example, 'block proto tcp on port 443; pass proto tcp on port 443 app tls', or 'block app ssh; pass proto tcp from <somehosts> to port 22 app ssh' without a bunch more complexity involved in passing across to a separate proxy (which would then need to implement its own completely separate filtering and would, I think, not really be able to integrate with things like PF tags and queue assignment)... Basically what I'm wondering if it's possible to go far enough to be useful whilst keeping the complexity down to a level which is sane and simple enough that it can be carefully audited.
