[4249] in linux-net channel archive
Re: SYN floods
daemon@ATHENA.MIT.EDU (Rob Janssen reading Linux mailingl)
Sat Aug 31 09:37:03 1996
From: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
To: mill0440@gold.tc.umn.edu (Henry W Miller)
Date: Sat, 31 Aug 1996 09:52:33 +0200 (MET DST)
Cc: linux-net@vger.rutgers.edu
In-Reply-To: <Pine.SOL.3.91.960830200116.8456A-100000@gold.tc.umn.edu> from "Henry W Miller" at Aug 30, 96 08:11:46 pm
Reply-To: linux-vger@wab-tis.rabobank.nl
According to Henry W Miller:
> After some thought I think that this would provide some relief: on
> reciving any syn, handle it normally, but also send a series of ICMP
> pings to the host. If after a short amount of time no pings come back
> assume the host is dead, and kill the connection. I theory a ping should
> get through quickly, so we at least know there is a valid host behind
> this ip address.
This is useless. When a SYN is received, a "SYN ACK" is already sent
back to the sending host, and it replies with an ACK when the connection
has been correctly set up (the 3-way handshake) or with an RST when it
knows nothing about the connection (so it was apparently spoofed).
The problem exists in the time that has to elapse after receiving the
SYN and no reply on the SYN ACK, before the TCP layer can assume that
there is no route back to the sending system (or some other problem) and
the connection in SYN_RCVD state can be dropped.
Adding more traffic back to the sending host is not going to solve that.
When you get a reply on the ping, you probably also get the "ACK".
When you get no reply to the ping, you know just as much (or little) as
when you would not have sent it.
Rob
--
+------------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | BBS: +31-302870036 (2300-0730 local) |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+
