[3454] in bugtraq
Re: Excellent host SYN-attack fix for BSD hosts
daemon@ATHENA.MIT.EDU (Granville Moore)
Mon Oct 14 13:04:14 1996
Date: Mon, 14 Oct 1996 13:31:47 +0100
Reply-To: Granville Moore <granville_moore@il.us.swissbank.com>
From: Granville Moore <granville_moore@il.us.swissbank.com>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
"Charles M. Hannum" <mycroft@mit.edu> writes:
> Avi Freedman <freedman@netaxs.com> writes:
>
> >
> > No state is kept locally; when a SYN is received, an ISS is generated that
> > contains a few bits for reference into a table of MSS values; window size
> > and any initial data is discarded; and the rest of the ISS is the MD5
> > output
> > of a 32-byte secret and all of the interesting header info.
> This doesn't seem to deal with window scaling, which is a big lose on
> high-bandwidth networks. It also breaks TCP's algorithm for
> recognizing stale data.
I don't understand why window scaling would be a problem, since the window
size isn't included in the MD5, but I believe that the stale data issue can
be addressed by using a "rolling secret".
By changing the 32-byte secret, say every minute, retaining the old secret for
one minute, and checking incoming packets against both, you can be sure that
if a packets check out OK against either, then the original SYN must have been
processed within the last 2 minutes. Each ACK sent is good for at least one
minute (even if the secret changes immediately after it's generated). If the
variation in the timeout (1-2 minutes) isn't acceptable, it can be reduced by
changing the secret more often, and retaining more old versions on a rolling
basis (e.g. changing every 10 seconds, retaining 6 old copies would give a
timeout of between 60 and 70 seconds). By checking against old versions in an
"intelligent" order (decreasing order of hit-frequency would seem good), it
should be possible to minimise the overhead of multiple MD5 calculations.
Regards,
Granville
-----------------------------------------------------------------------
Granville Moore granville.moore@swissbank.com
Perot Systems at
SBC Warburg, London
Nothing in this message represents the views of
SBC Warburg or Perot Systems
-----------------------------------------------------------------------
