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

> 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.


Reply via email to