Defenses Against TCP SYN Flooding Attacks

by Wesley M. Eddy, Verizon Federal Network Systems

This article discusses a specific Denial of Service (DoS) attack known as TCP SYN Flooding. The attack exploits an implementation characteristic of the Transmission Control Protocol (TCP), and can be used to make server processes incapable of answering a legitimate client application's requests for new TCP connections. Any service that binds to and listens on a TCP socket is potentially vulnerable to TCP SYN flooding attacks. Because this includes popular server applications for e-mail, Web, and file storage services, understanding and knowing how to protect against these attacks is a critical part of practical network engineering.

The attack has been well-known for a decade, and variations of it are still seen. Although effective techniques exist to combat SYN flooding, no single standard remedy for TCP implementations has emerged. Varied solutions can be found among current operating systems and equipment, with differing implications for both the applications and networks under defense. This article describes the attack and why it works, and follows with an overview and assessment of the current tactics that are used in both end hosts and network devices to combat SYN flooding attacks.

Basic Vulnerability

The SYN flooding attack became well-known in 1996, when the magazines 2600 and Phrack published descriptions of the attack along with source code to perform it [1]. This information was quickly used in attacks on an Internet service provider's (ISP's) mail and Telnet servers, causing outages that were widely publicized in The Washington Post and The Wall Street Journal (among other venues). CERT quickly released an advisory on the attack technique [2].

The basis of the SYN flooding attack lies in the design of the 3-way handshake that begins a TCP connection. In this handshake, the third packet verifies the initiator's ability to receive packets at the IP address it used as the source in its initial request, or its return reachability. Figure 1 shows the sequence of packets exchanged at the beginning of a normal TCP connection (refer to RFC 793 for a detailed description of this process).

Figure 1: Normal TCP 3-Way Handshake

The Transmission Control Block (TCB) is a transport protocol data structure (actually a set of structures in many operations systems) that holds all the information about a connection. The memory footprint of a single TCB depends on what TCP options and other features an implementation provides and has enabled for a connection. Usually, each TCB exceeds at least 280 bytes, and in some operating systems currently takes more than 1300 bytes. The TCP SYN-RECEIVED state is used to indicate that the connection is only half open, and that the legitimacy of the request is still in question. The important aspect to note is that the TCB is allocated based on reception of the SYN packet— before the connection is fully established or the initiator's return reachability has been verified.

This situation leads to a clear potential DoS attack where incoming SYNs cause the allocation of so many TCBs that a host's kernel memory is exhausted. In order to avoid this memory exhaustion, operating systems generally associate a "backlog" parameter with a listening socket that sets a cap on the number of TCBs simultaneously in the SYN-RECEIVED state. Although this action protects a host's available memory resource from attack, the backlog itself represents another (smaller) resource vulnerable to attack. With no room left in the backlog, it is impossible to service new connection requests until some TCBs can be reaped or otherwise removed from the SYN-RECEIVED state.

Depleting the backlog is the goal of the TCP SYN flooding attack, which attempts to send enough SYN segments to fill the entire backlog. The attacker uses source IP addresses in the SYNs that are not likely to trigger any response that would free the TCBs from the SYN-RECEIVED state. Because TCP attempts to be reliable, the target host keeps its TCBs stuck in SYN-RECEIVED for a relatively long time before giving up on the half connection and reaping them. In the meantime, service is denied to the application process on the listener for legitimate new TCP connection initiation requests. Figure 2 presents a simplification of the sequence of events involved in a TCP SYN flooding attack.

Attack Methods

Figure 2: Attack Demonstration: Enough illegitimate TCBs are in 
SYN-RECEIVED that a legitimate connection cannot be initiated.

The scenario pictured in Figure 2 is a simplification of how SYN flooding attacks are carried out in the real world, and is intended only to give an understanding of the basic idea behind these types of attacks. Figure 3 presents some variations that have been observed on the Internet.

Figure 3: Some Variants of the Basic Attack

Direct Attack

