draft-ietf-tcpm-syn-flood-02.txt   draft-ietf-tcpm-syn-flood-03.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 February 2007 Intended status: Informational April 18, 2007
Expires: August 5, 2007 Expires: October 20, 2007
TCP SYN Flooding Attacks and Common Mitigations TCP SYN Flooding Attacks and Common Mitigations
draft-ietf-tcpm-syn-flood-02 draft-ietf-tcpm-syn-flood-03
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 August 5, 2007. This Internet-Draft will expire on October 20, 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,
are described. This document archives explanations of the attack and are described. This document archives explanations of the attack and
common defense techniques for the benefit of TCP implementers and common defense techniques for the benefit of TCP implementers and
administrators of TCP servers or networks. administrators of TCP servers or networks, but does not make any
standards-level recommendations.
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
skipping to change at page 4, line 39 skipping to change at page 4, line 39
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
operating systems, although some significantly diverge from the TCP operating systems, although some significantly diverge from the TCP
specification and have not yet been standardized or sanctioned by the specification and none of these techniques have yet been standardized
IETF process. or sanctioned by the IETF process.
2.2. Theory of Operation 2.2. Theory of Operation
As described in RFC 793, a TCP implementation may allow the LISTEN As described in RFC 793, a TCP implementation may allow the LISTEN
state to be entered with either all, some, or none of the pair of IP state to be entered with either all, some, or none of the pair of IP
addresses and port numbers specified by the application. In many addresses and port numbers specified by the application. In many
common applications like web servers, none of the remote host's common applications like web servers, none of the remote host's
information is pre-known or preconfigured, so that a connection can information is pre-known or preconfigured, so that a connection can
be established with any client whose details are unknown to the be established with any client whose details are unknown to the
server ahead of time. This type of "unbound" LISTEN is the target of server ahead of time. This type of "unbound" LISTEN is the target of
skipping to change at page 6, line 12 skipping to change at page 6, line 12
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 an
application's backlog of half-open connections. The goal is to send application's backlog of half-open connections. The goal is to send
a quick barrage of SYN segments from spoofed IP addresses that will a quick barrage of SYN segments from IP addresses (often spoofed)
not generate replies to the SYN-ACKs that are produced. By keeping that will not generate replies to the SYN-ACKs that are produced. By
the backlog full of bogus half-opened connections, legitimate keeping the backlog full of bogus half-opened connections, legitimate
requests will be rejected. Three important attack parameters for requests will be rejected. Three important attack parameters for
success are the size of the barrage, the frequency with which success are the size of the barrage, the frequency with which
barrages are generated, and the means of selecting IP addresses to barrages are generated, and the means of selecting IP addresses to
spoof. 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
skipping to change at page 7, line 30 skipping to change at page 7, line 30
will immediately free the corresponding TCB and allow room in the will immediately free the corresponding TCB and allow room in the
backlog for legitimate connections to be made. The code backlog for legitimate connections to be made. The code
distributed in the original Phrack article used a single source distributed in the original Phrack article used a single source
address for all spoofed SYN segments. This makes the attack address for all spoofed SYN segments. This makes the attack
segments somewhat easier to identify and filter. A strong segments somewhat easier to identify and filter. A strong
attacker will have a list of unresponsive and unrelated addresses attacker will have a list of unresponsive and unrelated addresses
that it chooses spoofed source addresses from. that it chooses spoofed source addresses from.
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 attepts 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 "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 suppress 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 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
skipping to change at page 8, line 28 skipping to change at page 8, line 28
represent the best current practices for packet filtering based on IP represent the best current practices for packet filtering based on IP
addresses [RFC2827][RFC3013][RFC3704]. While perfectly effective, addresses [RFC2827][RFC3013][RFC3704]. While perfectly effective,
end hosts should not rely on filtering policies to prevent attacks end hosts should not rely on filtering policies to prevent attacks
from spoofed segments, as global deployment of filters is neither from spoofed segments, as global deployment of filters is neither
guaranteed nor likely. An attacker with the ability to use a group guaranteed nor likely. An attacker with the ability to use a group
of compromised hosts or to rapidly change between different access of compromised hosts or to rapidly change between different access
providers will also make filtering an impotent solution. providers 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 a 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
that limit their performance with large backlogs, and there seems to that limit their performance with large backlogs, and there seems to
be no compelling reason why stacks should be re-engineered to support be no compelling reason why stacks should be re-engineered to support
extremely large backlogs, since other solutions are available. extremely large backlogs, since other solutions are available.
However, experiments with large backlogs using efficient data However, experiments with large backlogs using efficient data
skipping to change at page 9, line 37 skipping to change at page 9, line 37
distribution of times to establish legitimate connections to about distribution of times to establish legitimate connections to about
15% longer than when not under attack [Lem02]. 15% longer than when not under attack [Lem02].
If data accompanies the SYN segment, then this data is not If data accompanies the SYN segment, then this data is not
acknowledged or stored by the receiver, and will require acknowledged or stored by the receiver, and will require
retransmission. This does not affect the reliability of TCP's data retransmission. This does not affect the reliability of TCP's data
transfer service, but it does affect its performance to some small transfer service, but it does affect its performance to some small
extent. SYNs carrying data are used by the T/TCP extensions extent. SYNs carrying data are used by the T/TCP extensions
[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.
Measurments 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.5. 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
skipping to change at page 10, line 38 skipping to change at page 10, line 38
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
of a SACK option at some point during the connection implies that of a SACK option at some point during the connection implies that
SACK was negotiated. Note that SACK blocks should normally not be SACK was negotiated. Note that SACK blocks should normally not be
sent by a host using TCP cookies unless they are first received. For sent by a host using TCP cookies unless they are first received. For
the common unidirectional data flow in many TCP connections, this can the common unidirectional data flow in many TCP connections, this can
be a 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 are not used by default on systems that implement them, and typically are not used by default on systems that implement them, and
are only enabled either under high-stress conditions indicative of an are only enabled either under high-stress conditions indicative of an
attack, or via adminstrative action. attack, or via administrative action.
Recently, a new SYN cookie technique developed for release in FreeBSD Recently, a new SYN cookie technique developed for release in FreeBSD
7.0 leverages the bits of the Timestamp option in addition to the 7.0 leverages the bits of the Timestamp option in addition to the
sequence number bits for encoding state. Since the Timestamp value sequence number bits for encoding state. Since the Timestamp value
is echoed back in the Timestamp Echo field of the ACK packet, any 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 state stored in the Timestamp option can be restored similarly to the
way that it is from the sequence number / acknowledgedment in a basic way that it is from the sequence number / acknowledgement in a basic
SYN cookie. Using the Timestamp bits, it is possible to explicitly SYN cookie. Using the Timestamp bits, it is possible to explicitly
store state bits for things like send and receive window scales, 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 SACK-allowed, and TCP-MD5-enabled, that there is no room for in a
typical SYN cookie. This use of Timestamps to improve the typical SYN cookie. This use of Timestamps to improve the
compromises inherrent in SYN cookies is unique to the FreeBSD compromises inherent in SYN cookies is unique to the FreeBSD
implementation, to our knowledge. A limitation is that the technique implementation, to our knowledge. A limitation is that the technique
can only be used if the SYN itself contains a Timestamp option, but can only be used if the SYN itself contains a Timestamp option, but
this option seems to be widely implemented today, and hosts that this option seems to be widely implemented today, and hosts that
support window scaling and SACK typically support timestamps as well. 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 Another problem with SYN cookies is for applications where the first
application data is sent by the passive host. If this host is application data is sent by the passive host. If this host is
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 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 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
skipping to change at page 19, line 16 skipping to change at page 19, line 16
This information is taken from Bernstein's web page on SYN cookies This information is taken from Bernstein's web page on SYN cookies
[cr.yp.to]. This is a rewriting of the technical information on that [cr.yp.to]. This is a rewriting of the technical information on that
web page and not a full replacement. There are other slightly web page and not a full replacement. There are other slightly
different ways of implementing the SYN cookie concept than the exact different ways of implementing the SYN cookie concept than the exact
means described here, although the basic idea of encoding data into means described here, although the basic idea of encoding data into
the SYN-ACK sequence number is constant. the SYN-ACK 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
number, MSS, a time counter, and the relevent addresses and port number, MSS, a time counter, and the relevant addresses and port
numbers. The actual bits comprising the SYN cookie are chosen to be numbers. The actual bits comprising the SYN cookie are chosen to be
the bitwise difference (exclusive-or) between the SYN's sequence the bitwise difference (exclusive-or) between the SYN's sequence
number and a 32 bit quantity computed so that the top five bits come number and a 32 bit quantity computed so that the top five bits come
from a 32-bit counter value modulo 32, where the counter increases from a 32-bit counter value modulo 32, where the counter increases
every 64 seconds, the next 3 bits encode a usable MSS near to the one every 64 seconds, the next 3 bits encode a usable MSS near to the one
in the SYN, and the bottom 24 bits are a server-selected secret in the SYN, and the bottom 24 bits are a server-selected secret
function of pair of IP addresses, the pair of port numbers, and the function of pair of IP addresses, the pair of port numbers, and the
32-bit counter used for the first 5 bits. This means of selecting an 32-bit counter used for the first 5 bits. This means of selecting an
initial sequence number for use in the SYN-ACK complies with the rule initial sequence number for use in the SYN-ACK complies with the rule
that TCP sequence numbers increase slowly. that TCP sequence numbers increase slowly.
 End of changes. 15 change blocks. 
19 lines changed or deleted 20 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/