The Internet today is driven by machines that communicate using services layered on top of the TCP/IP protocols, these include HTTP, ftp and ssh, among others. The accessibility of these services is dependent on how well the underlying transport protocol performs, which in this case is TCP. If TCP is unable or unavailable to deliver the layered service to a remote machine, the user perceives the site as being dead or inaccessible. Perhaps merely an inconvenience in the past, this is a much more serious problem today as machines are being used for commerce and business.
One way that a malicious host can attempt to deny services provided by a server machine is by sending a large number of TCP open requests. These are known as SYN packets, named after the specific bit in the TCP specification, hence this type of Denial of Service attack is often called SYN bombing or SYN flooding. When the server receives this packet, it is interpreted as a request by the remote host to initiate a TCP connection, and at this point, the OS on the server machine commonly allocates resources to track the TCP state. By sending these requests in rapid succession, an attacker can exhaust the resources on the machine to the point where it becomes unresponsive, or crashes.
The server can attempt to reduce the impact of the flooding by changing the resource allocation strategy that it uses. One approach is to allocate minimal state when the initial request is received, and only allocate all the resources required when the connection is completed; this is termed a SYN cache. Another approach is to allocate no state, but instead send a cryptographic secret back to the originator, called a cookie; hence the name SYN cookie. Both approaches are intended to allow the machine to continue to provide its services to valid users.
The rest of this paper is structured as follows: Section 2 examines the details involved in the SYN flood Denial of Service attacks and examines the approaches of different defenses. Section 3 details the experimental setup used for testing, while Section 4 describes the current system behavior and motivation for change. Section 5 discusses the SYN cache implementation and presents the performance measurements from the change, while Section 6 does the same for SYN cookies. Section 7 discusses related work, and the paper concludes with a summary in Section 8.