Direct Server Return and SYN Floods

1. ________________________________________________________________

   This is part of a series on Direct Server Return
   1. A Quick Primer
   2. SYN Floods
   3. The Real World
   ________________________________________________________________
   SYN Flood
   Before we get into it, let’s take a quick look at the way TCP connections get setup using a three-way handshake. 
   
   1. The Client initiates the request by sending a SYN (synchronize) message to the Server.
2. 2. The server responds by sending SYN-ACK (acknowledge) back to the client.
3. 3. The client, in turn, sends an ACK, and we’re all setup.

What an UnGood Client can do, however is the following

1. 1. The UnGood person sends a bunch of SYN messages to the server, each of which has a fake source address.
2. 2. The server responds by sending SYN-ACK for each of these to the fake address.
3. 3. Importantly, the server keeps waiting for theACK from the fake address, which, of course, is never going to show up. What’s worse is that the server probably maintains a connection for this request, until, eventually, all of it’s connections get used up (not to mention other resources!).
4. 4. When our (very Good!) Client sends an honest SYN to the Server, the server doesn’t respond, because, frankly, the poor thing has run out of capacity and can’t respond

This is what is known as a SYN flood, and there are some fairly well known mechanisms to deal with it, from SYN cookies to kernel tweaking.

SYN Cookies
Daniel Bernstein came up with a remarkably clever way of working around SYN floods. It’s called SYN cookies, and it basically relies on some technicalities of how TCP works. To summarize it (kinda, sorta)

1. 1. The Client sends the Server a SYN
2. 3. The Server sends the Client a SYN-ACK, and embeds info about the SYN in the SYN-ACK (this is the “cookie”). It also promptly forgets about this SYN.
3. 3. The Client then sends the Server theACK which, because of the way TCP is designed, contains this “cookie” (technically, it contains “cookie+1” as its Acknowledgement number).
4. 4. The Server then reconstructs the SYNfrom the “cookie” in theACK, and proceeds to setup the connection as normal.

In case of a SYN flood, there really is no additional load on the Server, since it doesn’t actually keep any “state” (having forgotten each of the spoofed immediately after sending back a SYN-ACK containing the “cookie”)

DSR and SYN Floods
The tricky part with DSR, is that the SYN cookie mechanism described earlier get’s frightfully complicated. First, look at what happens without DSR, i.e., when all the traffic to and from the server goes through the Router.

1. 
   1. The Client and the Router negotiate a connection using the SYN-Cookie method described earlier
2. 2. The Router then sends a Spoofed SYN to the Server, which contains it’s source address as the Client’s address.
3. 3. The Server sends a SYN-ACK back to the Router, expecting that it would get to the client (remember, all it’s traffic goes through the Router!). The Router would just directly respond with an ACK, and everything would be hunky-dory.

Remember, however, that with DSR, the Server’s responses go directly to the client, and bypass the router.

So, instead of the above, here’s what happens

1. 1. The Client and the Router negotiate a connection using the SYN-Cookie method described earlier
2. 2. The Router then sends a Spoofed SYN to the Server, which contains it’s source address as the Client’s address.
3. 3. The Server sends a SYN-ACK to the Client, which is now ConfusedAF, since it has no record of any SYN to which this SYN-ACK corresponds. It promptly drops the SYN.
4. 4. The Server tries a few more times, and then drops the connection. If the router persists in trying to setup the connection it is effectively SYN flooding the Server!

The bottom line is that doing SYN Cookies on the Router is, well, not exactly trivial when doing DSR. Mind you, the point isn’t that it won’t work. It’s more that it requires a bit more care and feeding. The bigs (Cisco, F5, etc.) tend to provide mechanisms to deal with this, as part of their ValueAddedFeaturesThatCostMoney™.

OTOH, if you don’t have that kind of monies, you could take the easy way out, have the Router completely pass the buck to the servers — and not try to do anything with incoming SYN requests. The Servers, OTOH, are responsible for dealing with SYN Floods, and should implement SYN cookies, or some such. Be sure to monitor them and make sure nothing bad is happening, if you go down this path!