In article <[EMAIL PROTECTED]>,
Patrick Schaaf <[EMAIL PROTECTED]> wrote:
>To write a really proper one, requires reimplementing or reusing the
>TCP/IP stack.
I disagree. For one thing, in many cases I can completely ignore the
data sent by one end of the connection--i.e. the side I'm not searching.
Secondly, packets fall into two classes:
- contains my entire search string, or does not contain any part
of my search string, or it's not a fragment or segment (not TCP
and not part of a fragmented packet). This packet class either
matches or it doesn't. If this packet is TCP and it is ACKed
by the receiver, then this packet also prevents matches within its
sequence number range +/- (length of the string) at both ends.
- begins with the end of, ends with the beginning of, or contains
exactly a contiguous subrange of my search string. Might match.
I don't need to keep any packet that fits into the first class. I don't
need to keep any packet that has been ACKed, except if that packet begins
or ends with the end or beginning of my string, respectively--and in that
case I need to keep length+offset, not the entire packet. I don't need
to modify packets or delay forwarding (assuming I don't care that the
receiver could get everything but the "V" in "EVIL STRING" before the
match triggers--if I do care, I'd be better off using REDIRECT instead).
All I need is to do TCP window reassembly or IP fragment reassembly,
and maybe mangle TCP window scaling and window size to deal with peers
who agree to use a multi-megabyte TCP window through the firewall.
I could also make life very easy for myself and prevent SACK or
fragmentation through rules that match strings.
This seems to me like much less than what the FTP or IRC conntrack
helpers are already doing without a full TCP/IP stack.
>Who says that the server REDIRECTed to must run at user level?
>What about a nice project making Tux (the kernel webserver)
>into a filtering Proxy?
Ah, now _that_ actually makes sense. I'd want something like that just
for hiding TCP/IP stacks behind firewalls, even if it just copied the
data without any further processing at all.
>Yeah! And offloaded to the NIC, too, so it will be even faster, and
>not misuse the I/O busses. [...]
>:-)
NICs aren't really faster. It's hard to find a NIC with two 2.0GHz
CPU's on it with 256K of L2 cache each. Most NICs I've seen would curl
up and die if they had to run anything as CPU- and memory-intensive as
netfilter at full line rate. :-)
--
Zygo Blaxell (Laptop) <[EMAIL PROTECTED]>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