If attackers rapidly send SYN segments without spoofing their IP source address, we call this a direct attack. This method of attack is very easy to perform because it does not involve directly injecting or spoofing packets below the user level of the attacker's operating system. It can be performed by simply using many TCP connect() calls, for instance. To be effective, however, attackers must prevent their operating system from responding to the SYN-ACKs in any way, because any ACKs, RSTs, or Internet Control Message Protocol (ICMP) messages will allow the listener to move the TCB out of SYN-RECEIVED. This scenario can be accomplished through firewall rules that either filter outgoing packets to the listener (allowing only SYNs out), or filter incoming packets so that any SYN-ACKs are discarded before reaching the local TCP processing code.

When detected, this type of attack is very easy to defend against, because a simple firewall rule to block packets with the attacker's source IP address is all that is needed. This defense behavior can be automated, and such functions are available in off-the-shelf reactive firewalls.

Spoofing-Based Attacks

Another form of SYN flooding attacks uses IP address spoofing, which might be considered more complex than the method used in a direct attack, in that instead of merely manipulating local firewall rules, the attacker also needs to be able to form and inject raw IP packets with valid IP and TCP headers. Today, popular libraries exist to aid with raw packet formation and injection, so attacks based on spoofing are actually fairly easy.

For spoofing attacks, a primary consideration is address selection. If the attack is to succeed, the machines at the spoofed source addresses must not respond to the SYN-ACKs that are sent to them in any way. A very simple attacker might spoof only a single source address that it knows will not respond to the SYN-ACKs, either because no machine physically exists at the address presently, or because of some other property of the address or network configuration. Another option is to spoof many different source addresses, under the assumption that some percentage of the spoofed addresses will be unrespondent to the SYN-ACKs. This option is accomplished either by cycling through a list of source addresses that are known to be desirable for the purpose, or by generating addresses inside a subnet with similar properties.

If only a single source address is repetitively spoofed, this address is easy for the listener to detect and filter. In most cases a larger list of source addresses is used to make defense more difficult. In this case, the best defense is to block the spoofed packets as close to their source as possible.

Assuming the attacker is based in a "stub" location in the network (rather than within a transit Autonomous System (AS), for instance), restrictive network ingress filtering [7] by stub ISPs and egress filtering within the attacker's network will shut down spoofing attacks—if these mechanisms can be deployed in the right places. Because these ingress/egress filtering defenses may interfere with some legitimate traffic, such as the Mobile IP triangle routing mode of operation, they might be seen as undesirable, and are not universally deployed. IP Security (IPsec) also provides an excellent defense against spoofed packets, but this protocol generally cannot be required because its deployment is currently limited. Because it is usually impossible for the listener to ask the initiator's ISPs to perform address filtering or to ask the initiator to use IPsec, defending against spoofing attacks that use multiple addresses requires more complex solutions that are discussed later in this article.

Distributed Attacks

The real limitation of single-attacker spoofing-based attacks is that if the packets can somehow be traced back to their true source, the attacker can be easily shut down. Although the tracing process typically involves some amount of time and coordination between ISPs, it is not impossible. A distributed version of the SYN flooding attack, in which the attacker takes advantage of numerous drone machines throughout the Internet, is much more difficult to stop. In the case shown in Figure 3, the drones use direct attacks, but to increase the effectiveness even further, each drone could use a spoofing attack and multiple spoofed addresses.

Currently, distributed attacks are feasible because there are several "botnets" or "drone armies" of thousands of compromised machines that are used by criminals for DoS attacks. Because drone machines are constantly added or removed from the armies and can change their IP addresses or connectivity, it is quite challenging to block these attacks.

Attack Parameters

Regardless of the method of attack, SYN flooding can be tuned to use fewer packets than a brute-force DoS attack that simply clogs the target network by sending a high volume of packets. This tuning is accomplished with some knowledge of the listener's operating system, such as the size of the backlog that is used, and how long it keeps TCBs in SYN-RECEIVED before timing out and reaping them. For instance, the attacker can minimally send a quick flight of some number of SYNs exactly equal to the backlog, and repeat this process periodically as TCBs are reclaimed in order to keep a listener unavailable perpetually.

Default backlogs of 1024 are configured on some recent operating systems, but many machines on the Internet are configured with backlogs of 128 or fewer. A common threshold for retransmission of the SYN-ACK is 5, with the timeout between successive attempts doubled, and an initial timeout of 3 seconds, yielding 189 seconds between the time when the first SYN-ACK is sent and the time when the TCB can be reclaimed.

