Hi Damien, On May 2, 2013, at 10:03 AM, Damien Miller <d...@mindrot.org> wrote:
> 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. as stated before, breaking down complexity to the bare minimum is my requirement for this to be happening at all. You all get to be the judges. I'm just trying to work on something worth doing. > The last thing we want it a rotting pile of protocol parsing code like > wireshark. Case closed then? I don't know how to argue with that. >> 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? Because it takes complexity out of the system for one. Plus, pf(4) is at the core of OpenBSD. There's not much noise about bpf(4) here. >> 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. You are absolutely right. And it's *not* my code, it was merely an example of how the TLS code can be broken down to the bare minimum[1]. > 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. Again, I don't know how to argue with that. :) Kind regards, Franco [1] http://marc.info/?l=openbsd-tech&m=136739531914555&w=2
