Solution To DoS Attacks
Steve Gibson of grc.com claims to have come up with a way of preventing DoS attacks by spoofed SYN flooding. The idea is that no information is retained by the server after the initial SYN is received. The server's resources aren't used until the ACK is received from the client (which must have a real address to receive the reply from the server). The SYN/ACK back from the server is encrypted to prevent "ACK flooding." It can be implemented in a way that is transparent to clients, so only servers need alteration. I'm skeptical (and this only solved one kind of DoS), but it's worth looking at.
The whole reason you don't want to use an array like you describe is that it requires that the server dedicate resources -- an array entry -- to a connection before the client's location is verified by the three-way handshake. This is exactly why syn floods work, by filling up the queue with bogus connection requests that never complete.
Dan Bernstein also has an old old web page in which he describes this idea in the context of IPV4:
http://cr.yp.to/syncookies.html
This idea -- invented by Phil Karn for IPV6 and known as Photuris cookies there -- was long ago implemented in IPV4 to prevent SYN floods. It's descried in several RFCs and it's available in the Linux Kernel as the "SYN cookies" option.
we put this into the linux kernel in early 2.1. the define is CONFIG_SYN_COOKIES and it also needs a sysctl/proc option to be enabled (net.ipv4.tcp_syncookies)
... it works.
basically, you make your syn a function of the session's data (local and remote port, hostname, and syn) and some secret. then when the ACK returns with your SYN (and all the original data), you can inverse the function to see if it matches.
if you make this function a cryptographically strong one-way hash and use a good secret, the cookie is fairly undeterministic
in linux, we do this exactly:
our_initial_syn = one_way_hash(src.port, dst.port, src.host, dst.host, secret) + src.initial.syn;
by adding on, and not using as an argument, the initial syn, we can keep our syns properly spaced. the secret is a counter that is incremented every minute. this acts as a method for checking for old acks, too.
the TSB is not created until the final ack is received. the MSS is encoded in 3-bits in our syn (so our syn is 2^28 bits secure). no TSBs until ACK means no queue size
see http://cr.yp.to/syncookies.html for the initial discussion of implementation.
robert m love
my initials at tech9 dot net
1) Legalize drugs.
2) Legalize prostitution.
3) Create a welfare type program for those who do not get enough sex or need to do drugs in order to not use the computer.
That should take care of just about all the problems in society. You're welcome.
It's a joke, laugh.
Mas vale cholo, que mal acompañado.