[4117] in linux-net channel archive
Re: SYN floods
daemon@ATHENA.MIT.EDU (Pedro Roque Marques)
Tue Aug 20 18:04:35 1996
Date: Tue, 20 Aug 1996 21:34:57 +0100
From: Pedro Roque Marques <roque@di.fc.ul.pt>
To: lefty@sliderule.geek.org.uk (Lefty)
Cc: alan@cymru.net, linux-net@vger.rutgers.edu, nelson@crynwr.com
In-Reply-To: <199608201623.QAA11776@sliderule.geek.org.uk>
>>>>> "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).
comments ?
./Pedro.
