On Wed, 1 May 2013, Franco Fichtner wrote: > Not sure if that's a fitting comparison; and I know too little OSPF > to answer. Let me try another route. The logic consists of an array > of application detection functions, which can be invoked via their > respective IP types.
I don't like this approach at all - it leads to a proliferation (as demonstrated by your already long list) of kernel-side parsers that will be a maintenance, and possibly security, nightmare. The last thing we want it a rotting pile of protocol parsing code like wireshark. > On May 1, 2013, at 1:14 AM, Ted Unangst <t...@tedunangst.com> wrote: > > > 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. So if there is not enough interest to develop app protocol detectors/ disectors in bpf then why should C be any different? > I find C to be quite flexible and empowering > if one doesn't overcomplicate[2]. > > [2] https://github.com/fichtner/OpenDPI/blob/master/src/lib/protocols/ssl.c That's complicated and scary code for a kernel, e.g. multiple opportunities for unsigned overflow that don't seem to be checked for. I agree with tedu - it safer and more flexible to write parsers in bpf. If that isn't desirable then maybe we could consider some other automata classifier, but I think it is a bad, bad idea to do it in C. -d
