draft-ietf-tcpm-syn-flood-03.txt   draft-ietf-tcpm-syn-flood-04.txt 
Network Working Group W. Eddy Network Working Group W. Eddy
Internet-Draft Verizon Federal Network Systems Internet-Draft Verizon Federal Network Systems
Intended status: Informational April 18, 2007 Intended status: Informational May 14, 2007
Expires: October 20, 2007 Expires: November 15, 2007
TCP SYN Flooding Attacks and Common Mitigations TCP SYN Flooding Attacks and Common Mitigations
draft-ietf-tcpm-syn-flood-03 draft-ietf-tcpm-syn-flood-04
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 34 skipping to change at page 1, line 34
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 October 20, 2007. This Internet-Draft will expire on November 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Recycling the Oldest Half-Open TCB . . . . . . . . . . . . 9
3.5. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 11 3.6. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 11 3.7. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 11
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.8. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 19 8. Informative References . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
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.
skipping to change at page 3, line 32 skipping to change at page 3, line 32
for TCP implementations. This document addresses both points, but for TCP implementations. This document addresses both points, but
does not define any standards. Formal specifications and does not define any standards. Formal specifications and
requirements of defense mechanisms are outside the scope of this requirements of defense mechanisms are outside the scope of this
document. Many defenses only impact an end-host's implementation document. Many defenses only impact an end-host's implementation
without changing interoperability. These may not require without changing interoperability. These may not require
standardization, but their side-effects should at least be well standardization, but their side-effects should at least be well
understood. understood.
This document intentionally focuses on SYN flooding attacks from an This document intentionally focuses on SYN flooding attacks from an
individual end-host or application's perspective, as a means to deny individual end-host or application's perspective, as a means to deny
service to that specific entity. Often, high packet-rate attacks service to that specific entity. High packet-rate attacks that
that target the network's packet processing capability and capacity target the network's packet processing capability and capacity have
have been observed operationally. Since such attacks target the been observed operationally. Since such attacks target the network,
network, and not a TCP implementation, they are out of scope for this 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 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 of the attack, as the nature of the packets used is irrelevant in
comparison to the packet-rate in such attacks. comparison to the packet-rate in such attacks.
The majority of this document consists of three sections. Section 2 The 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.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
Security: Repelling the Wily Hacker" [CB94]. Unfortunately, no Security: Repelling the Wily Hacker" [CB94]. Unfortunately, no
countermeasures were developed within the next two years. countermeasures were developed within the next two years.
The SYN flooding attack was first publicized in 1996, with the The SYN flooding attack was first publicized in 1996, with the
release of a description and exploit tool in Phrack Magazine release of a description and exploit tool in Phrack Magazine
[P48-13]. Aside from some minor inaccuracies, this article is of [P48-13]. Aside from some minor inaccuracies, this article is of
high enough quality to be useful, and code from the article was high enough quality to be useful, and code from the article was
widely distributed and used. widely distributed and used.
By September of 1996, SYN flooding attacks had been observed in the By September of 1996, SYN flooding attacks had been observed in the
wild. Particularly, an attack against the Panix ISP's mail servers wild. Particularly, an attack against one ISP's mail servers caused
caused well-publicized outages. CERT quickly released an advisory on well-publicized outages. CERT quickly released an advisory on the
the attack [CA-96.21]. SYN flooding was particularly serious in attack [CA-96.21]. SYN flooding was particularly serious in
comparison to other known denial of service attacks at the time. comparison to other known denial of service attacks at the time.
Rather than relying on the common brute-force tactic of simply Rather than relying on the common brute-force tactic of simply
exhausting the network's resources, SYN flooding targets end-host exhausting the network's resources, SYN flooding targets end-host
resources, which it requires fewer packets to deplete. resources, which it requires fewer packets to deplete.
The community quickly developed many widely-differing techniques for The community quickly developed many widely-differing techniques for
preventing or limiting the impact of SYN flooding attacks. Many of preventing or limiting the impact of SYN flooding attacks. Many of
these have been deployed to varying degrees on the Internet, in both these have been deployed to varying degrees on the Internet, in both
end hosts and intervening routers. Some of these techniques have end hosts and intervening routers. Some of these techniques have
become important pieces of the TCP implementations in certain become important pieces of the TCP implementations in certain
skipping to change at page 5, line 20 skipping to change at page 5, line 20
describes the standard processing of incoming SYN segments. RFC 793 describes the standard processing of incoming SYN segments. RFC 793
describes the concept of a Transmission Control Block (TCB) data describes the concept of a Transmission Control Block (TCB) data
structure to store all the state information for an individual structure to store all the state information for an individual
connection. In practice, operating systems may implement this connection. In practice, operating systems may implement this
concept rather differently, but the key is that each TCP connection concept rather differently, but the key is that each TCP connection
requires some memory space. requires some memory space.
Per RFC 793, when a SYN is received for a local TCP port where a Per RFC 793, when a SYN is received for a local TCP port where a
connection is in the LISTEN state, then the state transitions to SYN- connection is in the LISTEN state, then the state transitions to SYN-
RECEIVED and some of the TCB is initialized with information from the RECEIVED and some of the TCB is initialized with information from the
header fields of the received SYN segment. In practice, this is not header fields of the received SYN segment. In practice, many
really how things work. Many operating systems do not alter the TCB operating systems do not alter the TCB in LISTEN, but instead make a
in LISTEN, but instead make a copy of the TCB and perform the state copy of the TCB and perform the state transition and update on the
transition and update on the copy. This is done so that the local copy. This is done so that the local TCP port may be shared amongst
TCP port may be shared amongst several distinct connections. This several distinct connections. This TCB-copying behavior is not
TCB-copying behavior is not actually essential for this purpose, but actually essential for this purpose, but influences the way in which
influences the way in which applications that wish to handle multiple applications that wish to handle multiple simultaneous connections
simultaneous connections through a single TCP port are written. The through a single TCP port are written. The crucial result of this
crucial result of this behavior is that instead of updating already- behavior is that instead of updating already-allocated memory, new
allocated memory, new (or unused) memory must be devoted to the (or unused) memory must be devoted to the copied TCB.
copied TCB.
As an example, in the Linux 2.6.10 networking code, a "sock" As an example, in the Linux 2.6.10 networking code, a "sock"
structure is used to implement the TCB concept. By examination, this structure is used to implement the TCB concept. By examination, this
structure takes over 1300 bytes to store in memory. In other systems structure takes over 1300 bytes to store in memory. In other systems
that implement less complex TCP algorithms and options, the overhead that implement less complex TCP algorithms and options, the overhead
may be less, although it typically exceeds 280 bytes [SKK+97]. may be less, although it typically exceeds 280 bytes [SKK+97].
To protect host memory from being exhausted by connection requests, To protect host memory from being exhausted by connection requests,
the number of TCB structures that can be resident at any time is the number of TCB structures that can be resident at any time is
usually limited by operating system kernels. Systems vary on whether usually limited by operating system kernels. Systems vary on whether
skipping to change at page 6, line 10 skipping to change at page 6, line 9
standards documents, so the failure behavior when the backlog is standards documents, so the failure behavior when the backlog is
reached might differ between stacks (for instance, TCP RSTs might be reached might differ between stacks (for instance, TCP RSTs might be
generated). The exact failure behavior will determine whether generated). The exact failure behavior will determine whether
initiating hosts continue to retransmit SYN segments over time, or initiating hosts continue to retransmit SYN segments over time, or
quickly cease. These differences in implementation are acceptable quickly cease. These differences in implementation are acceptable
since they only affect the behavior of the local stack when its since they only affect the behavior of the local stack when its
resources are constrained, and do not cause interoperability resources are constrained, and do not cause interoperability
problems. problems.
The SYN flooding attack neither attempts to overload the network's The SYN flooding attack neither attempts to overload the network's
resources, nor the end host's memory, but merely to exhaust an resources, nor the end host's memory, but merely to exhaust the
application's backlog of half-open connections. The goal is to send backlog of half-open connections associated with a port number. The
a quick barrage of SYN segments from IP addresses (often spoofed) goal is to send a quick barrage of SYN segments from IP addresses
that will not generate replies to the SYN-ACKs that are produced. By (often spoofed) that will not generate replies to the SYN-ACKs that
keeping the backlog full of bogus half-opened connections, legitimate are produced. By keeping the backlog full of bogus half-opened
requests will be rejected. Three important attack parameters for connections, legitimate requests will be rejected. Three important
success are the size of the barrage, the frequency with which attack parameters for success are the size of the barrage, the
barrages are generated, and the means of selecting IP addresses to frequency with which barrages are generated, and the means of
spoof. selecting IP addresses to spoof.
Barrage Size Barrage Size
To be effective, the size of the barrage must be made large enough To be effective, the size of the barrage must be made large enough
to reach the backlog. Ideally, the barrage size is no larger than to reach the backlog. Ideally, the barrage size is no larger than
the backlog, minimizing the volume of traffic the attacker must the backlog, minimizing the volume of traffic the attacker must
source. Typical default backlog values vary from a half-dozen to source. Typical default backlog values vary from a half-dozen to
several dozen, so the attack might be tailored to the particular several dozen, so the attack might be tailored to the particular
value determined by the victim host and application. On machines value determined by the victim host and application. On machines
intended to be servers, especially for a high volume of traffic, intended to be servers, especially for a high volume of traffic,
skipping to change at page 7, line 37 skipping to change at page 7, line 37
It is important to note that this attack is directed at particular It is important to note that this attack is directed at particular
listening applications on a host, and not the host itself or the listening applications on a host, and not the host itself or the
network. The attack also attempts to prevent only the establishment network. The attack also attempts to prevent only the establishment
of new incoming connections to the victim port, and does not impact of new incoming connections to the victim port, and does not impact
outgoing connection requests, nor previously established connections outgoing connection requests, nor previously established connections
to the victim port. to the victim port.
In practice, an attacker might choose not to use spoofed IP In practice, an attacker might choose not to use spoofed IP
addresses, but instead to use a multitude of hosts to initiate a SYN addresses, but instead to use a multitude of hosts to initiate a SYN
flooding attack. For instance, a "botnet" could be used. In this flooding attack. For instance, a collection of compromised hosts
case, each host utilized in the attack would have to suppress its under the attacker's control (i.e. a "botnet") could be used. In
operating system's native response to the SYN-ACKs coming from the this case, each host utilized in the attack would have to suppress
target. It is also possible for the attack TCP segments to arrive in its operating system's native response to the SYN-ACKs coming from
a more continuous fashion than the "barrage" terminology used here the target. It is also possible for the attack TCP segments to
suggests; as long as the rate of new SYNs exceeds the rate at which arrive in a more continuous fashion than the "barrage" terminology
TCBs are reaped, the attack will be successful. used here suggests; as long as the rate of new SYNs exceeds the rate
at which 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 This section discusses a number of defense techniques which are known
to the community, many of which are available in off-the-shelf to the community, many of which are available in off-the-shelf
products. products.
3.1. Filtering 3.1. Filtering
Since in the absence of an army of controlled hosts, the ability to Since in the absence of an army of controlled hosts, the ability to
skipping to change at page 9, line 4 skipping to change at page 9, line 4
Another quickly implementable defense is shortening the timeout Another quickly implementable defense is shortening the timeout
period between receiving a SYN and reaping the created TCB for lack period between receiving a SYN and reaping the created TCB for lack
of progress. Decreasing the timer that limits the lifetime of TCBs of progress. Decreasing the timer that limits the lifetime of TCBs
in SYN-RECEIVED is also flawed. While a shorter timer will keep in SYN-RECEIVED is also flawed. While a shorter timer will keep
bogus connection attempts from persisting for as long in the backlog, bogus connection attempts from persisting for as long in the backlog,
and thus free up space for legitimate connections sooner, it can and thus free up space for legitimate connections sooner, it can
prevent some fraction of legitimate connections from becoming fully prevent some fraction of legitimate connections from becoming fully
established. This tactic is also ineffective because it only established. This tactic is also ineffective because it only
requires the attacker to increase the barrage frequency by a linearly requires the attacker to increase the barrage frequency by a linearly
proportional amount. proportional amount. This timer reduction is sometimes implemented
as a response to crossing some threshold in the backlog occupancy, or
some rate of SYN reception.
3.4. SYN Cache 3.4. Recycling the Oldest Half-Open TCB
Once the entire backlog is exhausted, some implementations allow
incoming SYNs to overwrite the oldest half-open TCB entry. This
works under the assumption that legitimate connections can be fully
established in less time than the backlog can be filled by incoming
attack SYNs. This can fail when the attacking packet rate is high
and/or the backlog size is small, and is not a robust defense.
3.5. SYN Cache
The SYN cache, best described by Lemon [Lem02], is based on The SYN cache, best described by Lemon [Lem02], is based on
minimizing the amount of state that a SYN allocates, i.e. not minimizing the amount of state that a SYN allocates, i.e. not
immediately allocating a full TCB. The full state allocation is immediately allocating a full TCB. The full state allocation is
delayed until the connection has been fully established. Hosts delayed until the connection has been fully established. Hosts
implementing a SYN cache have some secret bits that they select from implementing a SYN cache have some secret bits that they select from
the incoming SYN segments. The secret bits are hashed along with the the incoming SYN segments. The secret bits are hashed along with the
IP addresses and TCP ports of a segment, and the hash value IP addresses and TCP ports of a segment, and the hash value
determines the location in a global hash table where the incomplete determines the location in a global hash table where the incomplete
TCB is stored. There is a bucket limit for each hash value, and when TCB is stored. There is a bucket limit for each hash value, and when
skipping to change at page 9, line 45 skipping to change at page 10, line 8
[RFC1644]. While T/TCP is implemented in a number of popular [RFC1644]. While T/TCP is implemented in a number of popular
operating systems [GN00], it currently seems to be rarely used. operating systems [GN00], it currently seems to be rarely used.
Measurements at one site's border router [All07] logged 2,545,785 SYN Measurements at one site's border router [All07] logged 2,545,785 SYN
segments (not SYN-ACKs), of which 36 carried the T/TCP CCNEW option segments (not SYN-ACKs), of which 36 carried the T/TCP CCNEW option
(or 0.001%). These came from 26 unique hosts, and no other T/TCP (or 0.001%). These came from 26 unique hosts, and no other T/TCP
options were seen. 2,287 SYN segments with data were seen (or 0.09% options were seen. 2,287 SYN segments with data were seen (or 0.09%
of all SYN segments), all of which had exactly 24 bytes of data. of all SYN segments), all of which had exactly 24 bytes of data.
These observations indicate that issues with SYN caches and data on These observations indicate that issues with SYN caches and data on
SYN segments may not be significant in deployment. SYN segments may not be significant in deployment.
3.5. SYN Cookies 3.6. SYN Cookies
SYN cookies go a step further and allocate no state at all for SYN cookies go a step further and allocate no state at all for
connections in SYN-RECEIVED. Instead, they encode most of the state connections in SYN-RECEIVED. Instead, they encode most of the state
(and all of the strictly required) state that they would normally (and all of the strictly required) state that they would normally
keep into the sequence number transmitted on the SYN-ACK. If the SYN keep into the sequence number transmitted on the SYN-ACK. If the SYN
was not spoofed, then the acknowledgement number (along with several was not spoofed, then the acknowledgement number (along with several
other fields) in the ACK that completes the handshake can be used to other fields) in the ACK that completes the handshake can be used to
reconstruct the state to be put into the TCB. To date, one of the reconstruct the state to be put into the TCB. To date, one of the
best references on SYN cookies can be found on Dan Bernstein's web best references on SYN cookies can be found on Dan Bernstein's web
site [cr.yp.to]. This technique exploits the long-understood low site [cr.yp.to]. This technique exploits the long-understood low
skipping to change at page 10, line 20 skipping to change at page 10, line 31
web page will become unavailable. web page will become unavailable.
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 [RFC1321]. Any similar one-way hash could be used instead
without impacting interoperability since the hash value is checked by
the same host who generates it.
The problem with SYN cookies is that commonly implemented schemes are The problem with SYN cookies is that commonly implemented schemes are
incompatible with some TCP options, if the cookie generation scheme incompatible with some TCP options, if the cookie generation scheme
does not consider them. For example, an encoding of the MSS does not consider them. For example, an encoding of the MSS
advertised on the SYN has been accommodated by using 2 sequence advertised on the SYN has been accommodated by using 2 sequence
number bits to represent 4 predefined common MSS values. Similar number bits to represent 4 predefined common MSS values. Similar
techniques would be required for some other TCP options, while techniques would be required for some other TCP options, while
negotiated use of other TCP options can be detected implicitly. A negotiated use of other TCP options can be detected implicitly. A
timestamp on the ACK, as an example, indicates that Timestamp use was timestamp on the ACK, as an example, indicates that Timestamp use was
successfully negotiated on the SYN and SYN-ACK, while the reception successfully negotiated on the SYN and SYN-ACK, while the reception
skipping to change at page 11, line 23 skipping to change at page 11, line 36
handling a large number of connections, then packet loss may be handling a large number of connections, then packet loss may be
likely. When a handshake-completing ACK from the initiator is lost, likely. When a handshake-completing ACK from the initiator is lost,
the passive side's application-layer never is notified of the the passive side's application-layer never is notified of the
connection's existence and never sends data, even though the connection's existence and never sends data, even though the
initiator thinks that the connection has been successfully initiator thinks that the connection has been successfully
established. An example application where the first application- established. An example application where the first application-
layer data is sent by the passive side is SMTP, if implemented 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 according to RFC 2821, where a "service ready" message is sent by the
passive side after the TCP handshake is completed. passive side after the TCP handshake is completed.
3.6. Hybrid Approaches Although SYN cookie implementations exist and are deployed, the use
of SYN cookies is often disabled in default configurations, so it is
unclear how much operational experience actually exists with them, or
if using them opens up new vulnerabilities. Anecdotes of incidents
where SYN cookies have been used on typical web servers seem to
indicate that the added processing burden of computing MD5 sums for
every SYN packet received is not significant in comparison to the
loss of application availability when undefended. For some
computationally-constrained mobile or embedded devices, this
situation might be different.
3.7. 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 [Lem02]. utility of this hybrid [Lem02].
3.7. Firewalls and Proxies 3.8. Firewalls and Proxies
Firewall-based tactics may also be used to defend end-hosts from SYN Firewall-based tactics may also be used to defend end-hosts from SYN
flooding attacks. The basic concept is to offload the connection flooding attacks. The basic concept is to offload the connection
establishment procedures onto a firewall that screens connection establishment procedures onto a firewall that screens connection
attempts until they are completed and then proxies them back to attempts until they are completed and then proxies them back to
protected end hosts. This moves the problem away from end-hosts to protected end hosts. This moves the problem away from end-hosts to
become the firewall's or proxy's problem, and may introduce other become the firewall's or proxy's problem, and may introduce other
problems related to altering TCP's expected end-to-end semantics. problems related to altering TCP's expected end-to-end semantics. A
common tactic used in these firewall and proxy products is to
implement one of the end-host based techniques discussed above, and
screen incoming SYNs from the protected network until the connection
is fully established. This is accomplished by spoofing the source
addresses of several packets to the initiator and listener at various
stages of the handshake [Eddy06].
4. Analysis 4. Analysis
Several of the defenses discussed in the previous section rely on Several of the defenses discussed in the previous section rely on
changes to behavior inside the network; via router filtering, changes to behavior inside the network; via router filtering,
firewalls, and proxies. These may be highly effective, and often firewalls, and proxies. These may be highly effective, and often
require no modification or configuration of end host software. Given require no modification or configuration of end host software. Given
the mobile nature and dynamic connectivity of many end hosts, it is the mobile nature and dynamic connectivity of many end hosts, it is
optimistic for TCP implementers to assume the presence of such optimistic for TCP implementers to assume the presence of such
protective devices. TCP implementers should provide some means of protective devices. TCP implementers should provide some means of
skipping to change at page 13, line 5 skipping to change at page 14, line 5
FreeBSD 4.4 [Lem02]. Lemon notes that a SYN cache structure took up FreeBSD 4.4 [Lem02]. Lemon notes that a SYN cache structure took up
160 bytes compared to 736 for the full TCB (now 196 bytes for the 160 bytes compared to 736 for the full TCB (now 196 bytes for the
cache structure). We have examined the OpenBSD 3.6 code and cache structure). We have examined the OpenBSD 3.6 code and
determined that it includes a similar SYN cache. determined that it includes a similar SYN cache.
Linux 2.6.5 code, also by examination, contains a SYN cookie Linux 2.6.5 code, also by examination, contains a SYN cookie
implementation that encodes 8 MSS values, and does not use SYN implementation that encodes 8 MSS values, and does not use SYN
cookies by default. This functionality has been present in the Linux cookies by default. This functionality has been present in the Linux
kernel for several years previous to 2.6.5. kernel for several years previous to 2.6.5.
When a SYN cache and/or SYN cookies are implemented with IPv6, the
IPv6 flow label value used on the SYN-ACK should be consistent with
the flow label used for the rest of the packets within that flow.
There have been implementation bugs that caused random flow labels to
be used in SYN-ACKs generated by SYN cache and SYN cookie code
[MM05].
Beginning with Windows 2000, Microsoft's Windows operating systems Beginning with Windows 2000, Microsoft's Windows operating systems
have had a "TCP SYN attack protection" feature which can be toggled have had a "TCP SYN attack protection" feature which can be toggled
on or off in the registry. This defaulted to off, until Windows 2003 on or off in the registry. This defaulted to off, until Windows 2003
SP1, in which it is on by default. With this feature enabled, when SP1, in which it is on by default. With this feature enabled, when
the number of half-open connections and half-open connections with the number of half-open connections and half-open connections with
retransmitted SYN-ACKs exceeds configurable thresholds, then the retransmitted SYN-ACKs exceeds configurable thresholds, then the
number of times which SYN-ACKs are retransmitted before giving up is number of times which SYN-ACKs are retransmitted before giving up is
reduced, and the "Route Cache Entry" creation is delayed, which reduced, and the "Route Cache Entry" creation is delayed, which
prevents some features (e.g. window scaling) from being used prevents some features (e.g. window scaling) from being used
[win2k3-wp]. [win2k3-wp].
skipping to change at page 16, line 10 skipping to change at page 17, line 10
6. IANA Considerations 6. IANA Considerations
This document does not update or create any IANA registries. This document does not update or create any IANA registries.
7. Acknowledgements 7. 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, Caitlin Fernando Gont, Jean-Baptiste Marchand, Christian Huitema, Caitlin
Bestler, Pekka Savola, Andre Oppermann, Alfred Hoenes, and Mark Bestler, Pekka Savola, Andre Oppermann, Alfred Hoenes, Mark Allman,
Allman were useful in strengthening this document. The original work Pasi Eronen, Warren Kumari, David Malone, and Ron Bonica were useful
on TCP SYN cookies presented in Appendix A is due to D.J. Bernstein. in strengthening this document. The original work on TCP SYN cookies
presented in Appendix A is due to D.J. Bernstein.
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, NASA's Space Technologies (ACAST) project, the Sensis Corporation, NASA's Space
Communications Architecture Working Group, and NASA's Earth Science Communications Architecture Working Group, and NASA's Earth Science
Technology Office. Technology Office.
8. Informative References 8. 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.
[All07] Allman, M., "", personal communication , February 2007. [All07] Allman, M., "personal communication", February 2007.
[B96] Bennahum, D., "PANIX ATTACK", MEME 2.12 [B96] Bennahum, D., "PANIX ATTACK", MEME 2.12
(http://memex.org/meme2-12.html), October 1996. (http://memex.org/meme2-12.html), October 1996.
[B97] Borman, D., "Re: SYN/RST cookies (was Re: a quick [B97] Borman, D., "Re: SYN/RST cookies (was Re: a quick
clarification...)", IETF tcp-impl mailing list, June 1997. clarification...)", IETF tcp-impl mailing list, June 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.
[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.
[Eddy06] Eddy, W., "Defenses Against TCP SYN Flooding Attacks",
Cisco Internet Protocol Journal Volume 8, Number 4,
December 2006.
[GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for Transactions", [GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for Transactions",
Linux Journal, February 2000. Linux Journal, February 2000.
[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.
[MM05] McGann, O. and D. Malone, "Flow Label Filtering
Feasibility", European Conference on Computer Network
Defense 2005, December 2005.
[MNJH07] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [MNJH07] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", (draft-ietf-hip-base-07), "Host Identity Protocol", (draft-ietf-hip-base-07),
February 2007. February 2007.
[P48-13] daemon9, route, and infinity, "Project Neptune", Phrack [P48-13] daemon9, route, and infinity, "Project Neptune", Phrack
Magazine, Volume 7, 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.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994. Functional Specification", RFC 1644, July 1994.
[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.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
 End of changes. 22 change blocks. 
61 lines changed or deleted 111 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/