Assuming a backlog of 128 and that an attacker generates 40-byte SYN segments (with a 20-byte TCP header plus a 20-byte IP header), the attacker has to send only 5.12 kilobytes (at the IP layer) in order to fill the backlog. Repeated every 189 seconds, this process gives an average data rate of only 27 bytes per second (easily achievable even over dialup links). This data rate is in stark contrast to DoS attacks that rely on sending many megabits per second of attack traffic. Even if a backlog of 2048 is used, the required data rate is only 433 bytes per second, so it is clear that the ease of attack scales along with increases to the backlog—and more sophisticated defenses are needed.

Lessons Learned

The protocol flaw in TCP that makes SYN flooding effective is that for the small cost of sending a packet, an initiator causes a relatively greater expense to the listener by forcing the listener to reserve state in a TCB. An excellent technique for designing protocols that are robust to this type of attack is to make the listener side operate statelessly [3] until the initiator can demonstrate its legitimacy. This principle has been used in more recent transport protocols, such as the Stream Control Transmission Protocol(SCTP) [4], which has a 4-way handshake, with listener TCB state being created only after the initiator echoes back some "cookie" bytes sent to it by the listener. This echo proves to some extent that the initiator side is at the address it appears to be (that is, it has return reachability) and is not attempting a SYN flooding style of attack.

Outside of transport protocols and TCBs, security protocols also commonly use this defense technique. For instance, the Internet Key Exchange Version 2 (IKEv2) [5] component of IPsec does not create state for a new Security Association until it can verify that initiators are capable of responding to packets sent to the address they claims to be using. There are other security protocols in which the listener sends out "puzzles" in response to initiation attempts and grants services or state only when puzzle solutions are returned [6]. This tactic not only verifies the addresses of initiators but also implies a computational burden that causes them to further demonstrate their genuine willingness to communicate productively.

Countermeasures

During the initial Panix attack, random spoofed source addresses were being used, but it was noted that the attack TCP SYNs all used the same source port number. A filter that denied incoming packets from this port was temporarily effective, but easy for the attacker to adapt to, and the attack segments began using random ports. Panix was able to isolate which of its ingress routers the attack was coming from and null-route packets destined for its servers coming through that router, but this solution was obviously a heavy-handed one, and seems to have also been overcome when the attacker started sending packets that were routed through a different upstream provider. Panix had mixed success in getting its providers to assist in tracing and blocking the attack, and the networking community was spurred into devising other solutions.

Two broad classes of solutions to SYN flooding attacks have evolved, corresponding to where the defenses are implemented. The first class of solutions involves hardening the end-host TCP implementation itself, including altering the algorithms and data structures used for connection lookup and establishment, as well as some solutions that diverge from the TCP state machine behavior during connection establishment, as described in RFC 793.

The second class involves hardening the network, either to lessen the likelihood of the attack preconditions (an army of controlled hosts or the propagation of IP packets with spoofed source addresses), or to insert middleboxes that can isolate servers on the networks behind them from illegitimate SYNs.

End-Host Countermeasures

Increasing TCP Backlog: Because the basic attack mechanism relies on overflowing a host's backlog of connecting sockets, an obvious end host-based solution is to simply increase the backlog, as is already done for very popular server applications. In at least some popular TCP implementations, this solution is known to be a poor one because of the use of linear list traversal in the functions that attempt to free state associated with stale connection attempts. Increasing the backlog is typically possible through altering the listen() call of an application and setting an operating system kernel parameter named SOMAXCONN, which sets an upper bound on the size of the backlog that an application can request. This step by itself should not be seriously considered as a means to defend against SYN flooding attacks—even in operating systems that can efficiently support large backlogs—because an attacker who can generate attack segments will most likely be able to scale to larger orders than the backlog supportable by a host.

Reducing the SYN-RECEIVED Timer: Another simple end host-based mechanism is to put a tighter limit on the amount of time between when a TCB enters the SYN-RECEIVED state and when it may be reaped for not advancing. The obvious disadvantage to this mechanism is that in cases of aggressive attacks that impose some amount of congestion loss in either the SYN-ACK or handshake-completing ACK packets, legitimate connection TCBs may be reaped as hosts are in the process of retransmitting these segments. Furthermore, there is only a linear relationship between the reduction that an administrator makes in the SYN-RECEIVED timer and the corresponding increase in packet rate that the adversary must make in order to continue attacking the server. Other alternative end-host solutions make it much more difficult for an attack to remain viable. For these reasons, a reduction in the SYN-RECEIVED timer is not an advisable defense against SYN flooding attacks.

