Date: Sat, 16 Jun 2001 12:30:21 +0200 From: Stefan Esser <se@freebsd.org> To: Jesper Skriver <jesper@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org, cvs-all@FreeBSD.org, Stefan Esser <se@freebsd.org> Subject: Re: cvs commit: src/sys/netinet tcp_input.c Message-ID: <20010616123021.A2365@StefanEsser.FreeBSD.org> In-Reply-To: <200106061941.f56Jfqf74472@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-06-06 12:41 -0700, Jesper Skriver <jesper@FreeBSD.org> wrote: > One way we can reduce the amount of traffic we send in response to a SYN > flood is to eliminate the RST we send when removing a connection from > the listen queue. Since we are being flooded, we can assume that the > majority of connections in the queue are bogus. Our RST is unwanted > by these hosts, just as our SYN-ACK was. Genuine connection attempts > will result in hosts responding to our SYN-ACK with an ACK packet. We > will automatically return a RST response to their ACK when it gets to us > if the connection has been dropped, so the early RST doesn't serve the > genuine class of connections much. In summary, we can reduce the number > of packets we send by a factor of two without any loss in functionality > by ensuring that RST packets are not sent when dropping a connection > from the listen queue. Hmmm, I'm not sure that we really: "can reduce the number of packets ... without any loss in functionality" There was a discussion on the effect of ACK flooding (sending ACK only packets for which no socket exists) one year ago. The problem is, that after the hash method does not find the socket, a linear search is performed and even a small rate of such bogus packets can significantly load a server, if there are thousands or ten-thousands of sockets to check ... This is exactly the situation during a SYN flood attack on a highly loaded server, and it appears that by removing the socket from the listen queue without a RST, we will increase the number of ACK only packets sent from legitimate clients. At the time of the attacks against Amazon, Yahoo et.al. it was found, that a stateful packet filter was the best protection against bogus ACK packets entering the TCP stack. (That was the reason "keep-state" and "check-state") were added to IPFW. But in case of a real client connection being dropped, the stateful packet filter will allow the ACK through, since the connection was correctly initiated. I seem to remember, that even a rate of only 100 ACK/s for which no socket is found by means of the hash search may be an effective DoS attack on a busy web server! I'm not sure whether the above is a real threat (and I can't easily test the effect of the patch, currently). But I think we should not MFC the change, unless we know that it does not increase the effect of a SYN flood by adding excessive CPU load to what used to be just a problem of memory wasted by bogus sockets ... If it really turns out to be a problem, then we might want to add support to our stateful packet filters, which drops the validity tag for connection parameters belonging to dropped connections (those for which no data could be delivered because the socket has been deleted). I could be wrong! But I didn't want to let the change go by without any mention of my worry that it might have unexpected side effects ... Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010616123021.A2365>