draft-ietf-tcpm-syn-flood-01.txt   draft-ietf-tcpm-syn-flood-02.txt 
Network Working Group W. Eddy Network Working Group W. Eddy
Internet-Draft Verizon Federal Network Systems Internet-Draft Verizon Federal Network Systems
Expires: June 11, 2007 December 8, 2006 Intended status: Informational February 2007
Expires: August 5, 2007
TCP SYN Flooding Attacks and Common Mitigations TCP SYN Flooding Attacks and Common Mitigations
draft-ietf-tcpm-syn-flood-01 draft-ietf-tcpm-syn-flood-02
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 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 June 11, 2007. This Internet-Draft will expire on August 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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.
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. SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 9
3.6 Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 11 3.6. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 11
3.7 Firewalls and Proxies . . . . . . . . . . . . . . . . . . 11 3.7. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 11
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Informative References . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 8. Informative References . . . . . . . . . . . . . . . . . . . . 17
A. SYN Cookies Description . . . . . . . . . . . . . . . . . . . 17 Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
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 only attack, and the widely available countermeasures, the RFC series only
documented the vulnerability as an example motivation for ingress documented the vulnerability as an example motivation for ingress
filtering [RFC2827], and has not suggested any mitigation techniques filtering [RFC2827], and has not suggested any mitigation techniques
for TCP implementations. The purpose of this document is to satisfy for TCP implementations. This document addresses both points, but
both of these ends in an informational context. The advancement of does not define any standards. Formal specifications and
(or need to advance) mitigation techniques through the standards requirements of defense mechanisms are outside the scope of this
track is left to be considered as further work for the IETF, and document. Many defenses only impact an end-host's implementation
formal specifications and requirements of defense mechanisms are without changing interoperability. These may not require
outside the scope of this document. standardization, but their side-effects should at least be well
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. Often, high packet-rate attacks
that target the network's packet processing capability and capacity that target the network's packet processing capability and capacity
have been observed operationally. Since such attacks target the have been observed operationally. Since such attacks target the
network, and not a TCP implementation, they are out of scope for this 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 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.
This 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.
2. Attack Description 2. Attack Description
This section describes both the history and the technical basis of This section describes both the history and the technical basis of
the SYN flooding attack. the SYN flooding attack.
2.1 History 2.1. History
The TCP SYN flooding weakness was discovered as early as 1994 by Bill The TCP SYN flooding weakness was discovered as early as 1994 by Bill
Cheswick and Steve Bellovin. They included, and then removed, a Cheswick and Steve Bellovin [B96]. They included, and then removed,
paragraph on the attack in their book "Firewalls and Internet a paragraph on the attack in their book "Firewalls and Internet
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. This article contains code for the high enough quality to be useful, and code from the article was
attack and was widely distributed via the Internet. 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 the Panix ISP's mail servers
caused well-publicized outages. CERT quickly released an advisory on caused well-publicized outages. CERT quickly released an advisory on
the attack [CA-96.21]. SYN flooding was particularly serious in the 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
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 have not yet been standardized or sanctioned by the
IETF process. 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
SYN flooding attacks, due to the way it is typically implemented by SYN flooding attacks due to the way it is typically implemented by
operating systems. operating systems.
For success, the SYN flooding attack relies on the victim host TCP For success, the SYN flooding attack relies on the victim host TCP
implementation's behavior. In particular, it assumes that the victim implementation's behavior. In particular, it assumes that the victim
allocates state for every TCP SYN segment when it is received, and allocates state for every TCP SYN segment when it is received, and
that there is a limit on the amount of such state than can be kept at that there is a limit on the amount of such state than can be kept at
any time. The current base TCP specification, RFC 793 [RFC0793], any time. The current base TCP specification, RFC 793 [RFC0793],
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
skipping to change at page 5, line 36 skipping to change at page 5, line 36
influences the way in which applications that wish to handle multiple influences the way in which applications that wish to handle multiple
simultaneous connections through a single TCP port are written. The simultaneous connections through a single TCP port are written. The
crucial result of this behavior is that instead of updating already- crucial result of this behavior is that instead of updating already-
allocated memory, new (or unused) memory must be devoted to the allocated memory, new (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 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
limits are globally applied or local to a particular port number. limits are globally applied or local to a particular port number.
There is also variation on whether the limits apply to fully- There is also variation on whether the limits apply to fully-
established connections as well as those in SYN-RECEIVED. Commonly, established connections as well as those in SYN-RECEIVED. Commonly,
systems implement a parameter to the typical listen() system call systems implement a parameter to the typical listen() system call
that allows the application to suggest a value for this limit, called that allows the application to suggest a value for this limit, called
the backlog. When the backlog limit is reached, then either incoming the backlog. When the backlog limit is reached, then either incoming
SYN segments are ignored, or uncompleted connections in the backlog SYN segments are ignored, or uncompleted connections in the backlog
are replaced. The concept of using a backlog is not described in the are replaced. The concept of using a backlog is not described in the
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. quickly cease. These differences in implementation are acceptable
since they only affect the behavior of the local stack when its
resources are constrained, and do not cause interoperability
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 spoofed IP addresses that will
not generate replies to the SYN-ACKs that are produced. By keeping not generate replies to the SYN-ACKs that are produced. By keeping
the backlog full of bogus half-opened connections, legitimate 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
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. value determined by the victim host and application. On machines
intended to be servers, especially for a high volume of traffic,
the backlogs are often administratively configured to higher
values.
Barrage Frequency Barrage Frequency
To limit the lifetime of half-opened connection state, TCP To limit the lifetime of half-opened connection state, TCP
implementations commonly reclaim memory from half-opened implementations commonly reclaim memory from half-opened
connections if they do not become fully-opened after some time connections if they do not become fully-opened after some time
period. For instance, a timer of 75 seconds [SKK+97] might be set period. For instance, a timer of 75 seconds [SKK+97] might be set
when the first SYN-ACK is sent, and on expiration cause SYN-ACK when the first SYN-ACK is sent, and on expiration cause SYN-ACK
retransmissions to cease and the TCB to be released. The TCP retransmissions to cease and the TCB to be released. The TCP
specifications do not include this behavior of giving up on specifications do not include this behavior of giving up on
connection establishment after an arbitrary time. Some purists connection establishment after an arbitrary time. Some purists
have expressed that the TCP implementation should continue have expressed that the TCP implementation should continue
retransmitting SYN and SYN-ACK segments without artificial bounds retransmitting SYN and SYN-ACK segments without artificial bounds
(but with exponential backoff to some conservative rate) until the (but with exponential backoff to some conservative rate) until the
application gives up. Despite this, common operating systems application gives up. Despite this, common operating systems
today do implement some artificial limit on half-open TCB today do implement some artificial limit on half-open TCB
lifetime. For instance, backing off and stopping after a total of lifetime. For instance, backing off and stopping after a total of
511 seconds can be observed in 4.4 BSD-Lite [Ste95]. 511 seconds can be observed in 4.4 BSD-Lite [Ste95], and is still
practiced in some operating systems derived from this code.
To remain effective, a SYN flooding attack needs to send new To remain effective, a SYN flooding attack needs to send new
barrages of bogus connection requests as soon as the TCBs from the barrages of bogus connection requests as soon as the TCBs from the
previous barrage begin to be reclaimed. The frequency of barrages previous barrage begin to be reclaimed. The frequency of barrages
are tailored to the victim TCP implementation's TCB reclamation are tailored to the victim TCP implementation's TCB reclamation
timer. Frequencies higher than needed source more packets, timer. Frequencies higher than needed source more packets,
potentially drawing more attention, and frequencies that are too potentially drawing more attention, and frequencies that are too
low will allow windows of time where legitimate connections can be low will allow windows of time where legitimate connections can be
established. established.
skipping to change at page 7, line 21 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 prevents only the establishment of new network. The attack also attepts to prevent only the establishment
incoming connections to the victim port, and does not impact outgoing of new incoming connections to the victim port, and does not impact
connection requests, nor previously established connections to the outgoing connection requests, nor previously established connections
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 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 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
send packets with spoofed source IP addresses is required for this send packets with spoofed source IP addresses is required for this
attack to work, removing an attacker's ability to send spoofed IP attack to work, removing an attacker's ability to send spoofed IP
packets is an effective solution that requires no modifications to packets is an effective solution that requires no modifications to
TCP. The filtering techniques described in RFCs 2827, 3013, and 3704 TCP. The filtering techniques described in RFCs 2827, 3013, and 3704
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 move around in the network will also make of compromised hosts or to rapidly change between different access
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 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
structures and search algorithms have not been conducted, to our structures and search algorithms have not been conducted, to our
knowledge. knowledge.
3.3 Reducing SYN-RECEIVED Timer 3.3. Reducing SYN-RECEIVED Timer
Decreasing the timer that limits the lifetime of TCBs in SYN-RECEIVED Another quickly implementable defense is shortening the timeout
is also flawed. While a shorter timer will keep bogus connection period between receiving a SYN and reaping the created TCB for lack
attempts from persisting for as long in the backlog, and thus free up of progress. Decreasing the timer that limits the lifetime of TCBs
space for legitimate connections sooner, it can prevent some fraction in SYN-RECEIVED is also flawed. While a shorter timer will keep
of legitimate connections from becoming fully established. This bogus connection attempts from persisting for as long in the backlog,
tactic is also ineffective because it only requires the attacker to and thus free up space for legitimate connections sooner, it can
increase the barrage frequency by a linearly proportional amount. prevent some fraction of legitimate connections from becoming fully
established. This tactic is also ineffective because it only
requires the attacker to increase the barrage frequency by a linearly
proportional amount.
3.4 SYN Cache 3.4. 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 27 skipping to change at page 9, line 28
The SYN cache technique is effective because the secret bits prevent The SYN cache technique is effective because the secret bits prevent
an attacker from being able to target specific hash values for an attacker from being able to target specific hash values for
overflowing the bucket limit, and it bounds both the CPU time and overflowing the bucket limit, and it bounds both the CPU time and
memory requirements. Lemon's evaluation of the SYN cache shows that memory requirements. Lemon's evaluation of the SYN cache shows that
even under conditions where a SYN flooding attack is not being even under conditions where a SYN flooding attack is not being
performed, due to the modified processing path, connection performed, due to the modified processing path, connection
establishment is slightly more expedient. Under active attack, SYN establishment is slightly more expedient. Under active attack, SYN
cache performance was observed to approximately linearly shift the cache performance was observed to approximately linearly shift the
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. 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. extent. SYNs carrying data are used by the T/TCP extensions
[RFC1644]. While T/TCP is implemented in a number of popular
operating systems [GN00], it currently seems to be rarely used.
Measurments 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
(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%
of all SYN segments), all of which had exactly 24 bytes of data.
These observations indicate that issues with SYN caches and data on
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
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 25 skipping to change at page 10, line 36
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
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 default to off on systems that implement them, and are only typically are not used by default on systems that implement them, and
enabled either under high-stress conditions indicative of an attack, are only enabled either under high-stress conditions indicative of an
or via adminstrative action. attack, or via adminstrative 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 / acknowledgedment 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
skipping to change at page 11, line 12 skipping to change at page 11, line 23
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 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
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 [Lem02].
3.7 Firewalls and Proxies 3.7. Firewalls and Proxies
Firewall-baed 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 proceedures 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.
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
defense to SYN flooding attacks in end host implementations. defense to SYN flooding attacks in end host implementations.
Among end host modifications, the SYN cache and SYN cookie approaches Among end host modifications, the SYN cache and SYN cookie approaches
seem to be the only viable techniques discoverd. Increasing the seem to be the only viable techniques discovered to date. Increasing
backlog and reducing the SYN-RECEIVED timer are measurably the backlog and reducing the SYN-RECEIVED timer are measurably
problematic. The SYN cache implies a higher memory footprint than problematic. The SYN cache implies a higher memory footprint than
SYN cookies, however, SYN cookies may not be fully compatible with SYN cookies, however, SYN cookies may not be fully compatible with
some TCP options, and may hamper development of future TCP extensions some TCP options, and may hamper development of future TCP extensions
that require state. For these reasons, SYN cookies should not be that require state. For these reasons, SYN cookies should not be
enabled by default on systems that provide them. SYN caches do not enabled by default on systems that provide them. SYN caches do not
have the same negative implications and may be enabled as a default have the same negative implications and may be enabled as a default
mode of processing. mode of processing.
In October of 1996, Dave Borman implemented a SYN cache at BSDi for In October of 1996, Dave Borman implemented a SYN cache at BSDi for
BSD/OS, which was given to the community with no restrictions. This BSD/OS, which was given to the community with no restrictions. This
code seems to be the basis for the SYN cache implementations adopted code seems to be the basis for the SYN cache implementations adopted
later in other BSD variants. The cache was used when the backlog later in other BSD variants. The cache was used when the backlog
became full, rather than by default, as we have described. A note to became full, rather than by default, as we have described. A note to
the tcp-impl mailing list explains that this code does not retransmit the tcp-impl mailing list explains that this code does not retransmit
SYN-ACKs, which is a practice we would not encourage. SYN-ACKs, which is a practice we discourage [B97].
In 1997, NetBSD incorporated a modified version of Borman's code. In 1997, NetBSD incorporated a modified version of Borman's code.
Two notable differences from the original code stem from the decision Two notable differences from the original code stem from the decision
to use of the cache by default (for all connections). This implied to use the cache by default (for all connections). This implied the
the need to perform retransmissions for SYN-ACKs, and to use larger need to perform retransmissions for SYN-ACKs, and to use larger
structures to keep more complete data. The original structure was 32 structures to keep more complete data. The original structure was 32
bytes long for IPv4 connections and 56 bytes with IPv6 support, while bytes long for IPv4 connections and 56 bytes with IPv6 support, while
the current FreeBSD structure is 196 bytes long. As previously the current FreeBSD structure is 196 bytes long. As previously
cited, Lemon implemented the SYN cache and cookie techniques in cited, Lemon implemented the SYN cache and cookie techniques in
FreeBSD 4.4. Lemon notes that a SYN cache structure took up 160 FreeBSD 4.4 [Lem02]. Lemon notes that a SYN cache structure took up
bytes compared to 736 for the full TCB (now 196 bytes for the cache 160 bytes compared to 736 for the full TCB (now 196 bytes for the
structure). We have examined the OpenBSD 3.6 code and determined cache structure). We have examined the OpenBSD 3.6 code and
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.
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].
Several vendors of commercial firewall products sell devices that can Several vendors of commercial firewall products sell devices that can
mitigate SYN flooding's effects on end hosts by proxying connections. mitigate SYN flooding's effects on end hosts by proxying connections.
Discovery and exploitation of the SYN flooding vulnerability in TCP's Discovery and exploitation of the SYN flooding vulnerability in TCP's
design provided a valuable lesson for protocol designers. The Stream design provided a valuable lesson for protocol designers. The Stream
Control Transmission Protocol [RFC2960], which was designed more Control Transmission Protocol [RFC2960], which was designed more
recently, incorporated a 4-way handshake with a stateless cookie- recently, incorporated a 4-way handshake with a stateless cookie-
based component for the listening end. In this way, the passive- based component for the listening end. In this way, the passive-
opening side has better evidence that the initiator really exists at opening side has better evidence that the initiator really exists at
the given address before it allocates any state. The Host Identity the given address before it allocates any state. The Host Identity
Protocol base exchange [MNJH04] is similarly designed as a 4-way Protocol base exchange [MNJH07] is similarly designed as a 4-way
handshake, but also involves a puzzle sent to the initiator which handshake, but also involves a puzzle sent to the initiator which
must be solved before any state is reserved by the responder. The must be solved before any state is reserved by the responder. The
general concept of designing statelessness into protocol setup to general concept of designing statelessness into protocol setup to
avoid denial of service attacks has been discussed by Aura and avoid denial of service attacks has been discussed by Aura and
Nikander [AN97]. Nikander [AN97].
5. Security Considerations 5. Security Considerations
The SYN flooding attack on TCP has been described in numerous other The SYN flooding attack on TCP has been described in numerous other
publications, and the details and code needed to perform the attack publications, and the details and code needed to perform the attack
skipping to change at page 15, line 5 skipping to change at page 15, line 5
weakness in unmodified TCP stacks. Several widely-deployed operating weakness in unmodified TCP stacks. Several widely-deployed operating
systems implement the mitigation techniques that this document systems implement the mitigation techniques that this document
discusses for defeating SYN flooding attacks. In at least some discusses for defeating SYN flooding attacks. In at least some
cases, these operating systems do not enable these countermeasures by cases, these operating systems do not enable these countermeasures by
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. IANA Considerations
This document does not update or create any IANA registries.
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, and Andre Oppermann were useful in Bestler, Pekka Savola, Andre Oppermann, Alfred Hoenes, and Mark
strengthening this document. Allman were useful 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.
7. 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.
[B96] Bennahum, D., "PANIX ATTACK", MEME 2.12
(http://memex.org/meme2-12.html), October 1996.
[B97] Borman, D., "Re: SYN/RST cookies (was Re: a quick
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.
[GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for Transactions",
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.
[MNJH04] 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-03), "Host Identity Protocol", (draft-ietf-hip-base-07),
June 2005. 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.
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions
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
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3013] Killalea, T., "Recommended Internet Service Provider [RFC3013] Killalea, T., "Recommended Internet Service Provider
skipping to change at page 16, line 36 skipping to change at page 19, line 5
The Implementation", January 1995. The Implementation", January 1995.
[cr.yp.to] [cr.yp.to]
Bernstein, D., "URL: http://cr.yp.to/syncookies.html", Bernstein, D., "URL: http://cr.yp.to/syncookies.html",
visited in December 2005. visited in December 2005.
[win2k3-wp] [win2k3-wp]
Microsoft Corporation, "Microsoft Windows Server 2003 Microsoft Corporation, "Microsoft Windows Server 2003
TCP/IP Implementation Details", White Paper, July 2005. TCP/IP Implementation Details", White Paper, July 2005.
Author's Address
Wesley M. Eddy
Verizon Federal Network Systems
NASA Glenn Research Center
21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135
Phone: 216-433-6682
Email: weddy@grc.nasa.gov
Appendix A. SYN Cookies Description 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 [cr.yp.to]. This is a rewriting of the technical information on that
not a full replacement. There are other slightly different ways of web page and not a full replacement. There are other slightly
implementing the SYN cookie concept than the exact means described different ways of implementing the SYN cookie concept than the exact
here, although the basic idea of encoding data into the SYN-ACK means described here, although the basic idea of encoding data into
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 relevent 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
skipping to change at page 17, line 41 skipping to change at page 19, line 41
between the acknowledged sequence number and the sequence number of between the acknowledged sequence number and the sequence number of
the ACK segment can be checked against recent values of the counter the ACK segment can be checked against recent values of the counter
and the secret function's output given those counter values and the and the secret function's output given those counter values and the
IP addresses and port numbers in the ACK segment. If there is a IP addresses and port numbers in the ACK segment. If there is a
match, the connection can be accepted, since it is statistically very match, the connection can be accepted, since it is statistically very
likely that the other side received the SYN cookie and did not simply likely that the other side received the SYN cookie and did not simply
guess a valid cookie value. If there is not a match, the connection guess a valid cookie value. If there is not a match, the connection
can be rejected under the heuristic that it is probably not in can be rejected under the heuristic that it is probably not in
response to a recently sent SYN-ACK. response to a recently sent SYN-ACK.
With SYN cookies enabled, a host will be able to maintain responsive With SYN cookies enabled, a host will be able to remain responsive
even when under a SYN flooding attack. The largest price to be paid even when under a SYN flooding attack. The largest price to be paid
for using SYN cookies is in the disabling of the window scaling for using SYN cookies is in the disabling of the window scaling
option, which disables high performance. option, which disables high performance.
Bernstein's web page contains more information about the initial Bernstein's web page [cr.yp.to] contains more information about the
conceptualization and implementation of SYN cookies, and archives of initial conceptualization and implementation of SYN cookies, and
emails documenting this history. It also lists some false negative archives of emails documenting this history. It also lists some
claims that have been made about SYN cookies, and discusses reducing false negative claims that have been made about SYN cookies, and
the vulnerability of SYN cookie implementations to blind connection discusses reducing the vulnerability of SYN cookie implementations to
forgery by an attacker guessing valid cookies. blind connection forgery by an attacker guessing valid cookies.
The best description of the exact SYN cookie algorithms is in part of The best description of the exact SYN cookie algorithms is in a part
an email from Bernstein, that is archived on the web site (notice it of an email from Bernstein, that is archived on the web site (notice
does not set the top five bits from the counter modulo 32, as the it does not set the top five bits from the counter modulo 32, as the
previous description did, but instead uses 29 bits from the second previous description did, but instead uses 29 bits from the second
MD5 operation and 3 bits for the index into the MSS table; MD5 operation and 3 bits for the index into the MSS table;
establishing the secret values is also not discussed): establishing the secret values is also not discussed). The remainder
of this section is excerpted from Bernstein's email [cr.yp.to]:
Here's what an implementation would involve: Here's what an implementation would involve:
Maintain two (constant) secret keys, sec1 and sec2. Maintain two (constant) secret keys, sec1 and sec2.
Maintain a (constant) sorted table of 8 common MSS values, Maintain a (constant) sorted table of 8 common MSS values,
msstab[8]. msstab[8].
Keep track of a ``last overflow time.'' Keep track of a ``last overflow time.''
skipping to change at page 20, line 5 skipping to change at page 22, line 5
(3) Figure out whether our alleged ISN makes sense. This (3) Figure out whether our alleged ISN makes sense. This
means recomputing y as above, for each of the counters that means recomputing y as above, for each of the counters that
could have been used in the last few minutes (say, the last could have been used in the last few minutes (say, the last
four counters), and seeing whether any of the y's match the four counters), and seeing whether any of the y's match the
ISN in the bottom 29 bits. If none of them do, give up. ISN in the bottom 29 bits. If none of them do, give up.
(4) Create a new TCB. The top three bits of our ISN give a (4) Create a new TCB. The top three bits of our ISN give a
usable MSS. Turn off all fancy options. usable MSS. Turn off all fancy options.
Intellectual Property Statement Author's Address
Wesley M. Eddy
Verizon Federal Network Systems
NASA Glenn Research Center
21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135
Phone: 216-433-6682
Email: weddy@grc.nasa.gov
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 20, line 29 skipping to change at page 23, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 57 change blocks. 
128 lines changed or deleted 171 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/