Figure 4: Connection Establishment with SYN Cookies

SYN Caches: Two end-host defenses, called SYN caches and SYN cookies (described later), operate by reducing the amount of state allocated initially for a TCB generated by a received SYN, and putting off instantiating the full state [8]. In a host that uses a SYN cache, a hash table with a limited amount of space in each hash bucket is used to store a subset of the data that would normally go into an allocated TCB. If and when a handshake completing ACK is received, this data can be moved into a full TCB; otherwise the oldest bucket at a particular hash value can be reaped when needed. In Lemon's FreeBSD example [8], the SYN cache entry for a half connection is 160 bytes, versus 736 bytes for a full TCB, and 15359 entries in the SYN cache are supported.

The SYN cache data structure is robust to attackers attempting to overflow its buckets because it uses the initiator's local port number and some secret bits in the hash value. Because stacks are a more effective data structure to search than a simple linked list, stacks that use a SYN cache can have improved speed, even when not under attack. Under Lemon's tests, during an active attack a host using a SYN cache was able to establish legitimate connections with only about a 15-percent increase in latency.

SYN Cookies: In contrast to the SYN cache approach, the SYN cookies technique causes absolutely zero state to be generated by a received SYN. Instead, the most basic data comprising the connection state is compressed into the bits of the sequence number used in the SYN-ACK. Since for a legitimate connection, an ACK segment will be received that echoes this sequence number (actually the sequence number plus one), the basic TCB data can be regenerated and a full TCB can safely be instantiated by decompressing the Acknowledgement field. This decompression can be effective even under heavy attack because there is no storage load whatsoever on the listener, only a computational load to encode data into the SYN-ACK sequence numbers. The downside is that not all TCB data can fit into the 32-bit Sequence Number field, so some TCP options required for high performance might be disabled. Another problem is that SYN-ACKs are not retransmitted (because retransmission would require state), altering the TCP synchronization procedures from RFC 793.

Recent work by Andre Oppermann uses the TCP Timestamp option in conjunction with the Sequence Number field to encode more state information and preserve the use of high-performance options such as TCP Window Scaling, and TCP Selective Acknowledgment Options (SACK), and can also be used to preserve TCP-Message Digest 5 (MD5) support with SYN cookies. This option is a step forward, in that it removes the major negative effect of previous SYN cookie implementations that disabled these features.

Figure 5: Process for Generation and Validation of TCP SYN Cookies.

The exact format of TCP SYN cookies is not an interoperability issue, because they are only locally interpreted, and the format and procedures for generation and validation can vary slightly among implementations. Figure 5 depicts the general process of SYN cookie generation and validation used by multiple implementations.

To compute the SYN-ACK sequence number (that is, the TCP cookie) when using TCP cookies, a host first concatenates some local secret bits, a data structure that contains the IP addresses and TCP ports, the initial SYN sequence number, and some index data identifying the secret bits. An MD5 digest is computed over all these bytes, and some bits are truncated from the hash value to be placed in the SYN-ACK sequence number. Because the sequence number is about a fourth the size of the full hash value, this truncation is necessary, but generally at least 3 bytes worth of the hash bits are used, meaning that there should still be close to a 2^24 effort required to guess a valid cookie without knowing the local secret bits. In addition to the hash output, some of the cookie bits indicate a lower bound on the Maximum Segment Size (MSS) that the SYN contained, and the index bits identifying the local secret used within the hash.

To validate a SYN cookie, first the acknowledgement number in an incoming ACK segment is decremented by 1 to retrieve the generated SYN cookie. The valid value for the set of truncated hash bits is computed based on the IP address pair, TCP port numbers, segment sequence number minus one, and the value from the secret pool corresponding to the index bits inside the cookie. If these computed hash bits match those within the ACK segment, then a TCB is initialized and the connection proceeds. The encoded MSS bound is used to set a reasonable-sized MSS that is no larger than what was originally advertised. This MSS is usually implemented as three bits whose code points correspond to eight "commonly advertised" MSS values based on typical linkMaximum Transmission Units (MTUs) and header overheads.

