Date: Sat, 21 Sep 1996 15:43:35 -0600 From: Warner Losh <imp@village.org> To: "David E. Tweten" <tweten@frihet.com> Cc: newton@communica.com.au (Mark Newton), spfarrel@midway.uchicago.edu, security@freebsd.org Subject: Re: comments on the SYN attack Message-ID: <199609212143.PAA02996@rover.village.org> In-Reply-To: Your message of "Sat, 21 Sep 1996 14:23:04 PDT." <199609212123.OAA08641@ns.frihet.com> References: <199609212123.OAA08641@ns.frihet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
One thing I'd like to add. While out killing the Thistles that have seen fit to invade my front yard, and thinking about some mail that Theo de Raat had sent me on this topic... As I'm sure most people know, the TCP three way handshake is: In the diagram below, B is establishing a connection to A, and each line represents the packets that arrive at each machine: A B SYN SYN ACK ACK ACK <data> Now, when the BSD kernel gets an SYN, and sends out the SYN ACK, it creates some state in its memory. The remote side gets the SYN ACK and considers the connection to be ESTABLISHED after sending the ACK ACK packet. When A gets the ACK ACK packet, it too thinks the connection is established. The problem that I came up with was as follows (with thanks to Theo for pointing it out): B sends the SYN, A sends the SYN ACK and places the insipient connection in a queue. B gets the SYN ACK and considers the connection open. B's socket then desides it wants to read, so it tries to do so. As we will see later, the read will fail sometimes. Meanwhile, A is under SYN attack. A is forced to discard the insipient connection to B due to a resource shortage. Then, the ACK ACK comes in. The code in FreeBSD will now say, "Hmmm, where did I put that pcb... Can't find it, send a RST." and the connection will reset, if I read the code correctly. This will cause B to die with a connection reset by peer, which many protocols won't retry. This makes discarding needlessly very expensive, and would likely tip the balance away from the randomly killing something in the insipient queue. Generally, one shouldn't drop these things unless you absolutely must. That's likely the desiding factor. I think that if you get the point of discarding stuff, then you are in trouble anyway. It would be nice to not discard it too soon. Also, if the rates are such that you know you can handle it, then I think the determanistic would be better. If they are absolutely hammering the snot out of you, then the random one would be better because the service is so crappy anyway that a little flakiness is better than no possibility of a connection. Bottom line: You don't want to drop these things if you can help it... Maybe I've missed something here, so please carefully read this and let me know what it is. Finally, I've not been offended by the discourse so far, but it is starting to sound flamelike in many respects. The general tone is degenerating somewhat, so unless there are striking new developments, I think I've said all I can and the rest will be quibbling over silly points that we really agree on... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609212143.PAA02996>