Date:   Mon, 25 Sep 2000 12:02:05 -0700 (PDT)
From:   Dan Hollis <goemon@anime.net>
To:     linux-net@vger.kernel.org
cc:     linux-kernel@vger.kernel.org
Subject: Better than SYNcookies?

I dont know how many here read /. but recently someone's gone round
touting a new SYN defense system that he claims is better than SYNcookies.

    http://grc.com/r&d/NoMoreDoS2.htm

Specifically, Steve Gibson <support@grc.com> claims:
<QUOTE>
I followed those links and read about SYN Cookies yesterday after
Torinak mentioned them for the first time. The SYN Cookie system does,
indeed, have a similar concept to what I came up with.

From my reading of everything I've been able to find in archived four-
year old threads, they appear to have over-complicated, and thus
broken, their solution and ended up deciding that it was a bad idea.
They incorporate a whole unnecessary handful of junk into the
formation of their "cookie" which is derived from an MD5 (message
digest) hash ... and they talk about incrementing a "secret" every
minute ... which is not necessary if the IP is encrypted as with my
system.

(Note that by incorporating the source port into their "cookie" they
make their "hash" algorithm easily explorable by anyone simply by
using different apparent source ports.  My solution has no such
vulnerability and weakness.)

And they have the problem of producing non-monotonically increasing
outbound initial sequence numbers in their SYN/ACK since the output of
the MD5 hash is deliberately non-monotonic. AND -- most significantly
- -- the original discussion threads I found discuss and acknowledge at
least some of these limitations.  So they knew their system had these
flaws.

Their solution -- because it was unstable and broke some important
aspects of TCP protocol (which mine does not) was NOT to use the
system all the time, but rather only to "switch it on" dynamically
when they detected that their server was under SYN flooding attack.
Someone mentioned that "switching it off and on" would thus create
another problem of essentially changing the "ISN" generation, thus
potentially creating non-unique sequences on the fly.

The bottom line is, I think that the previous efforts sort of suffered
from "committee design syndrome" and never really got off the ground
because they realized that the result would break too many other
things.
</QUOTE>

So is he right, is his solution better than SYNcookies and there is
something to be learned from his solution? Or does someone need to take
him to school on the issue.

- -Dan