Hi Ted, On May 1, 2013, at 1:14 AM, Ted Unangst <t...@tedunangst.com> wrote:
> On Wed, May 01, 2013 at 00:16, Franco Fichtner wrote: >> 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. > >> And talking about complexity: 1000 LOC for 25 protocols. I'm afraid >> it can't be simplified any more than this. > > Well, it's really hard to comment on code we can't see. I understand. The code is hooked up to a library feeding off of recorded network traces at the moment. The idea doesn't feel mature enough to me at this time, not knowing where to put it. So there's no point in releasing a half-done code blob that does nothing on its own, but I'm willing to share it off-list with OpenBSD developers. > My thoughts on the matter have always been that it would be cool to > integrate bpf into pf (though other developers surely have other > opinions). Then you get filtering for as many protocols as you care to > write bpf matchers for. You mean externalising the DPI? People[1] have tried to work on such ideas, but the general drift is that there are not enough interested individuals in the field to drive "second tier" development for application detections. I find C to be quite flexible and empowering if one doesn't overcomplicate[2]. Franco [1] https://code.google.com/p/appid/source/browse/trunk/apps/aim [2] https://github.com/fichtner/OpenDPI/blob/master/src/lib/protocols/ssl.c