Hybrid Approaches: A hybrid approach combines two or more of the single defense techniques described previously. For instance, some end-host operating systems implement both a large backlog and SYN cookies, but enable SYN cookies only when the amount of the backlog that is occupied exceeds some threshold, allowing them to normally operate without the disadvantages of SYN cookies, but also allowing them to fail over to the SYN-cookie behavior and be strongly protected when an attack occurs.

Network-Based Countermeasures

Filtering: The most basic network-level defense is application of the filtering techniques described in RFC 2827 [7]. Using ingress filtering, an ISP refuses to further route packets coming from an end site with IP source addresses that do not belong to that end site. Ingress filtering would be highly effective at preventing SYN flooding attacks that rely on spoofed IP packets. However, it is not currently reliable because ingress filtering policies are not universally deployed. Ingress filtering is also wholly ineffective against SYN flooding attacks that use a distributed army of controlled hosts that each directly attack. Ingress filtering is also a mechanism that an end site wishing to defend itself most often has no control over, because it has no influence upon the policies employed by ISPs around the world.

Firewalls and Proxies: A firewall or proxy machine inside the network can buffer end hosts from SYN flooding attacks through two methods, by either spoofing SYN-ACKs to the initiators or spoofing ACKs to the listener [9].

Figure 6 shows the basic operation of a firewall/proxy that spoofs SYN-ACKs to the initiator. If the initiator is legitimate, the firewall/ proxy sees an ACK and then sets up a connection between itself and the listener, spoofing the initiator's address. The firewall/proxy splits the end-to-end connection into two connections to and from itself. This splitting works as a defense against SYN flooding attacks, because the listener never sees SYNs from an attacker. As long as the firewall/proxy implements some TCP-based defense mechanism such as SYN cookies or a SYN cache, it can protect all the servers on the network behind it from SYN flooding attacks.

Figure 6: Packet Exchanges through a SYN-ACK spoofing Firewall/Proxy

Figure 7 illustrates the packet exchanges through a firewall/proxy that spoofs ACKs to the listener in response to observed SYN-ACKs. This spoofing prevents the listeners TCBs from staying in the SYN-RECEIVED state, and thus maintains free space in the backlog. The firewall/proxy then waits for some time, and if a legitimate ACK from the initiator is not observed, then it can signal the listener to free the TCB using a spoofed TCP RST segment. For legitimate connections, packet flow can continue, with no interference from the firewall/ proxy. This solution is more desirable than the mode of operation in Figure 5, where the firewall/proxy spoofs SYN-ACKs, because it does not require the firewall/proxy to actively participate in legitimate connections after they are established.

Figure 7: Packet Exchanges through an ACK-spoofing Firewall/Proxy.

Active Monitor: An active monitor is a device that can observe and inject traffic to the listener, but is not necessarily within the routing path itself, like a firewall is. One type of active monitor acts like the ACK-spoofing firewall/proxy of Figure 6, with the added capability of spoofing RSTs immediately if it sees SYNs from source addresses that it knows to be used by attackers [9]. Active monitors are useful because they may be cheaper or easier to deploy than firewall-based or filtering solutions, and can still protect entire networks of listeners without requiring every listener's operating system to implement an end-host solution.

Defenses in Practice

Both end-host and network-based solutions to the SYN flooding attack have merits. Both types of defense are frequently employed, and they generally do not interfere when used in combination. Because SYN flooding targets end hosts rather than attempting to exhaust the network capacity, it seems logical that all end hosts should implement defenses, and that network-based techniques are an optional second line of defense that a site can employ.

End-host mechanisms are present in current versions of most common operating systems. Some implement SYN caches, others use SYN cookies after a threshold of backlog usage is crossed, and still others adapt the SYN-RECEIVED timer and number of retransmission attempts for SYN-ACKs.

