draft-ietf-tcpm-syn-flood-00.txt   draft-ietf-tcpm-syn-flood-01.txt 
Network Working Group W. Eddy Network Working Group W. Eddy
Internet-Draft Verizon Federal Network Systems Internet-Draft Verizon Federal Network Systems
Expires: January 18, 2007 July 17, 2006 Expires: June 11, 2007 December 8, 2006
TCP SYN Flooding Attacks and Common Mitigations TCP SYN Flooding Attacks and Common Mitigations
draft-ietf-tcpm-syn-flood-00 draft-ietf-tcpm-syn-flood-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 18, 2007. This Internet-Draft will expire on June 11, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes TCP SYN flooding attacks, which have been This document describes TCP SYN flooding attacks, which have been
well-known to the community for several years. Various well-known to the community for several years. Various
countermeasures against these attacks, and the trade-offs of each, countermeasures against these attacks, and the trade-offs of each,
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 4 2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 4
2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Theory of Operation . . . . . . . . . . . . . . . . . . . 4 2.2 Theory of Operation . . . . . . . . . . . . . . . . . . . 4
3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 8 3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Filtering . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Filtering . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Increasing Backlog . . . . . . . . . . . . . . . . . . . . 8 3.2 Increasing Backlog . . . . . . . . . . . . . . . . . . . . 8
3.3 Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 8 3.3 Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 8
3.4 SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 9 3.5 SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 9
3.6 Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 10 3.6 Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 11
3.7 Firewalls and Proxies . . . . . . . . . . . . . . . . . . 10 3.7 Firewalls and Proxies . . . . . . . . . . . . . . . . . . 11
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. Informative References . . . . . . . . . . . . . . . . . . . . 14 7. Informative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
A. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 16 A. SYN Cookies Description . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20
1. Introduction 1. Introduction
The SYN flooding attack is a denial of service method affecting hosts The SYN flooding attack is a denial of service method affecting hosts
that run TCP server processes. The attack takes advantage of the that run TCP server processes. The attack takes advantage of the
state retention TCP performs for some time after receiving a SYN state retention TCP performs for some time after receiving a SYN
segment to a port that has been put into the LISTEN state. The basic segment to a port that has been put into the LISTEN state. The basic
idea is to exploit this behavior by causing a host to retain enough idea is to exploit this behavior by causing a host to retain enough
state for bogus half-connections that there are no resources left to state for bogus half-connections that there are no resources left to
establish new legitimate connections. establish new legitimate connections.
This SYN flooding attack has been well-known to the community for This SYN flooding attack has been well-known to the community for
many years, and has been observed in the wild by network operators many years, and has been observed in the wild by network operators
and end-hosts. A number of methods have been developed and deployed and end-hosts. A number of methods have been developed and deployed
to make SYN flooding less effective. Despite the notoriety of the to make SYN flooding less effective. Despite the notoriety of the
attack, and the widely available countermeasures, the RFC series has attack, and the widely available countermeasures, the RFC series only
not previously documented the vulnerability, nor suggested any documented the vulnerability as an example motivation for ingress
mitigation techniques for TCP implementations. The purpose of this filtering [RFC2827], and has not suggested any mitigation techniques
document is to satisfy both of these ends in an informational for TCP implementations. The purpose of this document is to satisfy
context. The advancement of (or need to advance) mitigation both of these ends in an informational context. The advancement of
techniques through the standards track is left to be considered as (or need to advance) mitigation techniques through the standards
further work for the IETF, and formal specifications and requirements track is left to be considered as further work for the IETF, and
of defense mechanisms are outside the scope of this document. formal specifications and requirements of defense mechanisms are
outside the scope of this document.
This document intentionally focuses on SYN flooding attacks from an
individual end-host or application's perspective, as a means to deny
service to that specific entity. Often, high packet-rate attacks
that target the network's packet processing capability and capacity
have been observed operationally. Since such attacks target the
network, and not a TCP implementation, they are out of scope for this
document, whether or not they happen to use TCP SYN segments as part
of the attack, as the nature of the packets used is irrelevant in
comparison to the packet-rate in such attacks.
This majority of this document consists of three sections. Section 2 This majority of this document consists of three sections. Section 2
explains the SYN flooding attack in greater detail. Several common explains the SYN flooding attack in greater detail. Several common
mitigation techniques are described in Section 3. An analysis and mitigation techniques are described in Section 3. An analysis and
discussion of these techniques and their use is presented in discussion of these techniques and their use is presented in
Section 4. Further information on SYN cookies is contained in Section 4. Further information on SYN cookies is contained in
Appendix A. Appendix A.
2. Attack Description 2. Attack Description
skipping to change at page 8, line 7 skipping to change at page 8, line 7
flooding attack. For instance, a "botnet" could be used. In this flooding attack. For instance, a "botnet" could be used. In this
case, each host utilized in the attack would have to supress its case, each host utilized in the attack would have to supress its
operating system's native response to the SYN-ACKs coming from the operating system's native response to the SYN-ACKs coming from the
target. It is also possible for the attack TCP segments to arrive in target. It is also possible for the attack TCP segments to arrive in
a more continuous fashion than the "barrage" terminology used here a more continuous fashion than the "barrage" terminology used here
suggests; as long as the rate of new SYNs exceeds the rate at which suggests; as long as the rate of new SYNs exceeds the rate at which
TCBs are reaped, the attack will be successful. TCBs are reaped, the attack will be successful.
3. Common Defenses 3. Common Defenses
This section discusses a number of defense techniques which are known
to the community, many of which are available in off-the-shelf
products.
3.1 Filtering 3.1 Filtering
Since the ability to send packets with spoofed source IP addresses is Since in the absence of an army of controlled hosts, the ability to
required for this attack to work, removing an attacker's ability to send packets with spoofed source IP addresses is required for this
send spoofed IP packets is an effective solution that requires no attack to work, removing an attacker's ability to send spoofed IP
modifications to TCP. The filtering techniques described in RFCs packets is an effective solution that requires no modifications to
2827, 3013, and 3704 represent the best current practices for packet TCP. The filtering techniques described in RFCs 2827, 3013, and 3704
filtering based on IP addresses [RFC2827][RFC3013][RFC3704]. While represent the best current practices for packet filtering based on IP
perfectly effective, end hosts should not rely on filtering policies addresses [RFC2827][RFC3013][RFC3704]. While perfectly effective,
to prevent attacks from spoofed segments, as global deployment of end hosts should not rely on filtering policies to prevent attacks
filters is neither guaranteed nor likely. An attacker with the from spoofed segments, as global deployment of filters is neither
ability to use a group of compromised hosts or to move around in the guaranteed nor likely. An attacker with the ability to use a group
network will also make filtering an impotent solution. of compromised hosts or to move around in the network will also make
filtering an impotent solution.
3.2 Increasing Backlog 3.2 Increasing Backlog
An obvious attempt at defense is for end hosts to use a larger An obvious attempt at defense is for end hosts to use a larger
backlog. Lemon has shown that in FreeBSD 4.4, this tactic has some backlog. Lemon has shown that in FreeBSD 4.4, this tactic has some
serious negative aspects as the size of the backlog grows [Lem02]. serious negative aspects as the size of the backlog grows [Lem02].
The implementation has not been designed to scale past backlogs of a The implementation has not been designed to scale past backlogs of a
few hundred, and the data structures and search algorithms that it few hundred, and the data structures and search algorithms that it
uses are inefficient with larger backlogs. It is reasonable to uses are inefficient with larger backlogs. It is reasonable to
assume that other TCP implementations have similar design factors assume that other TCP implementations have similar design factors
skipping to change at page 10, line 5 skipping to change at page 10, line 11
The exact mechanism for encoding state into the SYN-ACK sequence The exact mechanism for encoding state into the SYN-ACK sequence
number can be implementation dependent. A common consideration is number can be implementation dependent. A common consideration is
that to prevent replay, some time-dependent random bits must be that to prevent replay, some time-dependent random bits must be
embedded in the sequence number. One technique used 7 bits for these embedded in the sequence number. One technique used 7 bits for these
bits and 25 bits for the other data [Lem02]. One way to encode these bits and 25 bits for the other data [Lem02]. One way to encode these
bits has been to XOR the initial sequence number received with a bits has been to XOR the initial sequence number received with a
truncated cryptographic hash of the IP address and TCP port number truncated cryptographic hash of the IP address and TCP port number
pairs, and secret bits. In practice, this hash has been generated pairs, and secret bits. In practice, this hash has been generated
using MD5. using MD5.
The problem with SYN cookies is that current schemes are incompatible The problem with SYN cookies is that commonly implemented schemes are
with some TCP options, if the cookie generation scheme does not incompatible with some TCP options, if the cookie generation scheme
consider them. For example, an encoding of the MSS advertised on the does not consider them. For example, an encoding of the MSS
SYN has been accommodated by using 2 sequence number bits to advertised on the SYN has been accommodated by using 2 sequence
represent 4 predefined common MSS values. Similar techniques would number bits to represent 4 predefined common MSS values. Similar
be required for some other TCP options, while negotiated use of other techniques would be required for some other TCP options, while
TCP options can be detected implicitly. A timestamp on the ACK, as negotiated use of other TCP options can be detected implicitly. A
an example, indicates that Timestamp use was successfully negotiated timestamp on the ACK, as an example, indicates that Timestamp use was
on the SYN and SYN-ACK, while the reception of a SACK option at some successfully negotiated on the SYN and SYN-ACK, while the reception
point during the connection implies that SACK was negotiated. Note of a SACK option at some point during the connection implies that
that SACK blocks should normally not be sent by a host using TCP SACK was negotiated. Note that SACK blocks should normally not be
cookies unless they are first received. For the common sent by a host using TCP cookies unless they are first received. For
unidirectional data flow in many TCP connections, this can be a the common unidirectional data flow in many TCP connections, this can
problem, as it limits SACK usage. For this reason, SYN cookies be a problem, as it limits SACK usage. For this reason, SYN cookies
typically default to off on systems that implement them, and are only typically default to off on systems that implement them, and are only
enabled either under high-stress conditions indicative of an attack, enabled either under high-stress conditions indicative of an attack,
or via adminstrative action. or via adminstrative action.
Recently, a new SYN cookie technique developed for release in FreeBSD
7.0 leverages the bits of the Timestamp option in addition to the
sequence number bits for encoding state. Since the Timestamp value
is echoed back in the Timestamp Echo field of the ACK packet, any
state stored in the Timestamp option can be restored similarly to the
way that it is from the sequence number / acknowledgedment in a basic
SYN cookie. Using the Timestamp bits, it is possible to explicitly
store state bits for things like send and receive window scales,
SACK-allowed, and TCP-MD5-enabled, that there is no room for in a
typical SYN cookie. This use of Timestamps to improve the
compromises inherrent in SYN cookies is unique to the FreeBSD
implementation, to our knowledge. A limitation is that the technique
can only be used if the SYN itself contains a Timestamp option, but
this option seems to be widely implemented today, and hosts that
support window scaling and SACK typically support timestamps as well.
Similarly to SYN caches, SYN cookies do not handle application data Similarly to SYN caches, SYN cookies do not handle application data
piggybacked on the SYN segment. piggybacked on the SYN segment.
Another problem with SYN cookies is for applications where the first
application data is sent by the passive host. If this host is
handling a large number of connections, then packet loss may be
likely. When a handshake-completing ACK from the initiator is lost,
the passive side side's application-layer never is notified of the
connection's existence and never sends data, even though the
initiator thinks that the connection has been successfully
established. An example application where the first application-
layer data is sent by the passive side is SMTP, if implemented
according to RFC 2821, where a "service ready" message is sent by the
passive side after the TCP handshake is completed.
3.6 Hybrid Approaches 3.6 Hybrid Approaches
The SYN cache and SYN cookie techniques can be combined. For The SYN cache and SYN cookie techniques can be combined. For
example, in the event that the cache becomes full, then SYN cookies example, in the event that the cache becomes full, then SYN cookies
can be sent instead of purging cache entries upon the arrival of new can be sent instead of purging cache entries upon the arrival of new
SYNs. Such hybrid approaches may provide a strong combination of the SYNs. Such hybrid approaches may provide a strong combination of the
positive aspects of each approach. Lemon has demonstrated the positive aspects of each approach. Lemon has demonstrated the
utility of this hybrid. utility of this hybrid.
3.7 Firewalls and Proxies 3.7 Firewalls and Proxies
skipping to change at page 14, line 9 skipping to change at page 15, line 9
default, however, the mechanisms for defeating SYN flooding are well default, however, the mechanisms for defeating SYN flooding are well
deployed, and easily enabled by end-users. The publication of this deployed, and easily enabled by end-users. The publication of this
document should not influence the number of SYN flooding attacks document should not influence the number of SYN flooding attacks
observed, and might increase the robustness of the Internet to such observed, and might increase the robustness of the Internet to such
attacks by encouraging use of the commonly available mitigations. attacks by encouraging use of the commonly available mitigations.
6. Acknowledgements 6. Acknowledgements
A conversation with Ted Faber was the impetus for writing this A conversation with Ted Faber was the impetus for writing this
document. Comments and suggestions from Joe Touch, Dave Borman, document. Comments and suggestions from Joe Touch, Dave Borman,
Fernando Gont, Jean-Baptiste Marchand, Christian Huitema, and Caitlin Fernando Gont, Jean-Baptiste Marchand, Christian Huitema, Caitlin
Bestler were useful in strengthening this document. Bestler, Pekka Savola, and Andre Oppermann were useful in
strengthening this document.
Work on this document was performed at NASA's Glenn Research Center. Work on this document was performed at NASA's Glenn Research Center.
Funding was partially provided by a combination of NASA's Advanced Funding was partially provided by a combination of NASA's Advanced
Communications, Navigation, and Surveillance Architectures and System Communications, Navigation, and Surveillance Architectures and System
Technologies (ACAST) project, the Sensis Corporation, and NASA's Technologies (ACAST) project, the Sensis Corporation, NASA's Space
Space Communications Architecture Working Group. Communications Architecture Working Group, and NASA's Earth Science
Technology Office.
7. Informative References 7. Informative References
[AN97] Aura, T. and P. Nikander, "Stateless Connections", [AN97] Aura, T. and P. Nikander, "Stateless Connections",
Proceedings of the First International Conference on Proceedings of the First International Conference on
Information and Communication Security , 1997. Information and Communication Security , 1997.
[CA-96.21] [CA-96.21]
CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP
Spoofing Attacks", September 1996. Spoofing Attacks", September 1996.
skipping to change at page 14, line 38 skipping to change at page 15, line 40
[CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet [CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet
Security", ISBN: 0201633574, January 1994. Security", ISBN: 0201633574, January 1994.
[Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN [Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN
Cache", BSDCON 2002, February 2002. Cache", BSDCON 2002, February 2002.
[MNJH04] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [MNJH04] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", (draft-ietf-hip-base-03), "Host Identity Protocol", (draft-ietf-hip-base-03),
June 2005. June 2005.
[P48-13] daemon9, "Project Neptune", Phrack Magazine, Volume 7, [P48-13] daemon9, route, and infinity, "Project Neptune", Phrack
Issue 48, File 13 of 18, July 1996. Magazine, Volume 7, Issue 48, File 13 of 18, July 1996.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed
serial links", RFC 1144, February 1990. serial links", RFC 1144, February 1990.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
skipping to change at page 16, line 5 skipping to change at page 17, line 5
Wesley M. Eddy Wesley M. Eddy
Verizon Federal Network Systems Verizon Federal Network Systems
NASA Glenn Research Center NASA Glenn Research Center
21000 Brookpark Rd, MS 54-5 21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135 Cleveland, OH 44135
Phone: 216-433-6682 Phone: 216-433-6682
Email: weddy@grc.nasa.gov Email: weddy@grc.nasa.gov
Appendix A. SYN Cookies Appendix A. SYN Cookies Description
This information is taken from Bernstein's web page on SYN cookies . This information is taken from Bernstein's web page on SYN cookies .
This is a rewriting of the technical information on that web page and This is a rewriting of the technical information on that web page and
not a full replacement. There are other slightly different ways of not a full replacement. There are other slightly different ways of
implementing the SYN cookie concept than the exact means described implementing the SYN cookie concept than the exact means described
here, although the basic idea of encoding data into the SYN-ACK here, although the basic idea of encoding data into the SYN-ACK
sequence number is constant. sequence number is constant.
A SYN cookie is an initial sequence number sent in the SYN-ACK, that A SYN cookie is an initial sequence number sent in the SYN-ACK, that
is chosen based on the connection initiator's initial sequence is chosen based on the connection initiator's initial sequence
 End of changes. 15 change blocks. 
53 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/