On Wed, Feb 06, 2008 at 12:52:17AM +0300, Evgeniy Polyakov wrote:
quoted text
> Hi Alan.
> 
> On Tue, Feb 05, 2008 at 09:20:17PM +0000, Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> > > Most (if not all) distributions have them enabled and window growing
> > > works just fine. Actually I do not see any reason why connection
> > > establishment handshake should prevent any run-time operations at all,
> > > even if it was setup during handshake.
> > 
> > Syncookies are only triggered if the system is under a load where it
> > would begin to lose connections otherwise. So they merely turn a DoS into
> > a working if slightly slower setup (and > 64K windows don't matter for
> > most normal users, especially on mobile devices).
> 
> SACK is actually a good idea for mobile devices, so preventing
> syncookies from not getting into account some options (btw, does it work
> with timestamps and PAWS?) is not a solution.

All TCP options negociated during session setup are lost. In fact, some
bits (3) are still reserved for the best known value of the MSS, but
that's all. The principle of SYN cookies is that the server does not
create any session upon the SYN, but builds a sequence number constitued
from a hash and the values it absolutely needs to know when the client
validates the session with an ACK.

I've seen some firewalls acting as SYN gateways which send the options
from the server to the client in the first ACK packet from the server.
This is normally not allowed, but it seems to work with some TCP stacks
(at least for the MSS). One solution would be to extend TCP to officially
support this behaviour and to optionally use it along with SYN cookies,
but there will always be old clients not compatible with the extension.

Regards,
Willy

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/