Because some techniques are known to be ineffective (increasing backlogs and reducing the SYN-RECEIVED timer), these techniques should definitely not be relied upon. Based on experimentation and analysis (and the author's opinion), SYN caches seem like the best end-host mechanism available.

This choice is motivated by the facts that they are capable of withstanding heavy attacks, they are free from the negative effects of SYN cookies, and they do not need any heuristics for threshold setting as in many hybrid approaches.

Among network-based solutions, there does not seem to be any strong argument for SYN-ACK spoofing firewall/proxies. Because these spoofing proxies split the TCP connection, they may disable some high-performance or other TCP options, and there seems to be little advantage to this approach over ACK-spoofing firewall/proxies. Active monitors should be used when a firewall/proxy solution is administratively impossible or too expensive to deploy. Ingress and egress filtering is frequently done today (but not ubiquitous), and is a commonly accepted practice as part of being a good neighbor on the Internet. Because filtering does not cope with distributed networks of drones that use direct attacks, it needs to be supplemented with other mechanisms, and must not be relied upon by an end host.

Related Attacks

In addition to SYN flooding, several other attacks on TCP connections are possible by spoofing the IP source address and connection parameters for in-progress TCP connections [10]. If an attacker can guess the two IP addresses, TCP port numbers, and a valid sequence number within the window, then a connection can be disrupted either through resetting it or injecting corrupt data. In addition to spoofed TCP segments, spoofed ICMP datagrams have the capability to terminate victim TCP connections.

Both these other attacks and SYN floods target a victim's TCP application and can potentially deny service to the victim using an attack rate less than that of brute-force packet flooding. However, SYN flooding and other TCP spoofing attacks have significant differences. SYN flooding denies service to new connections, without affecting in-progress connections, whereas other spoofing attacks disrupt inprogress connections, but do not prevent new connections from starting. SYN flooding attacks can be defended against by altering only the initial handshaking procedure, whereas other spoofing attacks require additional per-segment checks throughout the lifetime of a connection. The commonality between SYN flooding and other TCP spoofing attacks is that they are predicated on an attacker's ability to send IP packets with spoofed source addresses, and a similar defense against these attacks would be to remove this capability through more universal deployment of address filtering or IPsec.

Conclusion

At the time of this writing, the TCP SYN flooding vulnerability has been well-known for a decade. This article discussed several solutions aimed at making these attacks ineffective, some of which are readily available in commercial off-the-shelf products or free software, but no solution has been standardized as a part of TCP or middlebox function at the IETF level. The IETF's TCPMaintenance and Minor Extensions (TCPM) working group is in the process of producing an informational document that explains the positive and negative aspects of each of the common mitigation techniques [10], and readers are encouraged to consult this document for further information.

In this author's opinion, some variant of the SYN cache technique should be a mandatory feature to look for in a server operating system, and the variant can be deployed in combination with other network- based methods (address-based filtering, ACK-spoofing firewalls, IPsec, etc.) in appropriate situations. It is encouraging to see that protocol designers have learned a lesson from the SYN flooding vulnerability in TCP and have made more recent protocols inherently robust to such attacks.

Acknowledgements

Several individual participants in the IETF's TCPM working group have contributed bits of data found in the group's informational document on SYN flooding [11], some of which is replicated in spirit here.

References

[1] daemon9, route, and infinity, "Project Neptune," Phrack Magazine, Volume 7, Issue 48, File 13 of 18, July 1996.

[2] CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks," September 1996.

[3] Aura, T. and P. Nikander, "Stateless Connections," Proceedings of the First International Conference on Information and Communication Security, 1997.

[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol," RFC 2960, October 2000.

[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC 4306, December 2005.

[6] Aura, T., Nikander, P., and J. Leiwo, "DOS-resistant Authentication with Client Puzzles," Lecture Notes in Computer Science, Volume 2133, revised from the 8th International Workshop on Security Protocols, 2000.

[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing," BCP 38, RFC 2827, May 2000.

[8] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN Cache," BSDCON 2002, February 2002.

[9] Schuba, C., Krsul, I., Kuhn, M., Spafford, E., Sundaram, A., and D. Zamboni, "Analysis of a Denial of Service Attack on TCP," Proceedings of the 1997 IEEE Symposium on Security and Privacy, 1997.

[10] Touch, J., "Defending TCP Against Spoofing Attacks," Internet- Draft (work in progress), draft-ietf-tcpm-tcp-antispoof-05, October 2006.

[11] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations," Internet-Draft (work in progress), draft-ietf-tcpm-syn-flood-00, July 2006.

WESLEY M. EDDY works for Verizon Federal Network Systems as an onsite contractor at NASA's Glenn Research Center, where he performs research, analysis, and development of network protocols and architectures for use in space exploration and aeronautical communications.
E-Mail: weddy@grc.nasa.gov