On May 2, 2013, at 3:20 PM, Damien Miller <d...@mindrot.org> wrote:

> On Thu, 2 May 2013, Franco Fichtner wrote:
>> OK, the implementation only pulls a couple of bytes from the packet's
>> payload. It will never pull bytes that are not verified. It will never
>> allocate anything. It will never test against something that's neither
>> hard-coded nor available in the range of the approved payload. It will
>> never return more than "unsigned int" with a number describing the
>> actual application. It will never manipulate any input value, lest of
>> all the packet itself. It will never run into endless loops. And I'll
>> gladly zap everything that could still considered be a potential risk.
> You've just described bpf, right down to "no endless loops" and the amount
> of data it returns.
> For a little more code that it takes to write one packet parser
> (basically: loading bpf rules from pf and making the bpf_filter()'s
> return value available to it) you get everything you described above and
> more.

I yield.  I'm working on making DPI more human-readable and maintainable,
and struct bpf_insn is not an option for me, personally.

Worse still, searching for bpf+dpi in google already brings up this mail
thread as a top ten hit, which may be a good indicator of how successful
this approach has been the last couple of years.  ;)


Reply via email to