On Thu, Jan 25, 2007 at 09:20:55AM +1100, Andi Kleen wrote:

> > tcp.7 contains bad FUD about syncookies, 
> 
> I don't see any FUD in there

       tcp_syncookies (Boolean)
              Enable TCP syncookies.  The kernel must be  compiled  with  CON-
              FIG_SYN_COOKIES.  Send out syncookies when the syn backlog queue
              of a socket overflows.  The syncookies feature attempts to  pro-
              tect a socket from a SYN flood attack.  This should be used as a
                                                      ~~~~~~~~~~~~~~~~~~~~~~~~
              last resort, if at all.  This is a violation of the  TCP  proto-
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              col,  and  conflicts  with other areas of TCP such as TCP exten-
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              sions.  It can cause problems for clients and relays.  It is not
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              recommended  as a tuning mechanism for heavily loaded servers to
              help with overloaded or misconfigured  conditions.   For  recom-
              mended alternatives see tcp_max_syn_backlog, tcp_synack_retries,
              and tcp_abort_on_overflow.

I underlined the FUD.

Summary of facts:

- syncookies are a particular choice of initial sequence number. A host is
allowed to choose its inital sequence number. No violation there.

- as for the conflict: indeed, a connection saved by syncookies cannot use
large windows. But the connection would have been lost without syncookies,
because the backlog has to be full for syncookies to be used. So
effectively, you are saying that while syncookies 'conflict with TCP
extensions', dropping the connection attempts does not.

- because initial sequence numbers are arbitrary, a particular choice of
sequence number cannot cause problems for clients or relays, because they
can't assume anything about the ISN anyway.

- actually, there is no other working mechanism in the Linux kernel that
would allow a host to weather a syn flood while still being able to provide
TCP service on the attacked ports. (I guess you could come up with something
very complicated using tc, but that would still drop legitimate connections
from the same subnet as the attack.) Therefore, the best advice is in fact
to _enable_ syncookies unless the server has asymmetric bandwidth, with
upstream being much less than downstream.

But I'd be interested in hearing your arguments.

Andras

-- 
                 Andras Korn <korn at chardonnay.math.bme.hu>
                 <http://chardonnay.math.bme.hu/~korn/> QOTD:
           Sure you can trust the government. Just ask the Indians.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to