fOn Thu, May 02, 2013 at 04:03:05PM +0200, Franco Fichtner wrote:

> On May 2, 2013, at 3:20 PM, Damien Miller <> 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.

libpcap has a fairly simple parser to turn expressions into bpf instructions.
It is used by tcpdump.

> 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.  ;)
> Franco

Reply via email to