[4120] in linux-net channel archive
Re: SYN floods
daemon@ATHENA.MIT.EDU (Eric Schenk)
Tue Aug 20 19:09:56 1996
To: Pedro Roque Marques <roque@di.fc.ul.pt>
cc: linux-net@vger.rutgers.edu
In-reply-to: Your message of "Tue, 20 Aug 1996 16:34:57 EDT."
<199608202034.VAA15033@oberon.di.fc.ul.pt>
Date: Tue, 20 Aug 1996 17:56:45 -0400
From: "Eric Schenk" <schenk@cs.toronto.edu>
Pedro Roque Marques <roque@di.fc.ul.pt> writes:
>>>>>> "Lefty" == Lefty <lefty@sliderule.geek.org.uk> writes:
>
>
> Lefty> Also IPv6 will make this type of attack much more
> Lefty> difficult, and a lot easier to block (since routing info is
> Lefty> p[art of the addr, or something)
>
>No, IPv6 won't do that per se. IPsec can provide protection against
>that if you require the establishment of a security association prior
>to accepting a SYN. IPsec targets both versions of IP.
>
>isakmp has anti-clogging protection so it not enought to target your
>attack to the SA establishment mechanism. Interested readers are
>refered to section 1.7.1 of draft-ietf-ipsec-isakmp-05.txt.
>
>For those that don't believe that IPsec is a short term solution to
>this problem the proper path might lie in modifying TCP so that the
>reception of a SYN does not create a full socket but only some
>embryonic state. Timers for such sockets could be handled in a single
>timer handler (like BSD) instead of associating a timer for each.
>
>SYN_RECV sockets are not just a problem becaused of this "nice and
>well behaved" folks but problems can also happen when a valid source
>address in unreacheable from the server due to temporary routing
>failure (which is quite common this days).
I'm not sure an "embroyonic state" solves the problem.
There are two things we want to avoid here:
(1) running out of memory,
(2) having legitimate TCP users locked out.
(1) is protected against normally by having a maximum queue length
for sockets in the SYN_RECV state. But, this leads to the problem
where someone can lock out legitimate users by filling up the queue
with bogus SYN packets.
Any embronyonic state handler you introduce still has to track some
data for incoming packets, and so consumes some memory.
Therefore, we must place a limit on how many such incoming sockets
we want to allow at any one time, but in placing this limit, now
we leave ourselves open to having all the entries in this data
structure filled up.
So, what did you have in mind that is not covered by this, and that
does not require some non-compatible extension to the TCP protocol?
Oh yeah, while I'm on the topic, we currently sit in SYN_RECV way
too long, waiting for a sucessful connect. I do have a patch to fix this,
but it is not a defense against purposful SYN flooding.
-- eric
---------------------------------------------------------------------------
Eric Schenk www: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto
