SYN floods continueh

> Anyway. Point is this: We can't take too much more of this, nor can our
> customers. I have yet to hear *anyone* come up with any ideas even remotely
> reasonable for how to deal with this situation, long term, except for the
> filtering that Avi, Perry, and I have been promoting these last few days.

If hardening all hosts against forged source address SYN attacks is not
feasible then perhaps providing a hardened device in front of server
farms is. How about something that spoofs the TCP connection setup,
uses minimal resources for unconfirmed TCP connections and perhaps more
aggressively times out these connections when under attack. Basically
this firewall would not forward a SYN packet to a server from an unknown
host until that host had properly ACKd a SYN ACK from the firewall. The
resulting connection would require that the firewall adjust seq/ack
numbers before forwarding the packets between the host and server as
the pseudo random seq number used in the initial SYN ACK from the firewall
to the host will be different from that proposed eventually by the server.
And it makes sequence guessing attacks much harder as well.

An idea?

I've been focusing on routing for the last year and not kernel hacking, but
a better data structure (methinks for the whole kernel) for pending
embryonic connections is required. Hacking algorithms is easy; kernel data
structures hacking requires me to find my design & imp of the BSD os book.