Network Working Group W. Eddy
Request for Comments: 4987 Verizon
Category: Informational August 2007
Network Working Group W. Eddy
Request for Comments: 4987 Verizon
Category: Informational August 2007
TCP SYN Flooding Attacks and Common Mitigations
TCP SYN洪泛攻击和常见缓解措施
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations.
本文档描述了TCP SYN洪泛攻击，该攻击已为社区所熟知多年。描述了针对这些攻击的各种对策以及每种对策的权衡。本文档为TCP实施者和TCP服务器或网络管理员的利益归档了对攻击和常见防御技术的解释，但未提出任何标准级建议。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 2
2.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 3
3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Increasing Backlog . . . . . . . . . . . . . . . . . . . . 7
3.3. Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 7
3.4. Recycling the Oldest Half-Open TCB . . . . . . . . . . . . 7
3.5. SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 10
3.8. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 10
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 2
2.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 3
3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Increasing Backlog . . . . . . . . . . . . . . . . . . . . 7
3.3. Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 7
3.4. Recycling the Oldest Half-Open TCB . . . . . . . . . . . . 7
3.5. SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 10
3.8. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 10
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 16
The SYN flooding attack is a denial-of-service method affecting hosts that run TCP server processes. The attack takes advantage of the 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 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 establish new legitimate connections.
SYN洪泛攻击是一种拒绝服务方法，影响运行TCP服务器进程的主机。该攻击利用TCP在接收到已进入侦听状态的端口的SYN段一段时间后执行的状态保留。其基本思想是通过使主机保留足够的状态以进行伪造的半连接，从而使没有资源来建立新的合法连接，从而利用此行为。
This SYN flooding attack has been well-known to the community for many years, and has been observed in the wild by network operators and end hosts. A number of methods have been developed and deployed to make SYN flooding less effective. Despite the notoriety of the attack, and the widely available countermeasures, the RFC series only documented the vulnerability as an example motivation for ingress filtering [RFC2827], and has not suggested any mitigation techniques for TCP implementations. This document addresses both points, but does not define any standards. Formal specifications and requirements of defense mechanisms are outside the scope of this document. Many defenses only impact an end host's implementation without changing interoperability. These may not require standardization, but their side-effects should at least be well understood.
这种SYN洪泛攻击已为社区所熟知多年，网络运营商和终端主机已在野外观察到。已经开发并部署了许多方法来降低SYN洪泛的效率。尽管该攻击声名狼藉，并且有广泛可用的应对措施，但RFC系列仅将该漏洞作为入侵过滤的一个示例动机[RFC2827]进行了记录，并且没有为TCP实现提出任何缓解技术。本文件阐述了这两点，但未定义任何标准。防御机制的正式规范和要求不在本文件范围内。许多防御措施只会影响最终主机的实现，而不会改变互操作性。这些可能不需要标准化，但它们的副作用至少应该得到充分理解。
This document intentionally focuses on SYN flooding attacks from an individual end host or application's perspective, as a means to deny service to that specific entity. High packet-rate attacks that target the network's packet-processing capability and capacity have been observed operationally. Since such attacks target the network, and not a TCP implementation, they are out of scope for this document, whether or not they happen to use TCP SYN segments as part of the attack, as the nature of the packets used is irrelevant in comparison to the packet-rate in such attacks.
本文档有意从单个终端主机或应用程序的角度关注SYN洪泛攻击，以此作为拒绝向特定实体提供服务的手段。已观察到针对网络数据包处理能力和容量的高数据包速率攻击。由于此类攻击的目标是网络，而不是TCP实现，因此无论它们是否碰巧使用TCP SYN段作为攻击的一部分，它们都超出了本文档的范围，因为与此类攻击中的数据包速率相比，所用数据包的性质是不相关的。
The majority of this document consists of three sections. Section 2 explains the SYN flooding attack in greater detail. Several common mitigation techniques are described in Section 3. An analysis and discussion of these techniques and their use is presented in Section 4. Further information on SYN cookies is contained in Appendix A.
本文件大部分由三节组成。第2节更详细地解释了SYN泛洪攻击。第3节介绍了几种常见的缓解技术。第4节对这些技术及其使用进行了分析和讨论。有关SYN Cookie的更多信息，请参见附录A。
This section describes both the history and the technical basis of the SYN flooding attack.
本节介绍SYN洪泛攻击的历史和技术基础。
The TCP SYN flooding weakness was discovered as early as 1994 by Bill Cheswick and Steve Bellovin [B96]. They included, and then removed, a paragraph on the attack in their book "Firewalls and Internet Security: Repelling the Wily Hacker" [CB94]. Unfortunately, no countermeasures were developed within the next two years.
早在1994年，Bill Cheswick和Steve Bellovin就发现了TCP SYN洪泛弱点[B96]。他们在《防火墙和互联网安全：击退狡猾的黑客》一书[CB94]中加入并删除了一段关于攻击的内容。不幸的是，在未来两年内没有制定任何对策。
The SYN flooding attack was first publicized in 1996, with the release of a description and exploit tool in Phrack Magazine [P48-13]. Aside from some minor inaccuracies, this article is of high enough quality to be useful, and code from the article was widely distributed and used.
SYN flooding攻击于1996年首次公开，Phrack杂志[P48-13]发布了一个描述和利用工具。除了一些小的错误，本文的质量足够高，非常有用，并且文章中的代码被广泛分发和使用。
By September of 1996, SYN flooding attacks had been observed in the wild. Particularly, an attack against one ISP's mail servers caused well-publicized outages. CERT quickly released an advisory on the attack [CA-96.21]. SYN flooding was particularly serious in comparison to other known denial-of-service attacks at the time. Rather than relying on the common brute-force tactic of simply exhausting the network's resources, SYN flooding targets end-host resources, which require fewer packets to deplete.
到1996年9月，在野外观察到SYN洪水袭击。特别是，对一家ISP邮件服务器的攻击造成了广为人知的停机。CERT很快发布了关于此次攻击的公告[CA-96.21]。与当时其他已知的拒绝服务攻击相比，SYN泛滥尤其严重。SYN泛洪攻击的目标不是简单地耗尽网络资源的普通暴力策略，而是需要消耗更少数据包的终端主机资源。
The community quickly developed many widely differing techniques for preventing or limiting the impact of SYN flooding attacks. Many of these have been deployed to varying degrees on the Internet, in both end hosts and intervening routers. Some of these techniques have become important pieces of the TCP implementations in certain operating systems, although some significantly diverge from the TCP specification and none of these techniques have yet been standardized or sanctioned by the IETF process.
社区很快开发了许多不同的技术来防止或限制SYN洪泛攻击的影响。其中许多已经不同程度地部署在互联网上，包括终端主机和中间路由器。其中一些技术已成为某些操作系统中TCP实现的重要组成部分，尽管一些技术与TCP规范存在显著差异，并且这些技术尚未被IETF过程标准化或认可。
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 addresses and port numbers specified by the application. In many common applications like web servers, none of the remote host's information is pre-known or preconfigured, so that a connection can be established with any client whose details are unknown to the 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 operating systems.
如RFC 793中所述，TCP实现可能允许使用应用程序指定的全部、部分或全部IP地址和端口号对输入侦听状态。在许多常见的应用程序（如web服务器）中，远程主机的任何信息都不是预先知道的或预先配置的，因此可以提前与服务器不知道其详细信息的任何客户端建立连接。由于操作系统通常采用的实现方式，这种类型的“未绑定”侦听是SYN洪泛攻击的目标。
For success, the SYN flooding attack relies on the victim host TCP implementation's behavior. In particular, it assumes that the victim 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
为了成功，SYN洪泛攻击依赖于受害主机TCP实现的行为。特别是，它假设受害者在接收到每个TCP SYN段时为其分配状态，并且这种状态的数量有一个可以保持的限制
any time. The current base TCP specification, RFC 793 [RFC0793], describes the standard processing of incoming SYN segments. RFC 793 describes the concept of a Transmission Control Block (TCB) data structure to store all the state information for an individual connection. In practice, operating systems may implement this concept rather differently, but the key is that each TCP connection requires some memory space.
随时都可以。当前的基本TCP规范RFC 793[RFC0793]描述了传入SYN段的标准处理。RFC 793描述了传输控制块（TCB）数据结构的概念，用于存储单个连接的所有状态信息。实际上，操作系统实现这一概念的方式可能截然不同，但关键是每个TCP连接都需要一些内存空间。
Per RFC 793, when a SYN is received for a local TCP port where a connection is in the LISTEN state, then the state transitions to SYN-RECEIVED, and some of the TCB is initialized with information from the header fields of the received SYN segment. In practice, many operating systems do not alter the TCB in LISTEN, but instead make a copy of the TCB and perform the state transition and update on the copy. This is done so that the local TCP port may be shared amongst several distinct connections. This TCB-copying behavior is not actually essential for this purpose, but influences the way in which applications that wish to handle multiple simultaneous connections through a single TCP port are written. The crucial result of this behavior is that, instead of updating already-allocated memory, new (or unused) memory must be devoted to the copied TCB.
根据RFC 793，当接收到连接处于侦听状态的本地TCP端口的SYN时，状态转换为SYN-received，并且使用来自接收到的SYN段的头字段的信息初始化一些TCB。实际上，许多操作系统不会在侦听中更改TCB，而是创建TCB的副本，并在副本上执行状态转换和更新。这样做是为了在几个不同的连接之间共享本地TCP端口。这种TCB复制行为实际上并不重要，但会影响希望通过单个TCP端口处理多个同时连接的应用程序的写入方式。这种行为的关键结果是，新的（或未使用的）内存必须专用于复制的TCB，而不是更新已分配的内存。
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 takes over 1300 bytes to store in memory. In other systems that implement less-complex TCP algorithms and options, the overhead may be less, although it typically exceeds 280 bytes [SKK+97].
例如，在Linux2.6.10网络代码中，使用“sock”结构来实现TCB概念。通过检查，这种结构需要超过1300字节才能存储在内存中。在实现较不复杂的TCP算法和选项的其他系统中，开销可能较小，尽管它通常超过280字节[SKK+97]。
To protect host memory from being exhausted by connection requests, the number of TCB structures that can be resident at any time is usually limited by operating system kernels. Systems vary on whether limits are globally applied or local to a particular port number. There is also variation on whether the limits apply to fully established connections as well as those in SYN-RECEIVED. Commonly, systems implement a parameter to the typical listen() system call that allows the application to suggest a value for this limit, called the backlog. When the backlog limit is reached, then either incoming SYN segments are ignored, or uncompleted connections in the backlog are replaced. The concept of using a backlog is not described in the standards documents, so the failure behavior when the backlog is reached might differ between stacks (for instance, TCP RSTs might be generated). The exact failure behavior will determine whether initiating hosts continue to retransmit SYN segments over time, or 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.
为了保护主机内存不被连接请求耗尽，随时可以驻留的TCB结构的数量通常受到操作系统内核的限制。系统因限制是全局应用还是局部应用于特定端口号而有所不同。限制是否适用于完全建立的连接以及SYN-RECEIVE中的连接也存在差异。通常，系统为典型的listen（）系统调用实现一个参数，该参数允许应用程序为此限制建议一个值，称为backlog。当达到backlog限制时，要么忽略传入的SYN段，要么替换backlog中未完成的连接。标准文档中没有描述使用backlog的概念，因此当达到backlog时，堆栈之间的故障行为可能不同（例如，可能会生成TCP RST）。确切的故障行为将决定启动主机是随时间继续重新传输SYN段，还是快速停止。这些实现上的差异是可以接受的，因为它们只会在本地堆栈的资源受到约束时影响本地堆栈的行为，并且不会导致互操作性问题。
The SYN flooding attack does not attempt to overload the network's resources or the end host's memory, but merely attempts to exhaust the backlog of half-open connections associated with a port number. The goal is to send a quick barrage of SYN segments from IP addresses (often spoofed) that will not generate replies to the SYN-ACKs that are produced. By keeping the backlog full of bogus half-opened connections, legitimate requests will be rejected. Three important attack parameters for success are the size of the barrage, the frequency with which barrages are generated, and the means of selecting IP addresses to spoof.
SYN洪泛攻击并不试图使网络资源或终端主机内存过载，而只是试图耗尽与端口号相关的半开放连接的积压。目标是从IP地址（通常是伪造的）快速发送大量SYN段，这些地址不会生成对生成的SYN ACK的回复。通过让积压的连接充满虚假的半开放连接，合法请求将被拒绝。成功的三个重要攻击参数是弹幕的大小、生成弹幕的频率以及选择IP地址进行欺骗的方法。
Barrage Size
拦河坝尺寸
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 the backlog, minimizing the volume of traffic the attacker must source. Typical default backlog values vary from a half-dozen to several dozen, so the attack might be tailored to the particular 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
拦河坝频率
To limit the lifetime of half-opened connection state, TCP implementations commonly reclaim memory from half-opened connections if they do not become fully opened after some time 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 retransmissions to cease and the TCB to be released. The TCP specifications do not include this behavior of giving up on connection establishment after an arbitrary time. Some purists have expressed that the TCP implementation should continue retransmitting SYN and SYN-ACK segments without artificial bounds (but with exponential backoff to some conservative rate) until the application gives up. Despite this, common operating systems today do implement some artificial limit on half-open TCB lifetime. For instance, backing off and stopping after a total of 511 seconds can be observed in 4.4 BSD-Lite [Ste95], and is still practiced in some operating systems derived from this code.
为了限制半开连接状态的生存期，TCP实现通常会从半开连接中回收内存，如果它们在一段时间后没有完全打开。例如，当发送第一个SYN-ACK时，可能会设置75秒[SKK+97]的计时器，到期时会导致SYN-ACK重传停止并释放TCB。TCP规范不包括在任意时间后放弃连接建立的行为。一些纯粹主义者表示，TCP实现应该继续在没有人为限制的情况下重新传输SYN和SYN-ACK段（但以指数退避到某种保守的速率），直到应用程序放弃。尽管如此，今天的通用操作系统确实对半开放TCB生命周期实施了一些人为限制。例如，在4.4 BSD Lite[Ste95]中可以观察到在总共511秒后的后退和停止，并且仍然在一些从该代码派生的操作系统中使用。
To remain effective, a SYN flooding attack needs to send new barrages of bogus connection requests as soon as the TCBs from the previous barrage begin to be reclaimed. The frequency of barrages are tailored to the victim TCP implementation's TCB reclamation timer. Frequencies higher than needed source more packets, potentially drawing more attention, and frequencies that are too
为了保持有效性，SYN洪泛攻击需要在前一个拦网中的TCB开始回收后立即发送新的虚假连接请求拦网。拦截器的频率是根据受害者TCP实现的TCB回收计时器定制的。高于所需的频率会产生更多的数据包，可能会引起更多的注意，并且频率太高
low will allow windows of time where legitimate connections can be established.
low将允许建立合法连接的时间窗口。
IP Address Selection
IP地址选择
For an effective attack, it is important that the spoofed IP addresses be unresponsive to the SYN-ACK segments that the victim will generate. If addresses of normal connected hosts are used, then those hosts will send the victim a TCP reset segment that will immediately free the corresponding TCB and allow room in the backlog for legitimate connections to be made. The code distributed in the original Phrack article used a single source address for all spoofed SYN segments. This makes the attack segments somewhat easier to identify and filter. A strong attacker will have a list of unresponsive and unrelated addresses that it chooses spoofed source addresses from.
对于有效的攻击，伪造的IP地址对受害者将生成的SYN-ACK段没有响应是很重要的。如果使用了正常连接主机的地址，那么这些主机将向受害者发送一个TCP重置段，该段将立即释放相应的TCB，并在待办事项中留出空间进行合法连接。原始Phrack文章中发布的代码对所有伪造的SYN段使用了一个源地址。这使得攻击段更容易识别和过滤。强攻击者将拥有一个无响应和不相关的地址列表，从中选择伪造的源地址。
It is important to note that this attack is directed at particular listening applications on a host, and not the host itself or the network. The attack also attempts to prevent only the establishment of new incoming connections to the victim port, and does not impact outgoing connection requests, nor previously established connections to the victim port.
请务必注意，此攻击针对的是主机上的特定侦听应用程序，而不是主机本身或网络。该攻击还试图仅阻止建立到受害者端口的新传入连接，并且不会影响传出连接请求，也不会影响以前建立的到受害者端口的连接。
In practice, an attacker might choose not to use spoofed IP addresses, but instead to use a multitude of hosts to initiate a SYN flooding attack. For instance, a collection of compromised hosts under the attacker's control (i.e., a "botnet") could be used. In this case, each host utilized in the attack would have to suppress its 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 a more continuous fashion than the "barrage" terminology used here suggests; as long as the rate of new SYNs exceeds the rate at which TCBs are reaped, the attack will be successful.
实际上，攻击者可能选择不使用伪造的IP地址，而是使用多个主机发起SYN洪泛攻击。例如，可以使用攻击者控制的受损主机集合（即“僵尸网络”）。在这种情况下，攻击中使用的每个主机都必须抑制其操作系统对来自目标的SYN ACK的本机响应。攻击TCP段也可能以比此处使用的“拦网”术语更连续的方式到达；只要新SYN的速率超过获取TCB的速率，攻击就会成功。
This section discusses a number of defense techniques that are known to the community, many of which are available in off-the-shelf products.
本节讨论了社区已知的许多防御技术，其中许多可在现成产品中获得。
Since in the absence of an army of controlled hosts, the ability to send packets with spoofed source IP addresses is required for this attack to work, removing an attacker's ability to send spoofed IP packets is an effective solution that requires no modifications to TCP. The filtering techniques described in RFCs 2827, 3013, and 3704
由于在没有大量受控主机的情况下，此攻击需要能够发送具有伪造源IP地址的数据包，因此消除攻击者发送伪造IP数据包的能力是一种有效的解决方案，不需要修改TCP。RFCs 2827、3013和3704中描述的过滤技术
represent the best current practices for packet filtering based on IP addresses [RFC2827][RFC3013][RFC3704]. While perfectly effective, end hosts should not rely on filtering policies to prevent attacks from spoofed segments, as global deployment of filters is neither guaranteed nor likely. An attacker with the ability to use a group of compromised hosts or to rapidly change between different access providers will also make filtering an impotent solution.
代表基于IP地址的数据包过滤的最佳当前实践[RFC2827][RFC3013][RFC3704]。虽然非常有效，但终端主机不应该依赖过滤策略来防止来自欺骗段的攻击，因为过滤器的全局部署既不保证也不可能。能够使用一组受损主机或在不同访问提供商之间快速切换的攻击者也会使过滤成为无效的解决方案。
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 serious negative aspects as the size of the backlog grows [Lem02]. The implementation has not been designed to scale past backlogs of a few hundred, and the data structures and search algorithms that it uses are inefficient with larger backlogs. It is reasonable to assume that other TCP implementations have similar design factors that limit their performance with large backlogs, and there seems to be no compelling reason why stacks should be re-engineered to support extremely large backlogs, since other solutions are available. However, experiments with large backlogs using efficient data structures and search algorithms have not been conducted, to our knowledge.
一个明显的防御尝试是让终端主机使用更大的积压工作。Lemon已经表明，在FreeBSD 4.4中，随着积压工作的增加，这种策略有一些严重的负面影响[Lem02]。该实现的设计目的不是为了扩展过去几百个积压的数据，而且它使用的数据结构和搜索算法对于更大的积压数据效率低下。可以合理地假设，其他TCP实现具有类似的设计因素，这些因素限制了它们在大量积压情况下的性能，而且似乎没有令人信服的理由说明为什么应该重新设计堆栈以支持非常大的积压，因为还有其他解决方案可用。然而，据我们所知，还没有使用有效的数据结构和搜索算法进行大规模积压的实验。
Another quickly implementable defense is shortening the timeout period between receiving a SYN and reaping the created TCB for lack of progress. Decreasing the timer that limits the lifetime of TCBs in SYN-RECEIVED is also flawed. While a shorter timer will keep bogus connection attempts from persisting for as long in the backlog, and thus free up space for legitimate connections sooner, it can 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. This timer reduction is sometimes implemented as a response to crossing some threshold in the backlog occupancy, or some rate of SYN reception.
另一种可快速实施的防御措施是缩短接收SYN和获取创建的TCB之间的超时时间，以防进度不足。减少限制SYN-RECEIVE中TCB寿命的计时器也是有缺陷的。虽然较短的计时器将防止伪连接尝试在积压工作中持续时间过长，从而更快地为合法连接释放空间，但它可以防止部分合法连接完全建立。这种战术也是无效的，因为它只需要攻击者按线性比例增加弹幕频率。这种计时器减少有时作为对超过积压占用率中的某个阈值或某个SYN接收速率的响应而实现。
Once the entire backlog is exhausted, some implementations allow incoming SYNs to overwrite the oldest half-open TCB entry. This works under the assumption that legitimate connections can be fully established in less time than the backlog can be filled by incoming attack SYNs. This can fail when the attacking packet rate is high and/or the backlog size is small, and is not a robust defense.
一旦整个积压完成，一些实现允许传入的SYN覆盖最旧的半开放TCB条目。这是在这样的假设下工作的，即合法连接可以在比传入攻击SYN填充积压的时间更短的时间内完全建立。当攻击数据包速率较高和/或待办事项规模较小时，这可能会失败，并且不是一种稳健的防御。
The SYN cache, best described by Lemon [Lem02], is based on minimizing the amount of state that a SYN allocates, i.e., not immediately allocating a full TCB. The full state allocation is delayed until the connection has been fully established. Hosts implementing a SYN cache have some secret bits that they select from the incoming SYN segments. The secret bits are hashed along with the IP addresses and TCP ports of a segment, and the hash value 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 this limit is reached, the oldest entry is dropped.
Lemon[Lem02]最恰当地描述了SYN缓存，它基于最小化SYN分配的状态量，即不立即分配完整的TCB。完全状态分配延迟，直到连接完全建立。实现SYN缓存的主机具有一些从传入SYN段中选择的秘密位。秘密位与段的IP地址和TCP端口一起散列，散列值确定全局散列表中存储不完整TCB的位置。每个哈希值都有一个bucket限制，当达到该限制时，最早的条目将被丢弃。
The SYN cache technique is effective because the secret bits prevent an attacker from being able to target specific hash values for overflowing the bucket limit, and it bounds both the CPU time and memory requirements. Lemon's evaluation of the SYN cache shows that even under conditions where a SYN flooding attack is not being performed, due to the modified processing path, connection establishment is slightly more expedient. Under active attack, SYN cache performance was observed to approximately linearly shift the distribution of times to establish legitimate connections to about 15% longer than when not under attack [Lem02].
SYN缓存技术是有效的，因为秘密位阻止攻击者针对特定哈希值溢出存储桶限制，并且限制了CPU时间和内存需求。Lemon对SYN缓存的评估表明，即使在没有执行SYN洪泛攻击的情况下，由于修改了处理路径，建立连接也稍微方便一些。在主动攻击下，观察到SYN缓存性能将建立合法连接的时间分布近似线性地改变为比不受攻击时长15%左右[Lem02]。
If data accompanies the SYN segment, then this data is not acknowledged or stored by the receiver, and will require retransmission. This does not affect the reliability of TCP's data transfer service, but it does affect its performance to some small 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. 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 (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.
如果数据伴随SYN段，则接收器不会确认或存储该数据，并且需要重新传输。这不会影响TCP数据传输服务的可靠性，但会在一定程度上影响其性能。承载数据的SYN由T/TCP扩展[RFC1644]使用。虽然T/TCP在许多流行的操作系统[GN00]中实现，但目前似乎很少使用。在一个站点的边界路由器[All07]上进行的测量记录了2545785个SYN段（非SYN ACK），其中36个带有T/TCP CCNEW选项（或0.001%）。这些来自26个独特的主机，没有看到其他T/TCP选项。看到了2287个包含数据的SYN段（占所有SYN段的0.09%），所有SYN段都有24个字节的数据。这些观察结果表明，SYN缓存和SYN段上的数据问题在部署中可能并不重要。
SYN cookies go a step further and allocate no state at all for connections in SYN-RECEIVED. Instead, they encode most of the state (and all of the strictly required) state that they would normally keep into the sequence number transmitted on the SYN-ACK. If the SYN was not spoofed, then the acknowledgement number (along with several 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
SYN Cookie更进一步，在SYN-RECEIVED中根本不为连接分配任何状态。相反，它们将通常保留在SYN-ACK上传输的序列号中的大部分状态（以及所有严格要求的）进行编码。如果SYN未被欺骗，则ACK中完成握手的确认号（以及其他几个字段）可用于重建要放入TCB的状态。迄今为止，其中一个
best references on SYN cookies can be found on Dan Bernstein's web site [cr.yp.to]. This technique exploits the long-understood low entropy in TCP header fields [RFC1144][RFC4413]. In Appendix A, we describe the SYN cookie technique, to avoid the possibility that the web page will become unavailable.
有关SYN cookies的最佳参考资料可以在Dan Bernstein的网站[cr.yp.to]上找到。这种技术利用了TCP头字段[RFC1144][RFC4413]中长期以来被理解的低熵。在附录A中，我们描述了SYN cookie技术，以避免网页不可用的可能性。
The exact mechanism for encoding state into the SYN-ACK sequence number can be implementation dependent. A common consideration is that to prevent replay, some time-dependent random bits must be embedded in the sequence number. One technique used 7 bits for these bits and 25 bits for the other data [Lem02]. One way to encode these bits has been to XOR the initial sequence number received with a truncated cryptographic hash of the IP address and TCP port number pairs, and secret bits. In practice, this hash has been generated using MD5 [RFC1321]. Any similar one-way hash could be used instead without impacting interoperability since the hash value is checked by the same host who generates it.
将状态编码为SYN-ACK序列号的确切机制可能取决于实现。一个常见的考虑是，为了防止重播，必须在序列号中嵌入一些与时间相关的随机位。一种技术使用7位表示这些位，25位表示其他数据[Lem02]。对这些位进行编码的一种方法是对接收到的初始序列号与IP地址和TCP端口号对的截断加密散列以及秘密位进行异或运算。实际上，此哈希是使用MD5[RFC1321]生成的。可以使用任何类似的单向散列，而不会影响互操作性，因为散列值是由生成它的同一主机检查的。
The problem with SYN cookies is that commonly implemented schemes are incompatible with some TCP options, if the cookie generation scheme does not consider them. For example, an encoding of the Maximum Segment Size (MSS) advertised on the SYN has been accommodated by using 2 sequence number bits to represent 4 predefined common MSS values. Similar techniques would be required for some other TCP options, while negotiated use of other TCP options can be detected implicitly. A timestamp on the ACK, as an example, indicates that Timestamp use was successfully negotiated on the SYN and SYN-ACK, while the reception of a Selective Acknowledgement (SACK) option at some point during the connection implies that SACK was negotiated. Note that SACK blocks should normally not be sent by a host using TCP cookies unless they are first received. For the common unidirectional data flow in many TCP connections, this can 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 are only enabled either under high-stress conditions indicative of an attack, or via administrative action.
SYN Cookie的问题是，如果Cookie生成方案不考虑它们，通常实现的方案与某些TCP选项不兼容。例如，通过使用2个序列号比特来表示4个预定义的公共MSS值来适应在SYN上公布的最大段大小（MSS）的编码。其他一些TCP选项也需要类似的技术，而其他TCP选项的协商使用可以隐式检测。例如，ACK上的时间戳指示在SYN和SYN-ACK上成功协商时间戳使用，而在连接期间的某个点接收到选择性确认（SACK）选项意味着SACK已协商。请注意，SACK块通常不应由使用TCP cookie的主机发送，除非它们是第一次收到。对于许多TCP连接中常见的单向数据流，这可能是一个问题，因为它限制了SACK的使用。因此，默认情况下，SYN Cookie通常不会在实现它们的系统上使用，并且只能在指示攻击的高压力条件下或通过管理操作启用。
Recently, a new SYN cookie technique developed for release in FreeBSD 7.0 leverages the bits of the Timestamp option in addition to the sequence number bits for encoding state. Since the Timestamp value is echoed back in the Timestamp Echo field of the ACK packet, any state stored in the Timestamp option can be restored similarly to the way that it is from the sequence number / acknowledgement in a basic SYN cookie. Using the Timestamp bits, it is possible to explicitly store state bits for things like send and receive window scales, SACK-allowed, and TCP-MD5-enabled, for which there is no room in a typical SYN cookie. This use of Timestamps to improve the compromises inherent in SYN cookies is unique to the FreeBSD
最近，在FreeBSD 7.0中开发了一种新的SYN cookie技术，该技术利用了时间戳选项的位以及编码状态的序列号位。由于在ACK分组的Timestamp Echo字段中回显时间戳值，因此可以类似于从基本SYN cookie中的序列号/确认恢复时间戳选项中存储的任何状态。使用时间戳位，可以显式地存储诸如发送和接收窗口比例、允许SACK和启用TCP-MD5之类的状态位，典型的SYN cookie中没有空间存储这些状态位。使用时间戳来改进SYN Cookie中固有的折衷是FreeBSD所独有的
implementation, to our knowledge. A limitation is that the technique can only be used if the SYN itself contains a Timestamp option, but this option seems to be widely implemented today, and hosts that support window scaling and SACK typically support timestamps as well.
据我们所知，执行。一个限制是，该技术只能在SYN本身包含时间戳选项的情况下使用，但该选项目前似乎得到了广泛的实现，并且支持窗口缩放和SACK的主机通常也支持时间戳。
Similarly to SYN caches, SYN cookies do not handle application data piggybacked on the SYN segment.
与SYN缓存类似，SYN Cookie不处理搭载在SYN段上的应用程序数据。
Another problem with SYN cookies is for applications where the first application data is sent by the passive host. If this host is handling a large number of connections, then packet loss may be likely. When a handshake-completing ACK from the initiator is lost, the passive side's application layer never is notified of the connection's existence and never sends data, even though the initiator thinks that the connection has been successfully established. An example application where the first application-layer data is sent by the passive side is SMTP, if implemented according to RFC 2821, where a "service ready" message is sent by the passive side after the TCP handshake is completed.
SYN Cookie的另一个问题是，第一个应用程序数据由被动主机发送的应用程序。如果此主机正在处理大量连接，则可能会发生数据包丢失。当来自发起方的握手完成ACK丢失时，即使发起方认为连接已成功建立，被动方的应用层也不会收到连接存在的通知，也不会发送数据。被动端发送第一个应用层数据的示例应用程序是SMTP，如果根据RFC 2821实现，则被动端在TCP握手完成后发送“服务就绪”消息。
Although SYN cookie implementations exist and are deployed, the use of SYN cookies is often disabled in default configurations, so it is unclear how much operational experience actually exists with them or if using them opens up new vulnerabilities. Anecdotes of incidents where SYN cookies have been used on typical web servers seem to indicate that the added processing burden of computing MD5 sums for every SYN packet received is not significant in comparison to the loss of application availability when undefended. For some computationally constrained mobile or embedded devices, this situation might be different.
尽管存在并部署了SYN cookie实现，但在默认配置中，SYN cookie的使用通常被禁用，因此不清楚它们实际存在多少操作经验，或者使用它们是否会打开新的漏洞。在典型web服务器上使用SYN Cookie的事件的轶事似乎表明，与未设防时应用程序可用性的损失相比，计算每个接收到的SYN数据包的MD5总和所增加的处理负担并不显著。对于某些计算受限的移动或嵌入式设备，这种情况可能不同。
The SYN cache and SYN cookie techniques can be combined. For 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 SYNs. Such hybrid approaches may provide a strong combination of the positive aspects of each approach. Lemon has demonstrated the utility of this hybrid [Lem02].
SYN缓存和SYN cookie技术可以结合使用。例如，如果缓存已满，则可以发送SYN cookies，而不是在新SYN到达时清除缓存项。这种混合方法可以提供每种方法积极方面的强大组合。Lemon已经证明了这种杂交的效用[Lem02]。
Firewall-based tactics may also be used to defend end hosts from SYN flooding attacks. The basic concept is to offload the connection establishment procedures onto a firewall that screens connection attempts until they are completed and then proxies them back 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
基于防火墙的策略也可用于保护终端主机免受SYN洪泛攻击。基本概念是将连接建立过程卸载到防火墙上，防火墙会屏蔽连接尝试，直到连接尝试完成，然后将其代理回受保护的终端主机。这将问题从终端主机转移到防火墙或代理的问题，并可能引入其他问题
problems related to altering TCP's expected end-to-end semantics. A common tactic used in these firewall and proxy products is to implement one of the end host based techniques discussed above, and screen incoming SYNs from the protected network until the connection is fully established. This is accomplished by spoofing the source addresses of several packets to the initiator and listener at various stages of the handshake [Eddy06].
与更改TCP的预期端到端语义相关的问题。这些防火墙和代理产品中使用的一种常见策略是实施上述基于终端主机的技术之一，并屏蔽来自受保护网络的传入SYN，直到完全建立连接。这是通过在握手的不同阶段将多个数据包的源地址欺骗给启动器和侦听器来实现的[Eddy06]。
Several of the defenses discussed in the previous section rely on changes to behavior inside the network; via router filtering, firewalls, and proxies. These may be highly effective, and often require no modification or configuration of end-host software. Given the mobile nature and dynamic connectivity of many end hosts, it is optimistic for TCP implementers to assume the presence of such protective devices. TCP implementers should provide some means of defense to SYN flooding attacks in end-host implementations.
上一节讨论的几种防御依赖于网络内部行为的变化；通过路由器过滤、防火墙和代理。这些可能非常有效，通常不需要修改或配置终端主机软件。考虑到许多终端主机的移动性质和动态连接性，TCP实现者假设存在此类保护设备是乐观的。TCP实现者应该为终端主机实现中的SYN洪泛攻击提供一些防御手段。
Among end-host modifications, the SYN cache and SYN cookie approaches seem to be the only viable techniques discovered to date. Increasing the backlog and reducing the SYN-RECEIVED timer are measurably problematic. The SYN cache implies a higher memory footprint than SYN cookies; however, SYN cookies may not be fully compatible with some TCP options, and may hamper development of future TCP extensions that require state. For these reasons, SYN cookies should not be enabled by default on systems that provide them. SYN caches do not have the same negative implications and may be enabled as a default mode of processing.
在终端主机修改中，SYN缓存和SYN cookie方法似乎是迄今为止发现的唯一可行的技术。增加待办事项和减少SYN-RECEIVED计时器都存在明显的问题。SYN缓存意味着比SYN Cookie占用更大的内存；但是，SYN Cookie可能与某些TCP选项不完全兼容，并且可能会妨碍需要状态的未来TCP扩展的开发。出于这些原因，默认情况下，在提供SYN cookie的系统上不应启用SYN cookie。SYN缓存没有相同的负面影响，可以作为默认处理模式启用。
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 code seems to be the basis for the SYN cache implementations adopted 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 the tcp-impl mailing list explains that this code does not retransmit SYN-ACKs [B97]. More recent implementations have chosen to reverse this decision and retransmit SYN-ACKs. It is known that loss of SYN-ACK packets is not uncommon [SD01] and can severely slow the performance of connections when initial retransmission timers for SYNs are overly conservative (as in some operating systems) or retransmitted SYNs are lost. Furthermore, if a SYN flooding attacker has a high sending rate, loss of retransmitted SYNs is likely, so if SYN-ACKs are not retransmitted, the chance of efficiently establishing legitimate connections is reduced.
1996年10月，Dave Borman在BSDi为BSD/OS实现了一个SYN缓存，该缓存提供给社区，没有任何限制。这段代码似乎是后面在其他BSD变体中采用的SYN缓存实现的基础。缓存是在积压工作已满时使用的，而不是如我们所述的默认情况。tcp impl邮件列表的一个注释解释了此代码不会重新传输SYN ACK[B97]。最近的实现选择了逆转这一决定并重新传输SYN ACK。众所周知，SYN-ACK数据包的丢失并不罕见[SD01]，当SYN的初始重传计时器过于保守（如在某些操作系统中）或重传的SYN丢失时，会严重降低连接的性能。此外，如果SYN洪泛攻击者具有较高的发送速率，则可能会丢失重新传输的SYN，因此，如果不重新传输SYN ACK，则有效建立合法连接的机会会降低。
In 1997, NetBSD incorporated a modified version of Borman's code. Two notable differences from the original code stem from the decision to use the cache by default (for all connections). This implied the need to perform retransmissions for SYN-ACKs, and to use larger structures to keep more complete data. The original structure was 32 bytes long for IPv4 connections and 56 bytes with IPv6 support, while the current FreeBSD structure is 196 bytes long. As previously cited, Lemon implemented the SYN cache and cookie techniques in FreeBSD 4.4 [Lem02]. Lemon notes that a SYN cache structure took up 160 bytes compared to 736 for the full TCB (now 196 bytes for the cache structure). We have examined the OpenBSD 3.6 code and determined that it includes a similar SYN cache.
1997年，NetBSD合并了Borman代码的修改版本。与原始代码的两个显著差异源于默认情况下（对于所有连接）使用缓存的决定。这意味着需要对SYN ACK执行重传，并使用更大的结构来保存更完整的数据。IPv4连接的原始结构长度为32字节，支持IPv6的原始结构长度为56字节，而当前的FreeBSD结构长度为196字节。如前所述，Lemon在FreeBSD 4.4[Lem02]中实现了SYN缓存和cookie技术。Lemon指出，SYN缓存结构占用160字节，而完整TCB占用736字节（现在缓存结构占用196字节）。我们已经检查了OpenBSD3.6代码，并确定它包含一个类似的SYN缓存。
Linux 2.6.5 code, also by examination, contains a SYN cookie implementation that encodes 8 MSS values, and does not use SYN cookies by default. This functionality has been present in the Linux kernel for several years previous to 2.6.5.
Linux2.6.5代码（也经过检查）包含一个SYN cookie实现，该实现对8个MSS值进行编码，默认情况下不使用SYN cookie。在2.6.5之前的几年中，Linux内核中一直存在此功能。
When a SYN cache and/or SYN cookies are implemented with IPv6, the IPv6 flow label value used on the SYN-ACK should be consistent with the flow label used for the rest of the packets within that flow. There have been implementation bugs that caused random flow labels to be used in SYN-ACKs generated by SYN cache and SYN cookie code [MM05].
使用IPv6实现SYN缓存和/或SYN Cookie时，SYN-ACK上使用的IPv6流标签值应与该流中其余数据包使用的流标签一致。有一些实现错误导致在SYN缓存和SYN cookie代码生成的SYN ACK中使用随机流标签[MM05]。
Beginning with Windows 2000, Microsoft's Windows operating systems 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 SP1, in which it is on by default. With this feature enabled, when the number of half-open connections and half-open connections with retransmitted SYN-ACKs exceeds configurable thresholds, then the number of times that SYN-ACKs are retransmitted before giving up is reduced, and the "Route Cache Entry" creation is delayed, which prevents some features (e.g., window scaling) from being used [win2k3-wp].
从Windows 2000开始，Microsoft的Windows操作系统具有“TCP SYN攻击保护”功能，可以在注册表中打开或关闭该功能。在Windows 2003 SP1之前，该选项默认为关闭，默认情况下，该选项处于打开状态。启用此功能后，当半开放连接数和具有重传SYN ACK的半开放连接数超过可配置阈值时，SYN ACK在放弃前被重传的次数将减少，“路由缓存项”创建将延迟，这将阻止某些功能（例如，窗口缩放）从正在使用[win2k3 wp]。
Several vendors of commercial firewall products sell devices that can mitigate SYN flooding's effects on end hosts by proxying connections.
几家商用防火墙产品供应商销售的设备可以通过代理连接减轻SYN洪泛对终端主机的影响。
Discovery and exploitation of the SYN flooding vulnerability in TCP's design provided a valuable lesson for protocol designers. The Stream Control Transmission Protocol [RFC2960], which was designed more recently, incorporated a 4-way handshake with a stateless cookie-based component for the listening end. In this way, the passive-opening side has better evidence that the initiator really exists at the given address before it allocates any state. The Host Identity Protocol base exchange [MNJH07] is similarly designed as a 4-way handshake, but also involves a puzzle sent to the initiator that must
TCP设计中SYN洪泛漏洞的发现和利用为协议设计者提供了宝贵的经验。最近设计的流控制传输协议[RFC2960]将4路握手与基于cookie的无状态组件结合起来，用于监听端。通过这种方式，被动打开端在分配任何状态之前有更好的证据证明启动器确实存在于给定地址。主机标识协议基本交换[MNJH07]类似地设计为4路握手，但也涉及发送给启动器的谜题，该谜题必须
be solved before any state is reserved by the responder. The general concept of designing statelessness into protocol setup to avoid denial-of-service attacks has been discussed by Aura and Nikander [AN97].
在响应程序保留任何状态之前解决。Aura和Nikander[AN97]讨论了在协议设置中设计无状态以避免拒绝服务攻击的一般概念。
The SYN flooding attack on TCP has been described in numerous other publications, and the details and code needed to perform the attack have been easily available for years. Describing the attack in this document does not pose any danger of further publicizing this weakness in unmodified TCP stacks. Several widely deployed operating systems implement the mitigation techniques that this document discusses for defeating SYN flooding attacks. In at least some cases, these operating systems do not enable these countermeasures by default; however, the mechanisms for defeating SYN flooding are well deployed, and easily enabled by end-users. The publication of this document should not influence the number of SYN flooding attacks observed, and might increase the robustness of the Internet to such attacks by encouraging use of the commonly available mitigations.
TCP上的SYN flooding攻击在许多其他出版物中都有描述，执行该攻击所需的详细信息和代码多年来一直很容易获得。本文档中描述的攻击不会在未修改的TCP堆栈中进一步公开此弱点。几个广泛部署的操作系统实现了本文讨论的抵御SYN洪泛攻击的缓解技术。至少在某些情况下，这些操作系统在默认情况下不启用这些对策；然而，抵御SYN洪泛的机制部署良好，最终用户可以轻松启用。本文档的发布不应影响观察到的SYN洪泛攻击的数量，并可能通过鼓励使用常用的缓解措施来提高互联网对此类攻击的鲁棒性。
A conversation with Ted Faber was the impetus for writing this document. Comments and suggestions from Joe Touch, Dave Borman, Fernando Gont, Jean-Baptiste Marchand, Christian Huitema, Caitlin Bestler, Pekka Savola, Andre Oppermann, Alfred Hoenes, Mark Allman, Lars Eggert, Pasi Eronen, Warren Kumari, David Malone, Ron Bonica, and Lisa Dusseault were useful in strengthening this document. The original work on TCP SYN cookies presented in Appendix A is due to D.J. Bernstein.
与Ted Faber的对话是撰写本文件的动力。Joe Touch、Dave Borman、Fernando Gont、Jean-Baptiste Marchand、Christian Huitema、Caitlin Bestler、Pekka Savola、Andre Oppermann、Alfred Hoenes、Mark Allman、Lars Eggert、Pasi Eren、Warren Kumari、David Malone、Ron Bonica和Lisa Dusseault的评论和建议有助于加强本文件。附录A中介绍的关于TCP SYN Cookie的原始工作应归功于D.J.Bernstein。
Work on this document was performed at NASA's Glenn Research Center. Funding was partially provided by a combination of NASA's Advanced Communications, Navigation, and Surveillance Architectures and System Technologies (ACAST) project, the Sensis Corporation, NASA's Space Communications Architecture Working Group, and NASA's Earth Science Technology Office.
这份文件是在美国宇航局格伦研究中心完成的。部分资金由美国宇航局先进通信、导航和监视体系结构与系统技术（ACAST）项目、Sensis公司、美国宇航局空间通信体系结构工作组和美国宇航局地球科学技术办公室共同提供。
[AN97] Aura, T. and P. Nikander, "Stateless Connections", Proceedings of the First International Conference on Information and Communication Security, 1997.
[AN97]Aura，T.和P.Nikander，“无国籍联系”，第一届信息和通信安全国际会议记录，1997年。
[All07] Allman, M., "personal communication", February 2007.
[All07]Allman，M.，“个人沟通”，2007年2月。
[B96] Bennahum, D., "PANIX ATTACK", MEME 2.12, October 1996, <http://memex.org/meme2-12.html>.
[B96]Bennahum，D.，“PANIX攻击”，模因2.12，1996年10月<http://memex.org/meme2-12.html>.
[B97] Borman, D., "Re: SYN/RST cookies (was Re: a quick clarification...)", IETF tcp-impl mailing list, June 1997.
[B97]Borman，D.，“Re:SYN/RST cookies（was Re:a quick Declaration…），《IETF tcp impl邮件列表》，1997年6月。
[CA-96.21] CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks", September 1996.
[CA-96.21]证书，“证书咨询CA-1996-21 TCP SYN洪泛和IP欺骗攻击”，1996年9月。
[CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet Security", ISBN: 0201633574, January 1994.
[CB94]Cheswick，W.和S.Bellovin，“防火墙和互联网安全”，ISBN:0201633574，1994年1月。
[Eddy06] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", Cisco Internet Protocol Journal Volume 8, Number 4, December 2006.
[Eddy06]Eddy，W.“针对TCP SYN洪泛攻击的防御”，《思科互联网协议期刊》第8卷，第4期，2006年12月。
[GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for Transactions", Linux Journal, February 2000.
[GN00]Griffin，M.和J.Nelson，“T/TCP:TCP for Transactions”，Linux期刊，2000年2月。
[Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN Cache", BSDCON 2002, February 2002.
[Lem02]Lemon，J.，“使用SYN缓存抵御SYN洪水DoS攻击”，BSDCON 2002，2002年2月。
[MM05] McGann, O. and D. Malone, "Flow Label Filtering Feasibility", European Conference on Computer Network Defense 2005, December 2005.
[MM05]McGann，O.和D.Malone，“流量标签过滤可行性”，2005年欧洲计算机网络防御会议，2005年12月。
[MNJH07] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", Work in Progress, June 2007.
[MNJH07]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，正在进行的工作，2007年6月。
[P48-13] daemon9, route, and infinity, "Project Neptune", Phrack Magazine, Volume 7, Issue 48, File 13 of 18, July 1996.
[P48-13]daemon9，route and infinity，“海王星计划”，Phrack杂志，第7卷，第48期，1996年7月18日第13卷。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP报头”，RFC1144，1990年2月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644]Braden，B，“T/TCP——事务功能规范的TCP扩展”，RFC16441994年7月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.
[RFC3013]Killalea，T.，“推荐的互联网服务提供商安全服务和程序”，BCP 46，RFC 3013，2000年11月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, March 2006.
[RFC4413]West，M.和S.McCann，“TCP/IP现场行为”，RFC4413，2006年3月。
[SD01] Seddigh, N. and M. Devetsikiotis, "Studies of TCP's Retransmission Timeout Mechanism", Proceedings of the 2001 IEEE International Conference on Communications (ICC 2001), volume 6, pages 1834-1840, June 2001.
[SD01]Seddigh，N.和M.Devetsikiotis，“TCP重传超时机制的研究”，2001年IEEE国际通信会议记录（ICC 2001），第6卷，第1834-1840页，2001年6月。
[SKK+97] Schuba, C., Krsul, I., Kuhn, M., Spafford, E., Sundaram, A., and D. Zamboni, "Analysis of a Denial of Service Attack on TCP", Proceedings of the 1997 IEEE Symposium on Security and Privacy 1997.
[SKK+97]Schuba，C.，Krsul，I.，Kuhn，M.，Spafford，E.，Sundaram，A.，和D.Zamboni，“TCP拒绝服务攻击的分析”，1997年IEEE安全和隐私研讨会论文集，1997年。
[Ste95] Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume 2: The Implementation", January 1995.
[Ste95]Stevens，W.和G.Wright，“TCP/IP图解，第2卷：实现”，1995年1月。
[cr.yp.to] Bernstein, D., "SYN cookies", visited in December 2005, <http://cr.yp.to/syncookies.html>.
[cr.yp.to]Bernstein，D.，“SYN cookies”，于2005年12月访问<http://cr.yp.to/syncookies.html>.
[win2k3-wp] Microsoft Corporation, "Microsoft Windows Server 2003 TCP/IP Implementation Details", White Paper, July 2005.
[win2k3 wp]微软公司，“微软Windows Server 2003 TCP/IP实施细节”，白皮书，2005年7月。
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 web page and not a full replacement. There are other slightly different ways of implementing the SYN cookie concept than the exact means described here, although the basic idea of encoding data into the SYN-ACK sequence number is constant.
此信息取自Bernstein在SYN cookies[cr.yp.to]上的网页。这是对该网页上技术信息的重写，而不是完全替换。虽然将数据编码到SYN-ACK序列号的基本思想是不变的，但实现SYN cookie概念的方法与这里描述的确切方法稍有不同。
A SYN cookie is an initial sequence number sent in the SYN-ACK, that is chosen based on the connection initiator's initial sequence number, MSS, a time counter, and the relevant addresses and port numbers. The actual bits comprising the SYN cookie are chosen to be the bitwise difference (exclusive-or) between the SYN's sequence 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 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 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 initial sequence number for use in the SYN-ACK complies with the rule that TCP sequence numbers increase slowly.
SYN cookie是在SYN-ACK中发送的初始序列号，它是根据连接启动器的初始序列号、MSS、时间计数器以及相关地址和端口号选择的。构成SYN cookie的实际位被选择为SYN序列号和计算的32位数量之间的位差（异或），以便前五位来自32位计数器值模32，其中计数器每64秒增加一次，接下来的3位编码接近SYN中的一个可用MSS，底部24位是服务器选择的IP地址对、端口号对和前5位使用的32位计数器的秘密函数。选择初始序列号用于SYN-ACK的方法符合TCP序列号缓慢增加的规则。
When a connection in LISTEN receives a SYN segment, it can generate a SYN cookie and send it in the sequence number of a SYN-ACK, without allocating any other state. If an ACK comes back, the difference between the acknowledged sequence number and the sequence number of the ACK segment can be checked against recent values of the counter 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 match, the connection can be accepted, since it is statistically very 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 can be rejected under the heuristic that it is probably not in response to a recently sent SYN-ACK.
当侦听中的连接接收到SYN段时，它可以生成SYN cookie并以SYN-ACK的序列号发送，而无需分配任何其他状态。如果ACK返回，确认的序列号和ACK段的序列号之间的差异可以根据计数器的最新值以及给定这些计数器值和ACK段中的IP地址和端口号的秘密函数的输出进行检查。如果存在匹配项，则可以接受连接，因为从统计上看，很可能是另一方收到了SYN cookie，而不是简单地猜测有效的cookie值。如果不存在匹配项，则可以根据启发式规则拒绝连接，即该连接可能不是对最近发送的SYN-ACK的响应。
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 for using SYN cookies is in the disabling of the window scaling option, which disables high performance.
启用SYN Cookie后，主机将能够在受到SYN洪泛攻击时保持响应。使用SYN Cookie的最大代价是禁用窗口缩放选项，这将禁用高性能。
Bernstein's web page [cr.yp.to] contains more information about the initial conceptualization and implementation of SYN cookies, and archives of emails documenting this history. It also lists some false negative claims that have been made about SYN cookies, and discusses reducing the vulnerability of SYN cookie implementations to blind connection forgery by an attacker guessing valid cookies.
Bernstein的网页[cr.yp.to]包含关于SYN Cookie的初始概念和实现的更多信息，以及记录此历史的电子邮件档案。它还列出了一些关于SYN cookie的错误否定声明，并讨论了如何降低SYN cookie实现的漏洞，以防止攻击者猜测有效cookie时造成盲目连接伪造。
The best description of the exact SYN cookie algorithms is in a part of an email from Bernstein, that is archived on the web site (notice 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 MD5 operation and 3 bits for the index into the MSS table; establishing the secret values is also not discussed). The remainder of this section is excerpted from Bernstein's email [cr.yp.to]:
对确切的SYN cookie算法的最好描述是在Bernstein发来的一封电子邮件的一部分，该电子邮件存档在网站上（注意，它没有像前面的描述那样设置计数器模32的前五位，而是使用第二个MD5操作的29位和MSS表的索引的3位；也没有讨论建立秘密值）。本节的其余部分摘自Bernstein的电子邮件[cr.yp.to]：
Here's what an implementation would involve:
以下是实施所涉及的内容：
Maintain two (constant) secret keys, sec1 and sec2.
维护两个（恒定）密钥，sec1和sec2。
Maintain a (constant) sorted table of 8 common MSS values, msstab[8].
维护一个包含8个常见MSS值的（常量）排序表，msstab[8]。
Keep track of a "last overflow time".
跟踪“上次溢出时间”。
Maintain a counter that increases slowly over time and never repeats, such as "number of seconds since 1970, shifted right 6 bits".
保持一个随时间缓慢增加且从不重复的计数器，例如“自1970年以来的秒数，右移6位”。
When a SYN comes in from (saddr,sport) to (daddr,dport) with ISN x, find the largest i for which msstab[i] <= the incoming MSS. Compute
当SYN从（saddr、sport）到（daddr、dport）并带有ISNx时，查找msstab[i]<=传入MSS的最大i。计算
z = MD5(sec1,saddr,sport,daddr,dport,sec1)
z=MD5（sec1、SADD、sport、daddr、dport、sec1）
+ x
+ 十、
+ (counter << 24)
+ (counter << 24)
+ (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 <<
24))
+ (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 <<
24))
and then
然后
y = (i << 29) + (z % (1 << 29))
y = (i << 29) + (z % (1 << 29))
Create a TCB as usual, with y as our ISN. Send back a SYNACK.
像往常一样创建一个TCB，y作为我们的ISN。发回一个SYNACK。
Exception: _If_ we're out of memory for TCBs, set the "last overflow time" to the current time. Send the SYNACK anyway, with all fancy options turned off.
异常：\如果\uu TCB的内存不足，请将“上次溢出时间”设置为当前时间。在关闭所有高级选项的情况下，仍然发送SYNACK。
When an ACK comes back, follow this procedure to find a TCB:
当ACK返回时，按照以下步骤查找TCB：
(1) Look for a (saddr,sport,daddr,dport) TCB. If it's there, done.
(1) 寻找（SADD、sport、daddr、dport）TCB。如果它在那里，就完成了。
(2) If the "last overflow time" is earlier than a few minutes ago, give up.
(2) 如果“最后一次溢出时间”比几分钟前早，请放弃。
(3) Figure out whether our alleged ISN makes sense. This means recomputing y as above, for each of the counters that could have been used in the last few minutes (say, the last 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.
(3) 弄清楚我们所谓的不安全感是否有意义。这意味着如上所述，对过去几分钟内可能使用过的每个计数器（例如，最后四个计数器）重新计算y，并查看y是否与底部29位的ISN匹配。如果没有人这样做，就放弃。
(4) Create a new TCB. The top three bits of our ISN give a usable MSS. Turn off all fancy options.
(4) 创建一个新的TCB。ISN的前三位给出了一个可用的MSS。关闭所有花式选项。
Author's Address
作者地址
Wesley M. Eddy Verizon Federal Network Systems NASA Glenn Research Center 21000 Brookpark Rd, MS 54-5 Cleveland, OH 44135
威斯利·M·埃迪·威瑞森联邦网络系统美国宇航局格伦研究中心，俄亥俄州克利夫兰市布鲁克公园路21000号，邮编：44135
Phone: 216-433-6682 EMail: weddy@grc.nasa.gov
电话：216-433-6682电子邮件：weddy@grc.nasa.gov
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。