Re: string match -> new option

[Patrick Schaaf <bof@bof.de>]

> Look at 'libqsearch' from Philipe Biondi.  (I don't have the URL here
> right now, but 'libqsearch' + 'kernel' on google gives you the result).

Thanks for the pointer! The homepage is at

	http://www.cartel-securite.fr/pbiondi/libqsearch.html

> This is the way to do pattern matching on TCP streams in the kernel...

Looks good at first glance, as a fast parallel pattern matcher. Really nice.

However, for full generality in application to TCP streams, one would
at least need an additional, upfront reorder step, to bring the
stream's packets into the correct order. If a packet it missing,
in the sequence, the search must be paused, with the question
of what to do with the already arrived head-of-sequence packet
(the packet after the perceived gap).

I still feel that such logic has already been implemented in the form
of the local network stack TCP layer; it would be wrong to reimplement
all of that in a separate stream matcher. That's why REDIRECT is my
preferred approach: it gets the packets through the TCP layer.

Thus, the critical question, to me, is less in the matching, than in
how to architect such a matching machinery above the TCP stack, without
paying the cost of a user level interface / application level gateway.
As occasionally mentioned, I think khttpd and the Tux web server are
the correct "role models" for a total solution to this really frequently
asked question. How to fit such a kernel daemon approach into configuration
by iptables?

Note that I don't feel like implementing anything like that, myself. No need,
no motivation.

best regards
  Patrick