Internet Engineering Task Force (IETF) A. Ramaiah
Request for Comments: 5961 Cisco
Category: Standards Track R. Stewart
ISSN: 2070-1721 Huawei
M. Dalal
Cisco
August 2010
Internet Engineering Task Force (IETF) A. Ramaiah
Request for Comments: 5961 Cisco
Category: Standards Track R. Stewart
ISSN: 2070-1721 Huawei
M. Dalal
Cisco
August 2010
Improving TCP's Robustness to Blind In-Window Attacks
提高TCP对窗口盲攻击的鲁棒性
Abstract
摘要
TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks.
TCP历来被认为是针对伪造的非路径数据包注入攻击的保护，因为很难猜测4元组（源和目标IP地址以及源和目标端口）与32位序列号的组合。不断增加的窗口大小和使用长期连接的应用程序（例如，H-323或边界网关协议（BGP）[RFC4271]）使得现代TCP实现更容易受到这些类型的欺骗数据包注入攻击。
Many of these long-term TCP applications tend to have predictable IP addresses and ports that makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in RFC 793) to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack.
许多长期TCP应用程序往往具有可预测的IP地址和端口，这使得猜测4元组（4元组与RFC 793中提到的套接字对相同）变得容易得多。正确猜测4元组后，攻击者可以通过系统地猜测当前接收窗口中伪造段的序列号，将带有RST位集、SYN位集或数据的TCP段注入TCP连接。这可能会导致连接中止或导致数据损坏。本文档对TCP处理入站段的方式进行了一些小的修改，以减少成功攻击的机会。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5961.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5961.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicability Statement ....................................3
1.2. Basic Attack Methodology ...................................4
1.3. Attack probabilities .......................................5
2. Terminology .....................................................7
3. Blind Reset Attack Using the RST Bit ............................7
3.1. Description of the Attack ..................................7
3.2. Mitigation .................................................7
4. Blind Reset Attack Using the SYN Bit ............................9
4.1. Description of the Attack ..................................9
4.2. Mitigation .................................................9
5. Blind Data Injection Attack ....................................10
5.1. Description of the Attack .................................10
5.2. Mitigation ................................................11
6. Suggested Mitigation Strengths .................................12
7. ACK Throttling .................................................12
8. Backward Compatibility and Other Considerations ................13
9. Middlebox Considerations .......................................14
9.1. Middlebox That Resend RSTs ................................14
9.2. Middleboxes That Advance Sequence Numbers .................15
9.3. Middleboxes That Drop the Challenge ACK ...................15
10. Security Considerations .......................................16
11. Contributors ..................................................17
12. Acknowledgments ...............................................17
13. References ....................................................17
13.1. Normative References .....................................17
13.2. Informative References ...................................17
1. Introduction ....................................................3
1.1. Applicability Statement ....................................3
1.2. Basic Attack Methodology ...................................4
1.3. Attack probabilities .......................................5
2. Terminology .....................................................7
3. Blind Reset Attack Using the RST Bit ............................7
3.1. Description of the Attack ..................................7
3.2. Mitigation .................................................7
4. Blind Reset Attack Using the SYN Bit ............................9
4.1. Description of the Attack ..................................9
4.2. Mitigation .................................................9
5. Blind Data Injection Attack ....................................10
5.1. Description of the Attack .................................10
5.2. Mitigation ................................................11
6. Suggested Mitigation Strengths .................................12
7. ACK Throttling .................................................12
8. Backward Compatibility and Other Considerations ................13
9. Middlebox Considerations .......................................14
9.1. Middlebox That Resend RSTs ................................14
9.2. Middleboxes That Advance Sequence Numbers .................15
9.3. Middleboxes That Drop the Challenge ACK ...................15
10. Security Considerations .......................................16
11. Contributors ..................................................17
12. Acknowledgments ...............................................17
13. References ....................................................17
13.1. Normative References .....................................17
13.2. Informative References ...................................17
TCP [RFC0793] is widely deployed and the most common reliable end-to-end transport protocol used for data communication in today's Internet. Yet, when it was standardized over 20 years ago, the Internet was a different place, lacking many of the threats that are now common. The off-path TCP spoofing attacks, which are seen in the Internet today, fall into this category.
TCP[RFC0793]被广泛部署，是当今互联网上用于数据通信的最常见的可靠端到端传输协议。然而，当互联网在20多年前被标准化时，它是一个不同的地方，缺少许多现在常见的威胁。如今在互联网上出现的非路径TCP欺骗攻击属于这一类。
In a TCP spoofing attack, an off-path attacker crafts TCP packets by forging the IP source and destination addresses as well as the source and destination ports (referred to as a 4-tuple value in this document). The targeted TCP endpoint will then associate such a packet with an existing TCP connection. It needs to be noted that, guessing this 4-tuple value is not always easy for an attacker. But there are some applications (e.g., BGP [RFC4271]) that have a tendency to use the same set(s) of ports on either endpoint, making the odds of correctly guessing the 4-tuple value much easier. When an attacker is successful in guessing the 4-tuple value, one of three types of injection attacks may be waged against a long-lived connection. RST - Where an attacker injects a RST segment hoping to cause the connection to be torn down. "RST segment" here refers to a TCP segment with the RST bit set. SYN - Where an attacker injects a SYN hoping to cause the receiver to believe the peer has restarted and therefore tear down the connection state. "SYN segment" here refers to a TCP segment with SYN bit set. DATA - Where an attacker tries to inject a DATA segment to corrupt the contents of the transmission. "DATA segment" here refers to any TCP segment containing data.
在TCP欺骗攻击中，非路径攻击者通过伪造IP源和目标地址以及源和目标端口（在本文档中称为4元组值）来伪造TCP数据包。然后，目标TCP端点将此类数据包与现有TCP连接相关联。需要注意的是，猜测这个4元组值对于攻击者来说并不总是容易的。但也有一些应用程序（例如BGP[RFC4271]）倾向于在任一端点上使用相同的端口集，这使得正确猜测4元组值的几率大大降低。当攻击者成功猜测4元组值时，可能会对长寿命连接发起三种类型的注入攻击之一。RST-攻击者注入RST段，希望导致连接中断。这里的“RST段”是指设置了RST位的TCP段。SYN—攻击者注入SYN，希望使接收方相信对等方已重新启动，从而中断连接状态。这里的“SYN段”是指设置了SYN位的TCP段。数据-攻击者试图注入数据段以破坏传输内容。这里的“数据段”是指任何包含数据的TCP段。
This document talks about some known in-window attacks and suitable defenses against these. The mitigations suggested in this document SHOULD be implemented in devices that regularly need to maintain TCP connections of the kind most vulnerable to the attacks described in this document. Examples of such TCP connections are the ones that tend to be long-lived and where the connection endpoints can be determined, in cases where no auxiliary anti-spoofing protection mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations MAY be implemented in other cases.
本文档讨论一些已知的窗口内攻击以及针对这些攻击的适当防御。本文档中建议的缓解措施应在定期需要维护最容易受到本文档中所述攻击的TCP连接的设备中实施。此类TCP连接的示例往往是长寿命的，并且在无法部署TCP MD5[RFC2385]等辅助反欺骗保护机制的情况下，可以确定连接端点。这些缓解措施可在其他情况下实施。
Focusing upon the RST attack, we examine this attack in more detail to get an overview as to how it works and how this document addresses the issue. For this attack, the goal is for the attacker to cause one of the two endpoints of the connection to incorrectly tear down the connection state, effectively aborting the connection. One of the important things to note is that for the attack to succeed the RST needs to be in the valid receive window. It also needs to be emphasized that the receive window is independent of the current congestion window of the TCP connection. The attacker would try to forge many RST segments to try to cover the space of possible windows by putting out a packet in each potential window. To do this, the attacker needs to have or guess several pieces of information namely:
以RST攻击为重点，我们将更详细地检查此攻击，以了解其工作原理以及本文档如何解决此问题。对于此攻击，攻击者的目标是导致连接的两个端点之一错误地中断连接状态，从而有效地中止连接。需要注意的重要事项之一是，要使攻击成功，RST必须位于有效的接收窗口中。还需要强调的是，接收窗口独立于TCP连接的当前拥塞窗口。攻击者会试图伪造多个RST段，通过在每个潜在窗口中放入数据包来覆盖可能窗口的空间。为此，攻击者需要获得或猜测多条信息，即：
1) The 4-tuple value containing the IP address and TCP port number of both ends of the connection. For one side (usually the server), guessing the port number is a trivial exercise. The client side may or may not be easy for an attacker to guess depending on a number of factors, most notably the operating system and application involved.
1) 包含连接两端的IP地址和TCP端口号的4元组值。对于一方（通常是服务器），猜测端口号是一个简单的练习。客户端可能很容易被攻击者猜到，也可能不容易被攻击者猜到，这取决于许多因素，尤其是所涉及的操作系统和应用程序。
2) A sequence number that will be used in the RST. This sequence number will be a starting point for a series of guesses to attempt to present a RST segment to a connection endpoint that would be acceptable to it. Any random value may be used to guess the starting sequence number.
2) 将在RST中使用的序列号。该序列号将是一系列猜测的起点，以尝试向其可接受的连接端点呈现RST段。任何随机值都可用于猜测起始序列号。
3) The window size that the two endpoints are using. This value does NOT have to be the exact window size since a smaller value used in lieu of the correct one will just cause the attacker to generate more segments before succeeding in his mischief. Most modern operating systems have a default window size that usually is applied to most connections. Some applications however may change the window size to better suit the needs of the application. So often times the attacker, with a fair degree of certainty (knowing the application that is under attack), can come up with a very close approximation as to the actual window size in use on the connection.
3) 两个端点正在使用的窗口大小。此值不必是精确的窗口大小，因为使用较小的值代替正确的值只会导致攻击者在成功实施恶意攻击之前生成更多的段。大多数现代操作系统都有一个默认窗口大小，通常应用于大多数连接。但是，有些应用程序可能会更改窗口大小以更好地满足应用程序的需要。通常情况下，攻击者在一定程度上（知道受到攻击的应用程序）能够非常接近连接上使用的实际窗口大小。
After assembling the above set of information, the attacker begins sending spoofed TCP segments with the RST bit set and a guessed TCP sequence number. Each time a new RST segment is sent, the sequence number guess is incremented by the window size. The feasibility of this methodology (without mitigations) was first shown in [SITW]. This is because [RFC0793] specifies that any RST within the current window is acceptable. Also, [RFC4953] talks about the probability of a successful attack with varying window sizes and bandwidth.
组装上述信息集后，攻击者开始发送带有RST位集和猜测的TCP序列号的伪造TCP段。每次发送一个新的RST段时，序列号猜测值将按窗口大小递增。该方法的可行性（无缓解措施）首次在[SITW]中展示。这是因为[RFC0793]指定当前窗口中的任何RST都是可接受的。此外，[RFC4953]还讨论了在不同窗口大小和带宽下成功攻击的概率。
A slight enhancement to TCP's segment processing rules can be made, which makes such an attack much more difficult to accomplish. If the receiver examines the incoming RST segment and validates that the sequence number exactly matches the sequence number that is next expected, then such an attack becomes much more difficult than outlined in [SITW] (i.e., the attacker would have to generate 1/2 the entire sequence space, on average). This document will discuss the exact details of what needs to be changed within TCP's segment processing rules to mitigate all three types of attacks (RST, SYN, and DATA).
可以对TCP的段处理规则稍加增强，这使得此类攻击更难完成。如果接收器检查传入的RST段并验证序列号与下一个预期的序列号完全匹配，则此类攻击将比[SITW]中所述的困难得多（即，攻击者将平均生成整个序列空间的1/2）。本文档将详细讨论TCP的段处理规则中需要更改哪些内容，以减轻所有三种类型的攻击（RST、SYN和数据）。
Every application has control of a number of factors that drastically affect the probability of a successful spoofing attack. These factors include such things as:
每个应用程序都可以控制大量因素，这些因素会极大地影响成功欺骗攻击的概率。这些因素包括：
Window Size - Normally settable by the application but often times defaulting to 32,768 or 65,535 depending upon the operating system (see Figure 6 of [Medina05]).
窗口大小-通常可由应用程序设置，但根据操作系统的不同，通常默认为32768或65535（参见[Medina05]的图6）。
Server Port number - This value is normally a fixed value so that a client will know where to connect to the peer. Thus, this value normally provides no additional protection.
服务器端口号-此值通常为固定值，以便客户端知道在何处连接到对等方。因此，该值通常不提供额外的保护。
Client Port number - This value may be a random ephemeral value, if so, this makes a spoofing attack more difficult. There are some clients, however, that for whatever reason either pick a fixed client port or have a very guessable one (due to the range of ephemeral ports available with their operating system or other application considerations) for such applications a spoofing attack becomes less difficult.
客户端端口号-此值可能是随机的临时值，如果是，这会使欺骗攻击更加困难。但是，有些客户机出于任何原因，为此类应用程序选择固定客户机端口或使用非常容易猜测的端口（由于其操作系统或其他应用程序考虑的临时端口范围），欺骗攻击变得不那么困难。
For the purposes of the rest of this discussion we will assume that the attacker knows the 4-tuple values. This assumption will help us focus on the effects of the window size versus the number of TCP packets an attacker must generate. This assumption will rarely be true in the real Internet since at least the client port number will provide us with some amount of randomness (depending on the operating system).
在本讨论的其余部分中，我们将假设攻击者知道4元组值。这个假设将帮助我们关注窗口大小对攻击者必须生成的TCP数据包数量的影响。这种假设在真实的互联网中很少成立，因为至少客户端端口号会给我们提供一些随机性（取决于操作系统）。
To successfully inject a spoofed packet (RST, SYN, or DATA), in the
past, the entire sequence space (i.e., 2^32) was often considered
available to make such an attack unlikely. [SITW] demonstrated that
this assumption was incorrect and that instead of (1/2 * 2^32)
packets (assuming a random distribution), (1/2 * (2^32/window))
To successfully inject a spoofed packet (RST, SYN, or DATA), in the
past, the entire sequence space (i.e., 2^32) was often considered
available to make such an attack unlikely. [SITW] demonstrated that
this assumption was incorrect and that instead of (1/2 * 2^32)
packets (assuming a random distribution), (1/2 * (2^32/window))
packets are required. In other words, the mean number of tries needed to inject a RST segment is (2^31/window) rather than the 2^31 assumed before.
数据包是必需的。换句话说，注入RST段所需的平均尝试次数为（2^31/窗口），而不是之前假设的2^31。
Substituting numbers into this formula, we see that for a window size of 32,768, an average of 65,536 packets would need to be transmitted in order to "spoof" a TCP segment that would be acceptable to a TCP receiver. A window size of 65,535 reduces this even further to 32,768 packets. At today's access bandwidths, an attack of that size is feasible.
将数字代入这个公式，我们可以看到，对于32768的窗口大小，平均需要传输65536个数据包，以便“欺骗”TCP接收器可以接受的TCP段。窗口大小为65535的数据包进一步减少到32768个。在今天的访问带宽上，这种规模的攻击是可行的。
With rises in bandwidth to both the home and office, it can only be expected that the values for default window sizes will continue to rise in order to better take advantage of the newly available bandwidth. It also needs to be noted that this attack can be performed in a distributed fashion in order potentially gain access to more bandwidth.
随着家庭和办公室带宽的增加，只能预期默认窗口大小的值将继续增加，以便更好地利用新的可用带宽。还需要注意的是，这种攻击可以以分布式方式执行，以便潜在地获得对更多带宽的访问。
As we can see from the above discussion this weakness lowers the bar quite considerably for likely attacks. But there is one additional dependency that is the duration of the TCP connection. A TCP connection that lasts only a few brief packets, as often is the case for web traffic, would not be subject to such an attack since the connection may not be established long enough for an attacker to generate enough traffic. However, there is a set of applications, such as BGP [RFC4271], that is judged to be potentially most affected by this vulnerability. BGP relies on a persistent TCP session between BGP peers. Resetting the connection can result in term-medium unavailability due to the need to rebuild routing tables and route flapping; see [NISCC] for further details.
从上面的讨论中我们可以看出，这种弱点大大降低了可能发生攻击的门槛。但是还有一个附加的依赖项，即TCP连接的持续时间。与web流量的情况一样，只持续几个短数据包的TCP连接不会受到此类攻击，因为该连接的建立时间可能不足以让攻击者产生足够的流量。但是，有一组应用程序（如BGP[RFC4271]）被认为受此漏洞影响最大。BGP依赖于BGP对等方之间的持久TCP会话。由于需要重建路由表和路由抖动，重置连接可能导致中期不可用；有关更多详细信息，请参见[NISCC]。
For applications that can use the TCP MD5 option [RFC2385], such as BGP, that option makes the attacks described in this specification effectively impossible. However, some applications or implementations may find that option expensive to implement.
对于可以使用TCP MD5选项[RFC2385]的应用程序，如BGP，该选项使本规范中描述的攻击实际上不可能发生。但是，一些应用程序或实现可能会发现实现该选项的成本很高。
There are alternative protections against the threats that this document addresses. For further details regarding the attacks and the existing techniques, please refer to [RFC4953]. It also needs to be emphasized that, as suggested in [TSVWG-PORT] and [RFC1948], port randomization and initial sequence number (ISN) randomization would help improve the robustness of the TCP connection against off-path attacks.
对于本文档所述的威胁，还有其他保护措施。有关攻击和现有技术的更多详细信息，请参阅[RFC4953]。还需要强调的是，正如[TSVWG-PORT]和[RFC1948]中所建议的那样，端口随机化和初始序列号（ISN）随机化将有助于提高TCP连接对非路径攻击的鲁棒性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. TCP terminology should be interpreted as described in [RFC0793].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。TCP术语应按照[RFC0793]中所述进行解释。
As described in the introduction, it is possible for an attacker to generate a RST segment that would be acceptable to a TCP receiver by guessing in-window sequence numbers. In particular [RFC0793], page 37, states the following:
如简介中所述，攻击者可以通过猜测窗口序列号生成TCP接收器可以接受的RST段。特别是[RFC0793]，第37页，规定如下：
In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN.
在除SYN-SENT之外的所有状态下，通过检查其序列字段[序列号]来验证所有重置（RST）段。如果重置的序列号在窗口中，则重置有效。在SYN-SENT状态（响应初始SYN接收的RST）下，如果ACK字段确认SYN，则RST是可接受的。
[RFC0793] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows:
[RFC0793]当前需要在同步状态下处理具有RST位的段，如下所示：
1) If the RST bit is set and the sequence number is outside the current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ RCV.WND), silently drop the segment.
1) 如果设置了RST位且序列号在当前接收窗口之外（SEG.SEQ<=RCV.NXT | | SEG.SEQ>RCV.NXT+RCV.WND），则自动删除该段。
2) If the RST bit is set and the sequence number is acceptable, i.e., (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), then reset the connection.
2) 如果设置了RST位且序列号可接受，即（RCV.NXT<=SEG.SEQ<RCV.NXT+RCV.WND），则重置连接。
Instead, implementations SHOULD implement the following steps in place of those specified in [RFC0793] (as listed above).
相反，实施应实施以下步骤，以代替[RFC0793]（如上所列）中规定的步骤。
1) If the RST bit is set and the sequence number is outside the current receive window, silently drop the segment.
1) 如果设置了RST位且序列号在当前接收窗口之外，则静默删除该段。
2) If the RST bit is set and the sequence number exactly matches the next expected sequence number (RCV.NXT), then TCP MUST reset the connection.
2) 如果设置了RST位，并且序列号与下一个预期序列号（RCV.NXT）完全匹配，则TCP必须重置连接。
3) If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the current receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST send an acknowledgment (challenge ACK):
3) 如果设置了RST位且序列号与下一个预期序列值不完全匹配，但在当前接收窗口内（RCV.NXT<SEG.SEQ<RCV.NXT+RCV.WND），TCP必须发送确认（质询确认）：
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the challenge ACK, TCP MUST drop the unacceptable segment and stop processing the incoming packet further. Further segments destined to this connection will be processed as normal.
发送质询ACK后，TCP必须丢弃不可接受的段并停止进一步处理传入的数据包。发送到此连接的其他段将正常处理。
The modified RST segment processing would thus become:
因此，修改后的RST段处理将变为：
In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence number exactly matches the next expected sequence number. If the RST arrives and its sequence number field does NOT match the next expected sequence number but is within the window, then the receiver should generate an ACK. In all other cases, where the SEQ-field does not match and is outside the window, the receiver MUST silently discard the segment.
在除SYN-SENT之外的所有状态下，通过检查其序列字段[序列号]来验证所有重置（RST）段。如果重置的序列号与下一个预期序列号完全匹配，则重置有效。如果RST到达且其序列号字段与下一个预期序列号不匹配，但在窗口内，则接收器应生成ACK。在所有其他情况下，如果SEQ字段不匹配且在窗口之外，则接收器必须默默地丢弃该段。
In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN. In all other cases the receiver MUST silently discard the segment.
在SYN-SENT状态（响应初始SYN接收的RST）下，如果ACK字段确认SYN，则RST是可接受的。在所有其他情况下，接收器必须无声地丢弃该段。
With the above slight change to the TCP state machine, it becomes much harder for an attacker to generate an acceptable reset segment.
通过对TCP状态机的上述细微更改，攻击者更难生成可接受的重置段。
In cases where the remote peer did generate a RST, but it fails to meet the above criteria (the RST sequence number was within the window but NOT the exact expected sequence number), when the challenge ACK is sent back, it will no longer have the transmission control block (TCB) related to this connection and hence as per [RFC0793], the remote peer will send a second RST back. The sequence number of the second RST is derived from the acknowledgment number of the incoming ACK. This second RST, if it reaches the sender, will cause the connection to be aborted since the sequence number would now be an exact match.
如果远程对等方确实生成了RST，但未能满足上述标准（RST序列号在窗口内，但不是准确的预期序列号），当质询ACK发送回时，它将不再具有与此连接相关的传输控制块（TCB），因此符合[RFC0793]，远程对等方将发送第二个RST。第二个RST的序列号来自传入ACK的确认号。如果第二个RST到达发送方，将导致连接中止，因为序列号现在将完全匹配。
A valid RST received out of order would still generate a challenge ACK in response. If this RST happens to be a genuine one, the other end would send an RST with an exact sequence number match that would cause the connection to be dropped.
无序接收的有效RST仍将生成质询ACK作为响应。如果此RST恰好是真正的RST，则另一端将发送一个具有精确序列号匹配的RST，这将导致连接断开。
Note that the above mitigation may cause a non-amplification ACK exchange. This concern is discussed in Section 10.
请注意，上述缓解措施可能会导致非放大ACK交换。第10节讨论了这一问题。
The analysis of the reset attack using the RST bit highlights another possible avenue for a blind attacker using a similar set of sequence number guessing. Instead of using the RST bit, an attacker can use the SYN bit with the exact same semantics to tear down a connection.
使用RST位对重置攻击进行的分析突出了盲攻击者使用类似序列号猜测的另一种可能途径。攻击者可以使用语义完全相同的SYN位来断开连接，而不是使用RST位。
[RFC0793] currently requires handling of a segment with the SYN bit set in the synchronized state to be as follows:
[RFC0793]当前要求处理SYN位设置为同步状态的段，如下所示：
1) If the SYN bit is set and the sequence number is outside the expected window, send an ACK back to the sender.
1) 如果设置了SYN位且序列号超出预期窗口，则向发送方发送ACK。
2) If the SYN bit is set and the sequence number is acceptable, i.e., (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), then send a RST segment to the sender.
2) 如果设置了SYN位且序列号是可接受的，即（RCV.NXT<=SEG.SEQ<RCV.NXT+RCV.WND），则向发送方发送RST段。
Instead, the handling of the SYN in the synchronized state SHOULD be performed as follows:
相反，应按如下方式处理处于同步状态的SYN：
1) If the SYN bit is set, irrespective of the sequence number, TCP MUST send an ACK (also referred to as challenge ACK) to the remote peer:
1) 如果设置了SYN位，则无论序列号如何，TCP都必须向远程对等方发送ACK（也称为质询ACK）：
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, TCP MUST drop the unacceptable segment and stop processing further.
发送确认后，TCP必须删除不可接受的段并停止进一步处理。
By sending an ACK, the remote peer is challenged to confirm the loss of the previous connection and the request to start a new connection. A legitimate peer, after restart, would not have a TCB in the synchronized state. Thus, when the ACK arrives, the peer should send a RST segment back with the sequence number derived from the ACK field that caused the RST.
通过发送ACK，远程对等方被质询以确认先前连接的丢失以及启动新连接的请求。重新启动后，合法对等方的TCB不会处于已同步状态。因此，当ACK到达时，对等方应使用从导致RST的ACK字段派生的序列号发送一个RST段。
This RST will confirm that the remote peer has indeed closed the previous connection. Upon receipt of a valid RST, the local TCP endpoint MUST terminate its connection. The local TCP endpoint should then rely on SYN retransmission from the remote end to re-establish the connection.
此RST将确认远程对等方确实已关闭以前的连接。收到有效RST后，本地TCP端点必须终止其连接。然后，本地TCP端点应该依赖远程端的SYN重新传输来重新建立连接。
A spoofed SYN, on the other hand, will then have generated an additional ACK that the peer will discard as a duplicate ACK and will not affect the established connection.
另一方面，伪造的SYN将生成一个额外的ACK，对等方将丢弃该ACK作为重复ACK，并且不会影响已建立的连接。
Note that this mitigation does leave one corner case un-handled, which will prevent the reset of a connection when it should be reset (i.e., it is a non-spoofed SYN wherein a peer really did restart). This problem occurs when the restarting host chooses the exact same IP address and port number that it was using prior to its restart. By chance, the restarted host must also choose an initial sequence number of exactly (RCV.NXT - 1) of the remote peer that is still in the established state. Such a case would cause the receiver to generate a "challenge" ACK as described above. But since the ACK would be within the outgoing connections window, the inbound ACK would be acceptable, and the sender of the SYN will do nothing with the response ACK. This sequence will continue as the SYN sender continually times out and retransmits the SYN until such time as the connection attempt fails.
请注意，这种缓解措施确实使一个角落的情况未得到处理，这将防止在应该重置连接时重置连接（即，它是一个非欺骗SYN，其中对等方确实重新启动）。当重新启动的主机选择与重新启动前使用的完全相同的IP地址和端口号时，就会出现此问题。很可能，重新启动的主机还必须选择仍处于已建立状态的远程对等机的初始序列号（RCV.NXT-1）。这种情况将导致接收机产生如上所述的“质询”ACK。但是，由于ACK将在outgoing connections（传出连接）窗口内，因此入站ACK是可接受的，并且SYN的发送方不会对响应ACK进行任何处理。当SYN发送方持续超时并重新传输SYN时，此序列将继续，直到连接尝试失败为止。
This corner case is a result of the [RFC0793] specification and is not introduced by these new requirements.
此角盒是[RFC0793]规范的结果，不在这些新要求中引入。
Note that the above mitigation may cause a non-amplification ACK exchange. This concern is discussed in Section 10.
请注意，上述缓解措施可能会导致非放大ACK交换。第10节讨论了这一问题。
A third type of attack is also highlighted by both the RST and SYN attacks. It is also possible to inject data into a TCP connection by simply guessing a sequence number within the current receive window of the victim. The ACK value of any data segment is considered valid as long as it does not acknowledge data ahead of the next segment to send. In other words, an ACK value is acceptable if it is ((SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). The (2^31 - 1) in the above inequality takes into account the fact that comparisons on TCP sequence and acknowledgment numbers is done using the modulo 32-bit arithmetic to accommodate the number wraparound. This means that an attacker has to guess two ACK values with every guessed sequence number so that the chances of successfully injecting data into a connection are 1 in ( 1/2 (2^32 / RCV.WND) * 2). Thus, the mean number of tries needed to inject data successfully is 1/2 (2*2^32/RWND) = 2^32/RCV.WND.
第三种类型的攻击也通过RST和SYN攻击突出显示。也可以通过猜测受害者当前接收窗口内的序列号将数据注入TCP连接。只要在下一个要发送的数据段之前没有确认数据，任何数据段的ACK值都被视为有效。换句话说，如果ACK值是（（SND.UNA-（2^31-1））<=SEG.ACK<=SND.NXT），则ACK值是可接受的。上述不等式中的（2^31-1）考虑到了这样一个事实，即TCP序列和确认号的比较是使用模32位算法完成的，以适应环绕的数字。这意味着攻击者必须对每个猜测的序列号猜测两个ACK值，以便将数据成功注入连接的几率为1 in（1/2（2^32/RCV.WND）*2）。因此，成功注入数据所需的平均尝试次数为1/2（2*2^32/RWND）=2^32/RCV.WND。
When an attacker successfully injects data into a connection, the data will sit in the receiver's re-assembly queue until the peer sends enough data to bridge the gap between the RCV.NXT value and the injected data. At that point, one of two things will occur:
当攻击者成功地将数据注入连接时，数据将位于接收方的重新组装队列中，直到对等方发送足够的数据以弥合RCV.NXT值和注入数据之间的差距。在这一点上，将发生以下两种情况之一：
1) A packet war will ensue with the receiver indicating that it has received data up until RCV.NXT (which includes the attacker's data) and the sender sending an ACK with an acknowledgment number less than RCV.NXT.
1) 数据包战争将接踵而至，接收方指示其在RCV.NXT之前已收到数据（包括攻击者的数据），而发送方发送确认号小于RCV.NXT的ACK。
2) The sender will send enough data to the peer that will move RCV.NXT even further along past the injected data.
2) 发送方将向对等方发送足够的数据，该对等方将沿着注入的数据进一步移动RCV.NXT。
Depending upon the TCP implementation in question and the TCP traffic characteristics at that time, data corruption may result. In case (a), the connection will eventually be reset by one of the sides unless the sender produces more data that will transform the ACK war into case (b). The reset will usually occur via User Time Out (UTO) (see section 4.2.3.5 of [RFC1122]).
根据所讨论的TCP实现和当时的TCP流量特征，可能会导致数据损坏。在情况（a）中，连接最终将由其中一方重置，除非发送方产生更多的数据将ACK war转换为情况（b）。重置通常通过用户超时（UTO）进行（见[RFC1122]第4.2.3.5节）。
Note that the protections illustrated in this section neither cause an ACK war nor prevent one from occurring if data is actually injected into a connection. The ACK war is a product of the attack itself and cannot be prevented (other than by preventing the data from being injected).
请注意，如果数据实际注入到连接中，本节中说明的保护既不会导致ACK war，也不会阻止ACK war的发生。ACK war是攻击本身的产物，无法防止（防止数据注入除外）。
All TCP stacks MAY implement the following mitigation. TCP stacks that implement this mitigation MUST add an additional input check to any incoming segment. The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
所有TCP堆栈都可以实现以下缓解措施。实现此缓解的TCP堆栈必须向任何传入段添加额外的输入检查。只有当ACK值在（（SND.UNA-MAX.SND.WND）<=SEG.ACK<=SND.NXT）范围内时，才认为ACK值是可接受的。必须丢弃所有ACK值不满足上述条件的传入段，并发回ACK。需要注意的是，第72页（第五次检查）上的RFC 793说：“如果ACK是重复的（SEG.ACK<SND.UNA），则可以忽略它。如果ACK确认尚未发送的内容（SEG.ACK>SND.NXT），则发送ACK，删除该段并返回”。上面的“忽略”表示继续处理传入数据段，这意味着ACK值被视为可接受。这种缓解措施使得ACK检查更加严格，因为任何ACK<SND.UNA都不会被接受，而只有范围（（SND.UNA-MAX.SND.WND）<=SEG.ACK<=SND.NXT）内的ACK才能通过。
A new state variable MAX.SND.WND is defined as the largest window that the local sender has ever received from its peer. This window may be scaled to a value larger than 65,535 bytes ([RFC1323]). This small check will reduce the vulnerability to an attacker guessing a
新的状态变量MAX.SND.WND被定义为本地发送方从其对等方收到的最大窗口。此窗口可缩放为大于65535字节的值（[RFC1323]）。此小检查将减少攻击者猜测
valid sequence number, since, not only one must guess the in-window sequence number, but also guess a proper ACK value within a scoped range. This mitigation reduces, but does not eliminate, the ability to generate false segments. It does however reduce the probability that invalid data will be injected.
有效序列号，因为，不仅必须猜测窗口内序列号，还必须猜测范围内的正确ACK值。这种缓解措施会降低但不会消除生成错误片段的能力。但是，它确实降低了注入无效数据的可能性。
Implementations can also chose to hard code the MAX.SND.WND value to the maximum permissible window size, i.e., 65535 in the absence of window scaling. In the presence of the window scaling option, the value becomes (MAX.SND.WND << Snd.Wind.Scale).
实现还可以选择将MAX.SND.WND值硬编码为最大允许窗口大小，即在没有窗口缩放的情况下为65535。存在窗口缩放选项时，该值变为（MAX.SND.WND<<SND.Wind.Scale）。
This mitigation also helps in improving robustness on accepting spoofed FIN segments (FIN attacks). Among other things, this mitigation requires that the attacker also needs to get the acknowledgment number to fall in the range mentioned above in order to successfully spoof a FIN segment leading to the closure of the connection. Thus, this mitigation greatly improves the robustness to spoofed FIN segments.
这种缓解措施还有助于提高接受欺骗鳍段（鳍攻击）的鲁棒性。除其他外，这种缓解措施要求攻击者还需要将确认号设置在上述范围内，以便成功欺骗导致连接关闭的FIN段。因此，这种缓解措施大大提高了对欺骗鳍段的鲁棒性。
Note that the above mitigation may cause a non-amplification ACK exchange. This concern is discussed in Section 10.
请注意，上述缓解措施可能会导致非放大ACK交换。第10节讨论了这一问题。
As described in the above sections, recommendation levels for RST, SYN, and DATA are tagged as SHOULD, SHOULD, and MAY, respectively. The reason that DATA mitigation is tagged as MAY, even though it increased the TCP robustness in general is because, the DATA injection is perceived to be more difficult (twice as unlikely) when compared to RST and SYN counterparts. However, it needs to be noted that all the suggested mitigations improve TCP's robustness in general and hence the choice of implementing some or all mitigations recommended in the document is purely left to the implementer.
如以上章节所述，RST、SYN和数据的建议级别分别标记为宜、宜和可。数据缓解被标记为“可能”的原因是，与RST和SYN对应项相比，数据注入被认为更加困难（可能性是前者的两倍），尽管它通常提高了TCP的健壮性。但是，需要注意的是，所有建议的缓解措施总体上提高了TCP的健壮性，因此，实现文档中建议的部分或所有缓解措施的选择完全由实施者决定。
In order to alleviate multiple RSTs/SYNs from triggering multiple challenge ACKs, an ACK throttling mechanism is suggested as follows:
为了避免多个RST/SYN触发多个质询ACK，建议采用如下ACK节流机制：
1) The system administrator can configure the number of challenge ACKs that can be sent out in a given interval. For example, in any 5 second window, no more than 10 challenge ACKs should be sent.
1) 系统管理员可以配置在给定间隔内可以发送的质询确认数。例如，在任何5秒钟的窗口中，发送的质询确认不应超过10次。
2) The values for both the time and number of ACKs SHOULD be tunable by the system administrator to accommodate different perceived levels of threat and/or system resources.
2) 系统管理员应可调整ACK的时间和数量值，以适应不同级别的威胁和/或系统资源。
It should be noted that these numbers are empirical in nature and have been obtained from the RST throttling mechanisms existing in some implementations. Also, note that no timer is needed to implement the above mechanism, instead a timestamp and a counter can be used.
应该注意的是，这些数字本质上是经验性的，并且是从一些实现中存在的RST节流机制中获得的。另外，请注意，实现上述机制不需要计时器，而是可以使用时间戳和计数器。
An implementation SHOULD include an ACK throttling mechanism to be conservative. While we have not encountered a case where the lack of ACK throttling can be exploited, as a fail-safe mechanism we recommend its use. An implementation may take an excessive number of invocations of the throttling mechanism as an indication that network conditions are unusual or hostile.
一个实现应该包括一个保守的ACK限制机制。虽然我们没有遇到可以利用ACK限制不足的情况，但作为一种故障安全机制，我们建议使用它。一个实现可能会将过多的节流机制调用次数视为网络状况异常或恶劣的指示。
An administrator who is more concerned about protecting his bandwidth and CPU utilization may set smaller ACK throttling values whereas an administrator who is more interested in faster cleanup of stale connections (i.e., concerned about excess TCP state) may decide to set a higher value thus allowing more RST's to be processed in any given time period.
更关心保护带宽和CPU利用率的管理员可能会设置较小的ACK限制值，而更关心更快地清理陈旧连接（即，关心过多的TCP状态）的管理员则会设置较小的ACK限制值可决定设置更高的值，从而允许在任何给定时间段内处理更多RST。
The time limit SHOULD be tunable to help timeout brute force attacks faster than a potential legitimate flood of RSTs.
时间限制应该是可调的，以帮助暴力攻击比潜在的合法RST洪流更快超时。
All of the new required mitigation techniques in this document are totally compatible with existing ([RFC0793]) compliant TCP implementations as this document introduces no new assumptions or conditions.
由于本文件未引入任何新的假设或条件，因此本文件中要求的所有新缓解技术与现有（[RFC0793]）兼容的TCP实施完全兼容。
There is a corner scenario in the above mitigations that will require more than one round-trip time to successfully abort the connection as per the figure below. This scenario is similar to the one in which the original RST was lost in the network.
上述缓解措施中存在一个拐点场景，需要一个以上的往返时间才能成功中止连接，如下图所示。此场景类似于原始RST在网络中丢失的场景。
TCP A TCP B
1.a. ESTAB <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTAB
b. (delayed) ... <SEQ=400><ACK=101><CTL=ACK><DATA> <-- ESTAB
c. (in flight) ... <SEQ=500><ACK=101><CTL=RST> <-- CLOSED
2. ESTAB --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED
(ACK for 1.a)
... <SEQ=400><ACK=0><CTL=RST> <-- CLOSED
3. CHALLENGE --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED
(for 1.c)
... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE
4.a. ESTAB <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A
b. ESTAB --> <SEQ=101><ACK=500><CTL=ACK>
c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED
5. RESPONSE arrives at A, but dropped since its outside of window.
6. ESTAB <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A
7. CLOSED CLOSED
TCP A TCP B
1.a. ESTAB <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTAB
b. (delayed) ... <SEQ=400><ACK=101><CTL=ACK><DATA> <-- ESTAB
c. (in flight) ... <SEQ=500><ACK=101><CTL=RST> <-- CLOSED
2. ESTAB --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED
(ACK for 1.a)
... <SEQ=400><ACK=0><CTL=RST> <-- CLOSED
3. CHALLENGE --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED
(for 1.c)
... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE
4.a. ESTAB <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A
b. ESTAB --> <SEQ=101><ACK=500><CTL=ACK>
c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED
5. RESPONSE arrives at A, but dropped since its outside of window.
6. ESTAB <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A
7. CLOSED CLOSED
For the mitigation to be maximally effective against the vulnerabilities discussed in this document, both ends of the TCP connection need to have the fix. Although, having the mitigations at one end might prevent that end from being exposed to the attack, the connection is still vulnerable at the other end.
为了最大限度地缓解本文档中讨论的漏洞，TCP连接的两端都需要修复。尽管在一端使用缓解措施可能会防止该端受到攻击，但连接在另一端仍然容易受到攻击。
Consider a middlebox M-B tracking connections between two TCP end hosts E-A and E-C. If E-C sends a RST with a sequence number that is within the window but not an exact match to reset the connection and M-B does not have the fix recommended in this document, it may clear the connection and forward the RST to E-A saving an incorrect sequence number. If E-A does not have the fix, the connection would get cleared as required. However, if E-A does have the required fix, it will send a challenge ACK to E-C. M-B, being a middlebox, may intercept this ACK and resend the RST on behalf of E-C with the old sequence number. This RST will, again, not be acceptable and may trigger a challenge ACK.
考虑两个TCP端主机E-A和E-C之间的中间包M B跟踪连接；如果E-C发送一个RST，该序列号位于窗口内，但没有精确匹配以重置连接，并且M B没有该文档中推荐的修复，它可能会清除连接并将RST转发给E-A，从而保存错误的序列号。如果E-A没有修复程序，则会根据需要清除连接。但是，如果E-A确实具有所需的修复，它将向E-C发送质询应答。M-B作为中间盒，可以拦截该应答并代表E-C使用旧序列号重新发送RST。此RST同样不可接受，并可能触发质询确认。
The above situation may result in a RST/ACK war. However, we believe that if such a case exists in the Internet, the middlebox is generating packets a conformant TCP endpoint would not generate. [RFC0793] dictates that the sequence number of a RST has to be derived from the acknowledgment number of the incoming ACK segment. It is outside the scope of this document to suggest mitigations to the ill-behaved middleboxes.
上述情况可能导致RST/ACK战争。然而，我们相信，如果互联网上存在这种情况，那么中间盒正在生成一致的TCP端点不会生成的数据包。[RFC0793]规定RST的序列号必须来自传入ACK段的确认号。对行为不端的中间人提出缓解建议超出了本文件的范围。
Consider a similar scenario where the RST from M-B to E-A gets lost, E-A will continue to hold the connection and E-A might send an ACK an arbitrary time later after the connection state was destroyed at M-B. For this case, M-B will have to cache the RST for an arbitrary amount of time until it is confirmed that the connection has been cleared at E-A.
考虑类似的情况，从M到E的RST丢失，E-A将继续保持连接，并且E-A可能在连接状态在M—B被破坏后在任意时间发送ACK，对于这种情况，M-B必须将RST缓存任意时间，直到确认E-A已清除连接。
Some middleboxes may compute RST sequence numbers at the higher end of the acceptable window. The scenario is the same as the earlier case, but in this case instead of sending the cached RST, the middlebox (M-B) sends a RST that computes its sequence number as the sum of the acknowledgment field in the ACK and the window advertised by the ACK that was sent by E-A to challenge the RST as depicted below. The difference in the sequence numbers between step 1 and 2 below is due to data lost in the network.
一些中间盒可以在可接受窗口的高端计算RST序列号。该场景与前面的情况相同，但在这种情况下，中间盒（M-B）不发送缓存的RST，而是发送RST，该RST计算其序列号，作为ACK中的确认字段和由E-a发送的ACK播发的窗口的总和，以质询RST，如下所述。下面步骤1和步骤2之间的序列号差异是由于网络中的数据丢失造成的。
TCP A Middlebox
TCP中间包
1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED
1. 已建立<--<SEQ=500><ACK=100><CTL=RST><--CLOSED
2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
2. 已建立--><SEQ=100><ACK=300><WND=500><CTL=ACK>-->已关闭
3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
3. 已建立<--<SEQ=800><ACK=100><CTL=RST><--CLOSED
4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
4. 已建立--><SEQ=100><ACK=300><WND=500><CTL=ACK>-->已关闭
5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
5. 已建立<--<SEQ=800><ACK=100><CTL=RST><--CLOSED
Although the authors are not aware of an implementation that does the above, it could be mitigated by implementing the ACK throttling mechanism described earlier.
尽管作者不知道有一种实现可以实现上述功能，但可以通过实现前面描述的ACK限制机制来缓解这种情况。
It also needs to be noted that, some middleboxes (Firewalls/NATs) that don't have the fix recommended in the document, may drop the challenge ACK. This can happen because, the original RST segment that was in window had already cleared the flow state pertaining to the TCP connection in the middlebox. In such cases, the end hosts that have implemented the RST mitigation described in this document, will have the TCP connection left open. This is a corner case and can go away if the middlebox is conformant with the changes proposed in this document.
还需要注意的是，一些没有文档中建议的修复程序的中间盒（防火墙/NAT）可能会丢弃质询ACK。这可能是因为窗口中的原始RST段已经清除了与中间盒中TCP连接相关的流状态。在这种情况下，已实施本文档中描述的RST缓解的终端主机将保持TCP连接打开。这是一种极端情况，如果中间盒符合本文件中提出的更改，则可能会消失。
These changes to the TCP state machine do NOT protect an implementation from on-path attacks. It also needs to be emphasized that while mitigations within this document make it harder for off-path attackers to inject segments, it does NOT make it impossible. The only way to fully protect a TCP connection from both on- and off-path attacks is by using either IPsec Authentication Header (AH) [RFC4302] or IPsec Encapsulating Security Payload (ESP) [RFC4303].
对TCP状态机的这些更改不会保护实现免受路径攻击。还需要强调的是，虽然本文档中的缓解措施使非路径攻击者更难注入段，但这并不是不可能的。完全保护TCP连接不受路径上和路径外攻击的唯一方法是使用IPsec身份验证头（AH）[RFC4302]或IPsec封装安全负载（ESP）[RFC4303]。
Implementers also should be aware that the attacks detailed in this specification are not the only attacks available to an off-path attacker and that the counter measures described herein are not a comprehensive defense against such attacks.
实施者还应意识到，本规范中详述的攻击并不是路径外攻击者可以使用的唯一攻击，本文所述的应对措施并不是针对此类攻击的全面防御。
In particular, administrators should be aware that forged ICMP messages provide off-path attackers the opportunity to disrupt connections or degrade service. Such attacks may be subject to even less scrutiny than the TCP attacks addressed here, especially in stacks not tuned for hostile environments. It is important to note that some ICMP messages, validated or not, are key to the proper function of TCP. Those ICMP messages used to properly set the path maximum transmission unit are the most obvious example. There are a variety of ways to choose which, if any, ICMP messages to trust in the presence of off-path attackers and choosing between them depends on the assumptions and guarantees developers and administrators can make about their network. This specification does not attempt to do more than note this and related issues. Unless implementers address spoofed ICMP messages [RFC5927], the mitigations specified in this document may not provide the desired protection level.
特别是，管理员应该意识到伪造的ICMP消息为非路径攻击者提供了中断连接或降低服务质量的机会。这种攻击可能比这里讨论的TCP攻击受到更少的审查，特别是在不适合敌对环境的堆栈中。需要注意的是，一些ICMP消息，无论是否经过验证，都是TCP正常运行的关键。用于正确设置路径最大传输单位的ICMP消息是最明显的例子。有多种方法可以选择在存在非路径攻击者的情况下信任哪些ICMP消息（如果有的话），并根据开发人员和管理员对其网络的假设和保证来进行选择。本规范仅试图说明此问题和相关问题。除非实施者解决伪造ICMP消息[RFC5927]，否则本文件中规定的缓解措施可能无法提供所需的保护级别。
In any case, this RFC details only part of a complete strategy to prevent off-path attackers from disrupting services that use TCP. Administrators and implementers should consider the other attack vectors and determine appropriate mitigations in securing their systems.
在任何情况下，此RFC仅详细说明了防止非路径攻击者中断使用TCP的服务的完整策略的一部分。管理员和实现者应考虑其他攻击向量，并在确保系统的安全性方面确定适当的缓解措施。
Another notable consideration is that a reflector attack is possible with the required RST/SYN mitigation techniques. In this attack, an off-path attacker can cause a victim to send an ACK segment for each spoofed RST/SYN segment that lies within the current receive window of the victim. It should be noted, however, that this does not cause any amplification since the attacker must generate a segment for each one that the victim will generate.
另一个值得注意的问题是，使用所需的RST/SYN缓解技术，反射器攻击是可能的。在此攻击中，非路径攻击者可导致受害者为受害者当前接收窗口内的每个伪造RST/SYN段发送ACK段。但是，应该注意的是，这不会导致任何放大，因为攻击者必须为受害者将生成的每个片段生成一个片段。
Mitesh Dalal and Amol Khare of Cisco Systems came up with the solution for the RST/SYN attacks. Anantha Ramaiah and Randall Stewart of Cisco Systems discovered the data injection vulnerability and together with Patrick Mahan and Peter Lei of Cisco Systems found solutions for the same. Paul Goyette, Mark Baushke, Frank Kastenholz, Art Stine, and David Wang of Juniper Networks provided the insight that apart from RSTs, SYNs could also result in formidable attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of Wind River Systems, and Xiaodan Tang of QNX Software along with the folks above helped in ratifying and testing the interoperability of the suggested solutions.
Cisco Systems的Mitesh Dalal和Amol Khare提出了RST/SYN攻击的解决方案。Cisco Systems的Anantha Ramaiah和Randall Stewart发现了数据注入漏洞，并与Cisco Systems的Patrick Mahan和Peter Lei一起找到了解决方案。Juniper Networks的保罗·戈耶特（Paul Goyette）、马克·鲍什克（Mark Baushke）、弗兰克·卡斯滕霍尔茨（Frank Kastenholz）、阿特·斯汀（Art Stine）和大卫·王（David Wang）提供了这样的见解：除了RST，SYN还可能导致可怕的攻击。思科系统（Cisco Systems）的施瑞朗·贝奇（Shrirang Bage）、风河系统（Wind River Systems）的李青（Qing Li）和普里蒂·普里（Prety Puri）、QNX软件公司的唐晓丹（Xiao Dan Tang）以及上述人员帮助批准并测试了建议解决方案的互操作性。
Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong, Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra Murphy, Brian Carpenter, Cullen Jennings, and other members of the tcpm WG for suggestions and comments. ACK throttling was introduced to this document by combining the suggestions from the tcpm working group.
特别感谢Mark Allman、Ted Faber、Steve Bellovin、Vern Paxson、Allison Mankin、Sharad Ahlawat、Damir Rajnovic、John Wong、Joe Touch、Alfred Hoenes、Andre Oppermann、Fernando Gont、Sandra Murphy、Brian Carpenter、Cullen Jennings和tcpm工作组其他成员的建议和意见。本文件结合tcpm工作组的建议引入了ACK限制。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[Medina05] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM Computer Communication Review, 35(2), April 2005, <http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps>.
[Medina05]Medina，A.，Allman，M.，和S.Floyd，“测量互联网传输协议的演变”，ACM计算机通信评论，35（2），2005年4月<http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps>.
[NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - Vulnerability Issues in TCP".
[NISCC]NISCC，“NISCC漏洞咨询236929-TCP中的漏洞问题”。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，B.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]Touch，J.“保护TCP免受欺骗攻击”，RFC 4953，2007年7月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927]Gont，F.，“针对TCP的ICMP攻击”，RFC 5927，2010年7月。
[SITW] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, <http://cansecwest.com/csw04archive.html>.
[SITW]Watson，P.，“在窗口中滑动：TCP重置攻击”，在2004年CanSecWest上的演讲<http://cansecwest.com/csw04archive.html>.
[TSVWG-PORT] Larsen, M. and F. Gont, "Transport Protocol Port Randomization Recommendations", Work in Progress, August 2010.
[TSVWG-PORT]Larsen，M.和F.Gont，“运输协议端口随机化建议”，正在进行的工作，2010年8月。
Authors' Addresses
作者地址
Anantha Ramaiah Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道170号安娜塔·拉迈亚思科系统公司，邮编95134
Phone: +1 (408) 525-6486
EMail: ananth@cisco.com
Phone: +1 (408) 525-6486
EMail: ananth@cisco.com
Randall R. Stewart Huawei 148 Crystal Cove Ct Chapin, SC 29036 USA
Randall R.Stewart Huawei 148 Crystal Cove Ct Chapin，SC 29036美国
Phone: +1 (803) 345-0369
EMail: rstewart@huawei.com
Phone: +1 (803) 345-0369
EMail: rstewart@huawei.com
Mitesh Dalal Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道170号，邮编95134
Phone: +1 (408) 853-5257
EMail: mdalal@cisco.com
Phone: +1 (408) 853-5257
EMail: mdalal@cisco.com