From proff Tue Sep 24 16:03:23 1996 Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id QAA10795 for best-of-security; Tue, 24 Sep 1996 16:03:23 +1000 Received: (sendmail@localhost) by suburbia.net (8.7.4/Proff-950810) id IAA26390 for ; Tue, 24 Sep 1996 08:34:03 +1000 Received: from roxanne.nuclecu.unam.mx(132.248.29.2) via SMTP by suburbia.net, id smtpd26374aaa; Mon Sep 23 22:33:22 1996 Received: (from root@localhost) by roxanne.nuclecu.unam.mx (8.6.12/8.6.11) id RAA18121 for netdev-outgoing; Mon, 23 Sep 1996 17:01:05 -0500 Received: from yonge.cs.toronto.edu (yonge.cs.toronto.edu [128.100.1.8]) by roxanne.nuclecu.unam.mx (8.6.12/8.6.11) with SMTP id RAA18111 for ; Mon, 23 Sep 1996 17:00:35 -0500 Received: from dvp.cs.toronto.edu ([128.100.1.15]) by yonge.cs.toronto.edu with SMTP id <86858>; Mon, 23 Sep 1996 17:47:03 -0400 Received: from localhost by dvp.cs.toronto.edu with SMTP id <15394>; Mon, 23 Sep 1996 17:26:27 -0400 To: netdev@roxanne.nuclecu.unam.mx cc: Alan Cox Subject: A new thought on TCP SYN attacks Date: Mon, 23 Sep 1996 17:26:18 -0400 From: "Eric Schenk" Message-Id: <96Sep23.172627edt.15394@dvp.cs.toronto.edu> Sender: owner-netdev@roxanne.nuclecu.unam.mx Precedence: bulk Reply-To: netdev@roxanne.nuclecu.unam.mx, "Eric Schenk" Approved: proff@suburbia.net I've been thinking a bit about D.J. Bernstein's proposed method of dealing with TCP SYN flooding, and I think I've come up with a new twist that might make it usuable, at least in some reasonable subset of cases. The original proposal from D.J. Bernstein was to take a secret, (changed every 75 seconds or so), the incoming address, port, and sequence number and the local address and port and run then through MD5 or some other secure hash to come up with a 32 bit sequence number for the outgoing response. When a data packet comes in that does not match a socket, we just check if the sequence numbers match the appropriate hash, and if so create a new socket. Objections to this proposal include: 1. The incoming MSS is not stored anywhere, which we need to know once we actually create the connection. 2. No initial RTT measurement will be possible, since we do not save the time. 3. TCP options such as RFC1323, SACK and T/TCP options cannot be used. 4. The sequence numbers generated by this scheme will not have the required seperation properties in sequence space to guarantee reliable TCP operation in the presence of old packets floating around the network. After some thought, I think I can address most of these concerns. 1. As pointed out in the discussion in comp.protocols.tcp-ip, there are not a lot of common MSS values. If we reserve 3 bits of the 32 bit initial sequence number to store a 3 bit index into a lookup table of likely MSS values, we can cover most cases. For cases that don't occur in the table, we simply pick the the largest choice in the table smaller than the proposed MSS. 2. I think this is a red herring. Currently, for various performance reasons we ignore RTT measures on SYN packets anyway. 3. Currently, we don't even implement any of these. I believe the timestamps portion of RFC1323 can be dealt with without needing to remember anything. Similarly for SACK. This would depend on our implementation beeing able to accept Timestamp options or SACK options that start occuring after the SYN packet. This should not be a big deal. The main thing to remember is that we should never initiate such options without seeing them first. Window scaling and T/TCP are problematic. I don't see how to deal with these at this time. 4. Spacing in the initial sequence number space. In my earlier message I worried that because we want to tie the ISN to a fast clock, that we would have to search a very large space to check validity, reducing the number of bits left for the cookie.. In fact, there is a handy clock we can tie it to that will not require more than a single check: namely, the ISN provided by the incoming SYN packet. Here is my basic idea: incoming information: saddr source address sport source port sseq source sequence number daddr destination address dport destination port We combine (saddr, sport, daddr, dport) with a random secret picked at boot time. Let t be the MD5 hash of this information. [Sharp readers will note that this is exactly the formula for an ISN in the current linux code.] Compute the outgoing ISN as (t + sseq). As long as the remote TCP is generating appropriately spaced initial sequence numbers, we will generate appropriately spaced initial sequence numbers. An attack would still need to know our random secret in order to spoof a connection without seeing any of our outgoing traffic. If an attacker can see our outgoing traffic, then they will be able to spoof a connection, but they could have done that anyway, even under the secure sequence number scheme we currently use. What I haven't covered yet, is the need to encode the MSS, and the issue of expiring "old" cookies. We can encode the MSS by replacing the top 3 or so bits of the cookie with an index into a table of MSS values. This reduces the security marginally. This leaves the issue of expiring cookies. Once we issue a cookie, a respondent on the far end can wait for an arbitrary period before responding, and still get a connection. This could be avoided by replacing some of the high order bits of the cookie with a randomly selected secret that changes once every few minutes. If we leave enough bits in the cookie depdendent on the incoming ISN, then we still avoid problems with sequence space wrap around. I should say that it is not clear to me that this additional complication is necessary. So the end result here is that we can deal with SYN flooding using constant space, provided that we don't want to implement window scaling or T/TCP. I'll give RFC1323 another look later tonight and see if I can figure out a way to get window scaling to work. T/TCP is probably harder. Comments? -- eric --------------------------------------------------------------------------- Eric Schenk www: http://www.cs.toronto.edu/~schenk Department of Computer Science email: schenk@cs.toronto.edu University of Toronto