Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 5927 UTN/FRH
Category: Informational July 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 5927 UTN/FRH
Category: Informational July 2010
ISSN: 2070-1721
ICMP Attacks against TCP
针对TCP的ICMP攻击
Abstract
摘要
This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues.
本文档讨论如何使用Internet控制消息协议（ICMP）对传输控制协议（TCP）执行各种攻击。此外，本文档描述了对TCP处理ICMP错误消息的一些广泛实施的修改，这些修改有助于缓解这些问题。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc5927.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5927.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5
2.1.1. ICMP for IP version 4 (ICMPv4) . . . . . . . . . . . . 5
2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6
2.2. Handling of ICMP Error Messages . . . . . . . . . . . . . 6
2.3. Handling of ICMP Error Messages in the Context of IPsec . 7
3. Constraints in the Possible Solutions . . . . . . . . . . . . 8
4. General Counter-Measures against ICMP Attacks . . . . . . . . 10
4.1. TCP Sequence Number Checking . . . . . . . . . . . . . . . 10
4.2. Port Randomization . . . . . . . . . . . . . . . . . . . . 11
4.3. Filtering ICMP Error Messages Based on the ICMP Payload . 11
5. Blind Connection-Reset Attack . . . . . . . . . . . . . . . . 12
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 13
6. Blind Throughput-Reduction Attack . . . . . . . . . . . . . . 16
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 16
7. Blind Performance-Degrading Attack . . . . . . . . . . . . . . 16
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 18
7.3. The Counter-Measure for the PMTUD Attack in Action . . . . 22
7.3.1. Normal Operation for Bulk Transfers . . . . . . . . . 22
7.3.2. Operation during Path-MTU Changes . . . . . . . . . . 24
7.3.3. Idle Connection Being Attacked . . . . . . . . . . . . 25
7.3.4. Active Connection Being Attacked after Discovery
of the Path-MTU . . . . . . . . . . . . . . . . . . . 26
7.3.5. TCP Peer Attacked when Sending Small Packets Just
after the Three-Way Handshake . . . . . . . . . . . . 26
7.4. Pseudo-Code for the Counter-Measure for the Blind
Performance-Degrading Attack . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Internet Control Message Protocol (ICMP) . . . . . . . 5
2.1.1. ICMP for IP version 4 (ICMPv4) . . . . . . . . . . . . 5
2.1.2. ICMP for IP version 6 (ICMPv6) . . . . . . . . . . . . 6
2.2. Handling of ICMP Error Messages . . . . . . . . . . . . . 6
2.3. Handling of ICMP Error Messages in the Context of IPsec . 7
3. Constraints in the Possible Solutions . . . . . . . . . . . . 8
4. General Counter-Measures against ICMP Attacks . . . . . . . . 10
4.1. TCP Sequence Number Checking . . . . . . . . . . . . . . . 10
4.2. Port Randomization . . . . . . . . . . . . . . . . . . . . 11
4.3. Filtering ICMP Error Messages Based on the ICMP Payload . 11
5. Blind Connection-Reset Attack . . . . . . . . . . . . . . . . 12
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 13
6. Blind Throughput-Reduction Attack . . . . . . . . . . . . . . 16
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 16
7. Blind Performance-Degrading Attack . . . . . . . . . . . . . . 16
7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Attack-Specific Counter-Measures . . . . . . . . . . . . . 18
7.3. The Counter-Measure for the PMTUD Attack in Action . . . . 22
7.3.1. Normal Operation for Bulk Transfers . . . . . . . . . 22
7.3.2. Operation during Path-MTU Changes . . . . . . . . . . 24
7.3.3. Idle Connection Being Attacked . . . . . . . . . . . . 25
7.3.4. Active Connection Being Attacked after Discovery
of the Path-MTU . . . . . . . . . . . . . . . . . . . 26
7.3.5. TCP Peer Attacked when Sending Small Packets Just
after the Three-Way Handshake . . . . . . . . . . . . 26
7.4. Pseudo-Code for the Counter-Measure for the Blind
Performance-Degrading Attack . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 33
ICMP [RFC0792] [RFC4443] is a fundamental part of the TCP/IP protocol suite, and is used mainly for reporting network error conditions. However, the current specifications do not recommend any kind of validation checks on the received ICMP error messages, thus allowing a variety of attacks against TCP [RFC0793] by means of ICMP, which include blind connection-reset, blind throughput-reduction, and blind performance-degrading attacks. All of these attacks can be performed even when the attacker is off-path, without the need to sniff the packets that correspond to the attacked TCP connection.
ICMP[RFC0792][RFC4443]是TCP/IP协议套件的基本组成部分，主要用于报告网络错误情况。然而，当前规范不建议对接收到的ICMP错误消息进行任何类型的验证检查，因此允许通过ICMP对TCP[RFC0793]进行各种攻击，包括盲连接重置、盲吞吐量降低和盲性能降低攻击。即使攻击者不在路径上，也可以执行所有这些攻击，而无需嗅探与受攻击的TCP连接对应的数据包。
While the possible security implications of ICMP have been known in the research community for a long time, there has never been an official proposal on how to deal with these vulnerabilities. In 2005, a disclosure process was carried out by the UK's National Infrastructure Security Co-ordination Centre (NISCC) (now CPNI, Centre for the Protection of National Infrastructure), with the collaboration of other computer emergency response teams. A large number of implementations were found vulnerable to either all or a subset of the attacks discussed in this document [NISCC][US-CERT]. The affected systems ranged from TCP/IP implementations meant for desktop computers, to TCP/IP implementations meant for core Internet routers.
虽然ICMP可能对安全造成的影响在研究界已经知道很长时间了，但从来没有关于如何处理这些漏洞的正式提案。2005年，英国国家基础设施安全协调中心（NISCC）（现为CPNI，国家基础设施保护中心）与其他计算机应急响应团队合作，实施了一项披露程序。发现大量实现容易受到本文档[NISCC][US-CERT]中讨论的所有或部分攻击的攻击。受影响的系统包括用于台式计算机的TCP/IP实现，以及用于核心互联网路由器的TCP/IP实现。
It is clear that implementations should be more cautious when processing ICMP error messages, to eliminate or mitigate the use of ICMP to perform attacks against TCP [RFC4907].
显然，在处理ICMP错误消息时，实现应该更加谨慎，以消除或减轻使用ICMP对TCP执行攻击[RFC4907]。
This document aims to raise awareness of the use of ICMP to perform a variety of attacks against TCP, and discusses several counter-measures that eliminate or minimize the impact of these attacks. Most of the these counter-measures can be implemented while still remaining compliant with the current specifications, as they simply describe reasons for not taking the advice provided in the specifications in terms of "SHOULDs", but still comply with the requirements stated as "MUSTs".
本文档旨在提高人们对使用ICMP对TCP执行各种攻击的认识，并讨论消除或最小化这些攻击影响的几种对策。这些反措施中的大多数可以在仍然符合当前规范的情况下实施，因为它们只是简单地描述了不采纳规范中提供的“应”建议的原因，但仍然符合“必须”的要求。
We note that the counter-measures discussed in this document are not part of standard TCP behavior, and this document does not change that state of affairs. The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior but to not change the TCP standard.
我们注意到，本文档中讨论的对策不是标准TCP行为的一部分，并且本文档不会改变这种情况。TCPM工作组（TCP维护和小型扩展工作组）的共识是记录这种广泛实施的非标准TCP行为，但不改变TCP标准。
Section 2 provides background information on ICMP. Section 3 discusses the constraints in the general counter-measures that can be implemented against the attacks described in this document.
第2节提供了ICMP的背景信息。第3节讨论了可针对本文档中描述的攻击实施的一般对策中的约束。
Section 4 describes several general validation checks that can be implemented to mitigate any ICMP-based attack. Finally, Section 5, Section 6, and Section 7, discuss a variety of ICMP attacks that can be performed against TCP, and describe attack-specific counter-measures that eliminate or greatly mitigate their impact.
第4节描述了几种可用于缓解任何基于ICMP的攻击的通用验证检查。最后，在第5节、第6节和第7节中，讨论了可以针对TCP执行的各种ICMP攻击，并描述了消除或大大减轻其影响的特定于攻击的对策。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The Internet Control Message Protocol (ICMP) is used in the Internet architecture mainly to perform the fault-isolation function, that is, the group of actions that hosts and routers take to determine that there is some network failure [RFC0816].
Internet控制消息协议（ICMP）在Internet体系结构中主要用于执行故障隔离功能，即主机和路由器为确定存在某种网络故障而采取的一组操作[RFC0816]。
When an intermediate router detects a network problem while trying to forward an IP packet, it will usually send an ICMP error message to the source system, to inform the source system of the network problem taking place. In the same way, there are a number of scenarios in which an end-system may generate an ICMP error message if it finds a problem while processing a datagram. The received ICMP errors are handed to the corresponding transport-protocol instance, which will usually perform a fault recovery function.
当中间路由器在尝试转发IP数据包时检测到网络问题时，它通常会向源系统发送ICMP错误消息，以通知源系统发生的网络问题。同样，在许多情况下，如果终端系统在处理数据报时发现问题，可能会生成ICMP错误消息。接收到的ICMP错误会传递给相应的传输协议实例，该实例通常会执行故障恢复功能。
It is important to note that ICMP error messages are transmitted unreliably and may be discarded due to data corruption, network congestion, or rate-limiting. Thus, while they provide useful information, upper-layer protocols cannot depend on ICMP for correct operation.
需要注意的是，ICMP错误消息传输不可靠，并且可能由于数据损坏、网络拥塞或速率限制而被丢弃。因此，尽管上层协议提供了有用的信息，但它们不能依赖ICMP进行正确的操作。
It should be noted that there are no timeliness requirements for ICMP error messages. ICMP error messages could be delayed for various reasons, and at least in theory could be received with an arbitrarily long delay. For example, there are no existing requirements that a router flush any queued ICMP error messages when it is rebooted.
应该注意的是，ICMP错误消息没有时效性要求。ICMP错误消息可能由于各种原因而延迟，至少在理论上可以以任意长的延迟接收。例如，路由器重新启动时，不存在刷新任何排队ICMP错误消息的现有要求。
[RFC0792] specifies the Internet Control Message Protocol (ICMP) to be used with the Internet Protocol version 4 (IPv4) -- henceforth "ICMPv4". It defines, among other things, a number of error messages that can be used by end-systems and intermediate systems to report errors to the sending system. The Host Requirements RFC [RFC1122]
[RFC0792]指定要与Internet协议版本4（IPv4）一起使用的Internet控制消息协议（ICMP）——此后为“ICMPv4”。它定义了许多错误消息，终端系统和中间系统可以使用这些消息向发送系统报告错误。主机要求RFC[RFC1122]
classifies ICMPv4 error messages into those that indicate "soft errors", and those that indicate "hard errors", thus roughly defining the semantics of them.
将ICMPv4错误消息分为表示“软错误”的消息和表示“硬错误”的消息，从而大致定义了它们的语义。
The ICMPv4 specification [RFC0792] also defines the ICMPv4 Source Quench message (type 4, code 0), which is meant to provide a mechanism for flow control and congestion control.
ICMPv4规范[RFC0792]还定义了ICMPv4源猝灭消息（类型4，代码0），旨在提供流量控制和拥塞控制机制。
[RFC1191] defines a mechanism called "Path MTU Discovery" (PMTUD), which makes use of ICMPv4 error messages of type 3 (Destination Unreachable), code 4 (fragmentation needed and DF bit set) to allow systems to determine the MTU of an arbitrary internet path.
[RFC1191]定义了一种称为“路径MTU发现”（PMTUD）的机制，该机制利用类型3（无法到达目的地）、代码4（需要碎片和DF位设置）的ICMPv4错误消息，允许系统确定任意internet路径的MTU。
Finally, [RFC4884] redefines selected ICMPv4 messages to include an extension structure and a length attribute, such that those ICMPv4 messages can carry additional information by encoding that information in the extension structure.
最后，[RFC4884]重新定义选定的ICMPv4消息，以包括扩展结构和长度属性，这样这些ICMPv4消息可以通过在扩展结构中编码该信息来携带附加信息。
Appendix D of [RFC4301] provides information about which ICMPv4 error messages are produced by hosts, intermediate routers, or both.
[RFC4301]的附录D提供了由主机、中间路由器或两者产生的ICMPv4错误消息的相关信息。
[RFC4443] specifies the Internet Control Message Protocol (ICMPv6) to be used with the Internet Protocol version 6 (IPv6) [RFC2460].
[RFC4443]指定要与Internet协议版本6（IPv6）[RFC2460]一起使用的Internet控制消息协议（ICMPv6）。
[RFC4443] defines the "Packet Too Big" (type 2, code 0) error message, which is analogous to the ICMPv4 "fragmentation needed and DF bit set" (type 3, code 4) error message. [RFC1981] defines the Path MTU Discovery mechanism for IP version 6, which makes use of these messages to determine the MTU of an arbitrary internet path.
[RFC4443]定义“数据包太大”（类型2，代码0）错误消息，类似于ICMPv4“需要碎片和DF位设置”（类型3，代码4）错误消息。[RFC1981]定义了IP版本6的路径MTU发现机制，该机制利用这些消息确定任意internet路径的MTU。
Finally, [RFC4884] redefines selected ICMPv6 messages to include an extension structure and a length attribute, such that those ICMPv6 messages can carry additional information by encoding that information in the extension structure.
最后，[RFC4884]重新定义所选ICMPv6消息，以包括扩展结构和长度属性，从而这些ICMPv6消息可以通过在扩展结构中编码该信息来携带附加信息。
Appendix D of [RFC4301] provides information about which ICMPv6 error messages are produced by hosts, intermediate routers, or both.
[RFC4301]的附录D提供了由主机、中间路由器或两者产生的ICMPv6错误消息的相关信息。
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that TCP MUST act on an ICMP error message passed up from the IP layer, directing it to the connection that triggered the error.
主机要求RFC[RFC1122]在第4.2.3.9节中指出，TCP必须对IP层传递的ICMP错误消息采取行动，将其定向到触发错误的连接。
In order to allow ICMP messages to be demultiplexed by the receiving system, part of the original packet that triggered the message is included in the payload of the ICMP error message. Thus, the receiving system can use that information to match the ICMP error to the transport protocol instance that triggered it.
为了允许接收系统对ICMP消息进行解复用，触发消息的原始数据包的一部分包含在ICMP错误消息的有效负载中。因此，接收系统可以使用该信息将ICMP错误与触发该错误的传输协议实例相匹配。
Neither the Host Requirements RFC [RFC1122] nor the original TCP specification [RFC0793] recommends any validation checks on the received ICMP messages. Thus, as long as the ICMP payload contains the information that identifies an existing communication instance, it will be processed by the corresponding transport-protocol instance, and the corresponding action will be performed.
主机要求RFC[RFC1122]和原始TCP规范[RFC0793]都不建议对收到的ICMP消息进行任何验证检查。因此，只要ICMP有效负载包含标识现有通信实例的信息，它就会被相应的传输协议实例处理，并执行相应的操作。
Therefore, in the case of TCP, an attacker could send a crafted ICMP error message to the attacked system, and, as long as he is able to guess the four-tuple (i.e., Source IP Address, Source TCP port, Destination IP Address, and Destination TCP port) that identifies the communication instance to be attacked, he will be able to use ICMP to perform a variety of attacks.
因此，在TCP的情况下，攻击者可以向被攻击的系统发送精心编制的ICMP错误消息，并且，只要他能够猜出标识要攻击的通信实例的四个元组（即，源IP地址、源TCP端口、目标IP地址和目标TCP端口），他将能够使用ICMP执行各种攻击。
Generally, the four-tuple required to perform these attacks is not known. However, as discussed in [Watson] and [RFC4953], there are a number of scenarios (notably that of TCP connections established between two BGP routers [RFC4271]) in which an attacker may be able to know or guess the four-tuple that identifies a TCP connection. In such a case, if we assume the attacker knows the two systems involved in the TCP connection to be attacked, both the client-side and the server-side IP addresses could be known or be within a reasonable number of possibilities. Furthermore, as most Internet services use the so-called "well-known" ports, only the client port number might need to be guessed. In such a scenario, an attacker would need to send, in principle, at most 65536 packets to perform any of the attacks described in this document. These issues are exacerbated by the fact that most systems choose the port numbers they use for outgoing connections from a subset of the whole port number space, thus reducing the amount of work needed to successfully perform these attacks.
通常，执行这些攻击所需的四元组是未知的。然而，正如[Watson]和[RFC4953]中所讨论的，在许多情况下（尤其是在两个BGP路由器[RFC4271]之间建立TCP连接的情况），攻击者可能知道或猜测标识TCP连接的四元组。在这种情况下，如果我们假设攻击者知道要攻击的TCP连接中涉及的两个系统，那么客户端和服务器端IP地址都可能是已知的，或者在合理的可能性范围内。此外，由于大多数Internet服务使用所谓的“已知”端口，因此可能只需要猜测客户端端口号。在这种情况下，攻击者原则上最多需要发送65536个数据包才能执行本文档中描述的任何攻击。大多数系统从整个端口号空间的子集中选择用于传出连接的端口号，从而减少成功执行这些攻击所需的工作量，这一事实加剧了这些问题。
The need to be more cautious when processing received ICMP error messages in order to mitigate or eliminate the impact of the attacks described in this RFC has been documented by the Internet Architecture Board (IAB) in [RFC4907].
互联网体系结构委员会（IAB）在[RFC4907]中记录了在处理收到的ICMP错误消息时需要更加谨慎，以减轻或消除本RFC中所述攻击的影响。
Section 5.2 of [RFC4301] describes the processing of inbound IP traffic in the case of "unprotected-to-protected". In the case of ICMP, when an unprotected ICMP error message is received, it is
[RFC4301]第5.2节描述了“未保护到受保护”情况下的入站IP流量处理。对于ICMP，当接收到未受保护的ICMP错误消息时，它是
matched to the corresponding security association by means of the SPI (Security Parameters Index) included in the payload of the ICMP error message. Then, local policy is applied to determine whether to accept or reject the message and, if accepted, what action to take as a result. For example, if an ICMP Destination Unreachable message is received, the implementation must decide whether to act on it, reject it, or act on it with constraints. Section 8 ("Path MTU/DF Processing") discusses the processing of unauthenticated ICMPv4 "fragmentation needed and DF bit set" (type 3, code 4) and ICMPv6 "Packet Too Big" (type 2, code 0) messages when an IPsec implementation is configured to process (vs. ignore) such messages.
通过ICMP错误消息有效负载中包含的SPI（安全参数索引）与相应的安全关联相匹配。然后，应用本地策略来确定是接受还是拒绝消息，以及如果接受，将采取什么操作。例如，如果接收到ICMP目标不可访问消息，则实现必须决定是对其进行操作、拒绝它，还是对其进行约束。第8节（“路径MTU/DF处理”）讨论了当IPsec实现配置为处理（而不是忽略）此类消息时，未经验证的ICMPv4“需要碎片和DF位设置”（类型3，代码4）和ICMPv6“数据包太大”（类型2，代码0）消息的处理。
Section 6.1.1 of [RFC4301] notes that processing of unauthenticated ICMP error messages may result in denial or degradation of service, and therefore it would be desirable to ignore such messages. However, it also notes that in many cases, ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTUD and redirection messages, and therefore there is also a motivation for accepting and acting upon them. It finally states that to accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic, and that this control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic.
[RFC4301]第6.1.1节指出，处理未经验证的ICMP错误消息可能导致拒绝或服务降级，因此最好忽略此类消息。然而，它也注意到，在许多情况下，忽略这些ICMP消息可能会降低服务质量，例如，由于无法处理PMTUD和重定向消息，因此也有接受和处理这些消息的动机。它最后指出，为了适应这一范围的两端，兼容的IPsec实现必须允许本地管理员配置IPsec实现以接受或拒绝未经验证的ICMP通信，并且此控制必须是ICMP类型的粒度，也可以是ICMP类型和代码的粒度。此外，实现应包含处理此类流量的机制和参数。
Thus, the policy to apply for the processing of unprotected ICMP error messages is left up to the implementation and administrator.
因此，应用于处理未受保护的ICMP错误消息的策略由实现和管理员决定。
If a host wants to perform validation checks on the received ICMP error messages before acting on them, it is limited by the piece of the packet that triggered the error that the sender of the ICMP error message chose to include in the ICMP payload. This constrains the possible validation checks, as the number of bytes of the packet that triggered the error message that is included in the ICMP payload is limited.
如果主机希望在对接收到的ICMP错误消息执行操作之前对其执行验证检查，则受触发ICMP错误消息发送方选择包含在ICMP有效负载中的错误的数据包片段的限制。这限制了可能的验证检查，因为触发ICMP有效负载中包含的错误消息的数据包的字节数是有限的。
For ICMPv4, [RFC0792] states that the IP header plus the first 64 bits of the packet that triggered the ICMPv4 message are to be included in the payload of the ICMPv4 error message. Thus, it is assumed that all data needed to identify a transport protocol instance and process the ICMPv4 error message is contained in the first 64 bits of the transport protocol header. Section 3.2.2 of [RFC1122] states that "the Internet header and at least the first 8 data octets of the datagram that triggered the error" are to be
对于ICMPv4，[RFC0792]指出，IP报头加上触发ICMPv4消息的数据包的前64位将包含在ICMPv4错误消息的有效负载中。因此，假设识别传输协议实例和处理ICMPv4错误消息所需的所有数据都包含在传输协议报头的前64位中。[RFC1122]第3.2.2节规定，“互联网报头和触发错误的数据报的至少前8个数据八位字节”将被删除
included in the payload of ICMPv4 error messages, and that "more than 8 octets MAY be sent", thus allowing implementations to include more data from the original packet than those required by the original ICMPv4 specification. The "Requirements for IP Version 4 Routers" RFC [RFC1812] states that ICMPv4 error messages "SHOULD contain as much of the original datagram as possible without the length of the ICMP datagram exceeding 576 bytes".
包含在ICMPv4错误消息的有效负载中，并且“可能发送8个以上的八位字节”，因此允许实现从原始数据包中包含比原始ICMPv4规范要求的更多的数据。“IP版本4路由器的要求”RFC[RFC1812]指出，ICMPv4错误消息“应包含尽可能多的原始数据报，且ICMP数据报的长度不得超过576字节”。
Thus, for ICMPv4 messages generated by hosts, we can only expect to get the entire IP header of the original packet, plus the first 64 bits of its payload. For TCP, this means that the only fields that will be included in the ICMPv4 payload are the source port number, the destination port number, and the 32-bit TCP sequence number. This clearly imposes a constraint on the possible validation checks that can be performed, as there is not much information available on which to perform them.
因此，对于主机生成的ICMPv4消息，我们只能期望得到原始数据包的整个IP报头，加上其有效负载的前64位。对于TCP，这意味着ICMPv4有效负载中只包括源端口号、目标端口号和32位TCP序列号。这显然对可能执行的验证检查施加了限制，因为执行这些检查的信息不多。
This means, for example, that even if TCP were signing its segments by means of the TCP MD5 signature option [RFC2385], this mechanism could not be used as a counter-measure against ICMP-based attacks, because, as ICMP messages include only a piece of the TCP segment that triggered the error, the MD5 [RFC1321] signature could not be recalculated. In the same way, even if the attacked peer were authenticating its packets at the IP layer [RFC4301], because only a part of the original IP packet would be available, the signature used for authentication could not be recalculated, and thus the authentication header in the original packet could not be used as a counter-measure for ICMP-based attacks against TCP.
这意味着，例如，即使TCP通过TCP MD5签名选项[RFC2385]对其段进行签名，该机制也不能用作对抗基于ICMP的攻击的对策，因为ICMP消息仅包括触发错误的TCP段的一部分，因此无法重新计算MD5[RFC1321]签名。同样，即使受攻击的对等方在IP层[RFC4301]对其数据包进行身份验证，由于只有原始IP数据包的一部分可用，因此无法重新计算用于身份验证的签名，因此，原始数据包中的身份验证头不能用作针对TCP的基于ICMP的攻击的对抗措施。
[RFC4884] updated [RFC0792] and specified that ICMPv4 Destination Unreachable (type 3), Time Exceeded (type 11), and Parameter Problem (type 12) messages that have an ICMP Extension Structure appended include at least 128 octets in the "original datagram" field. This would improve the situation, but at the time of this writing, [RFC4884] is not yet widely deployed for end-systems.
[RFC4884]更新了[RFC0792]，并指定附加了ICMP扩展结构的ICMPv4目标不可访问（类型3）、超过时间（类型11）和参数问题（类型12）消息在“原始数据报”字段中至少包含128个八位字节。这将改善这种情况，但在撰写本文时，[RFC4884]尚未广泛用于终端系统。
For IPv6, the payload of ICMPv6 error messages includes as many octets from the IPv6 packet that triggered the ICMPv6 error message as will fit without making the resulting ICMPv6 error message exceed the minimum IPv6 MTU (1280 octets) [RFC4443]. Thus, more information is available than in the IPv4 case.
对于IPv6，ICMPv6错误消息的有效负载包括来自触发ICMPv6错误消息的IPv6数据包的尽可能多的八位字节，而不会使生成的ICMPv6错误消息超过最小IPv6 MTU（1280个八位字节）[RFC4443]。因此，可以获得比IPv4更多的信息。
Hosts could require ICMP error messages to be authenticated [RFC4301], in order to act upon them. However, while this requirement could make sense for those ICMP error messages sent by hosts, it would not be feasible for those ICMP error messages generated by routers, as this would imply either that the attacked system should have a security association [RFC4301] with every
主机可能需要对ICMP错误消息进行身份验证[RFC4301]，以便对其采取行动。然而，虽然这一要求对于主机发送的ICMP错误消息是有意义的，但对于路由器生成的ICMP错误消息则是不可行的，因为这意味着受攻击的系统应该与每个路由器都有安全关联[RFC4301]
existing intermediate system, or that it should be able to establish one dynamically. Current levels of deployment of protocols for dynamic establishment of security associations makes this unfeasible. Additionally, this would require routers to use certificates with paths compatible for all hosts on the network. Finally, there may be some scenarios, such as embedded devices, in which the processing power requirements of authentication might not allow IPsec authentication to be implemented effectively.
现有的中间系统，或者它应该能够动态地建立一个中间系统。目前用于动态建立安全关联的协议的部署水平使得这不可行。此外，这将要求路由器使用路径与网络上所有主机兼容的证书。最后，可能存在一些场景，例如嵌入式设备，其中身份验证的处理能力要求可能不允许有效实现IPsec身份验证。
The following subsections describe a number of mitigation techniques that help to eliminate or mitigate the impact of the attacks discussed in this document. Rather than being alternative counter-measures, they can be implemented together to increase the protection against these attacks.
以下小节描述了一些缓解技术，这些技术有助于消除或缓解本文档中讨论的攻击的影响。它们不是替代性的反措施，而是可以一起实施，以加强对这些攻击的保护。
The current specifications do not impose any validity checks on the TCP segment that is contained in the ICMP payload. For instance, no checks are performed to verify that a received ICMP error message has been triggered by a segment that was "in flight" to the destination. Thus, even stale ICMP error messages will be acted upon.
当前规范未对ICMP有效负载中包含的TCP段实施任何有效性检查。例如，不执行任何检查以验证接收到的ICMP错误消息是否由“正在飞行”到目的地的段触发。因此，即使是过时的ICMP错误消息也会被处理。
Many TCP implementations have incorporated a validation check such that they react only to those ICMP error messages that appear to relate to segments currently "in flight" to the destination system. These implementations check that the TCP sequence number contained in the payload of the ICMP error message is within the range SND.UNA =< SEG.SEQ < SND.NXT. This means that they require that the sequence number be within the range of the data already sent but not yet acknowledged. If an ICMP error message does not pass this check, it is discarded.
许多TCP实现都包含了验证检查，因此它们只对那些似乎与当前“正在飞行”到目标系统的段相关的ICMP错误消息作出反应。这些实现检查ICMP错误消息的有效负载中包含的TCP序列号是否在范围SND.UNA=<SEG.SEQ<SND.NXT内。这意味着它们要求序列号在已发送但尚未确认的数据范围内。如果ICMP错误消息未通过此检查，则会将其丢弃。
Even if an attacker were able to guess the four-tuple that identifies the TCP connection, this additional check would reduce the possibility of considering a spoofed ICMP packet as valid to Flight_Size/2^^32 (where Flight_Size is the number of data bytes already sent to the remote peer, but not yet acknowledged [RFC5681]). For connections in the SYN-SENT or SYN-RECEIVED states, this would reduce the possibility of considering a spoofed ICMP packet as valid to 1/2^^32. For a TCP endpoint with no data "in flight", this would completely eliminate the possibility of success of these attacks.
即使攻击者能够猜出识别TCP连接的四元组，此附加检查也会降低将伪造ICMP数据包视为对Flight_Size/2^^32有效的可能性（其中Flight_Size是已发送到远程对等方但尚未确认的数据字节数[RFC5681]）。对于处于SYN-SENT或SYN-RECEIVE状态的连接，这将减少将伪造ICMP数据包视为有效到1/2^^32的可能性。对于没有“飞行中”数据的TCP端点，这将完全消除这些攻击成功的可能性。
This validation check has been implemented in Linux [Linux] for many years, in OpenBSD [OpenBSD] since 2004, and in FreeBSD [FreeBSD] and NetBSD [NetBSD] since 2005.
此验证检查已在Linux[Linux]中实施多年，从2004年开始在OpenBSD[OpenBSD]中实施，从2005年开始在FreeBSD[FreeBSD]和NetBSD[NetBSD]中实施。
It is important to note that while this check greatly increases the number of packets required to perform any of the attacks discussed in this document, this may not be enough in those scenarios in which bandwidth is easily available and/or large TCP windows [RFC1323] are in use. Additionally, this validation check does not help to prevent on-path attacks, that is, attacks performed in scenarios in which the attacker can sniff the packets that correspond to the target TCP connection.
需要注意的是，虽然此检查大大增加了执行本文档中讨论的任何攻击所需的数据包数量，但在带宽容易获得和/或使用大型TCP窗口[RFC1323]的情况下，这可能是不够的。此外，此验证检查无助于防止路径攻击，即在攻击者可以嗅探与目标TCP连接对应的数据包的情况下执行的攻击。
It should be noted that, as there are no timeliness requirements for ICMP error messages, the TCP Sequence Number check described in this section might cause legitimate ICMP error messages to be discarded. Also, even if this check is enforced, TCP might end up responding to stale ICMP error messages (e.g., if the Sequence Number for the corresponding direction of the data transfer wraps around).
应该注意的是，由于ICMP错误消息没有时效性要求，本节中描述的TCP序列号检查可能会导致丢弃合法的ICMP错误消息。此外，即使强制执行此检查，TCP也可能最终响应过时的ICMP错误消息（例如，如果数据传输的相应方向的序列号环绕）。
As discussed in the previous sections, in order to perform any of the attacks described in this document, an attacker would need to guess (or know) the four-tuple that identifies the connection to be attacked. Increasing the port number range used for outgoing TCP connections, and randomizing the port number chosen for each outgoing TCP connection, would make it harder for an attacker to perform any of the attacks discussed in this document.
如前几节所述，为了执行本文档中描述的任何攻击，攻击者需要猜测（或知道）标识要攻击的连接的四元组。增加用于传出TCP连接的端口号范围，并随机化为每个传出TCP连接选择的端口号，将使攻击者更难执行本文档中讨论的任何攻击。
[PORT-RANDOM] recommends that transport protocols randomize the ephemeral ports used by clients, and proposes a number of randomization algorithms.
[PORT-RANDOM]建议传输协议对客户端使用的临时端口进行随机化，并提出了一些随机化算法。
The source address of ICMP error messages does not need to be spoofed to perform the attacks described in this document, as the ICMP error messages might legitimately come from an intermediate system. Therefore, simple filtering based on the source address of ICMP error messages does not serve as a counter-measure against these attacks. However, a more advanced packet filtering can be implemented in middlebox devices such as firewalls and NATs. Middleboxes implementing such advanced filtering look at the payload of the ICMP error messages, and perform ingress and egress packet filtering based on the source address of the IP header contained in the payload of the ICMP error message. As the source address contained in the payload of the ICMP error message does need to be spoofed to perform the attacks described in this document, this kind of advanced filtering serves as a counter-measure against these attacks. As with traditional egress filtering [IP-filtering], egress filtering based on the ICMP payload can help to prevent users of the network being
不需要伪造ICMP错误消息的源地址来执行本文档中描述的攻击，因为ICMP错误消息可能合法地来自中间系统。因此，基于ICMP错误消息源地址的简单过滤不能作为抵御这些攻击的对策。然而，更高级的包过滤可以在诸如防火墙和NAT之类的中间盒设备中实现。实现这种高级过滤的中间盒查看ICMP错误消息的有效负载，并基于ICMP错误消息的有效负载中包含的IP报头的源地址执行进出包过滤。由于ICMP错误消息的有效负载中包含的源地址确实需要被欺骗以执行本文档中描述的攻击，因此这种高级过滤可作为对抗这些攻击的一种对策。与传统的出口过滤[IP过滤]一样，基于ICMP有效负载的出口过滤有助于防止网络用户受到攻击
protected by the firewall from successfully performing ICMP attacks against TCP connections established between external systems. Additionally, ingress filtering based on the ICMP payload can prevent TCP connections established between internal systems from being attacked by external systems. [ICMP-Filtering] provides examples of ICMP filtering based on the ICMP payload.
受防火墙保护，不会对外部系统之间建立的TCP连接成功执行ICMP攻击。此外，基于ICMP有效负载的入口过滤可以防止内部系统之间建立的TCP连接受到外部系统的攻击。[ICMP筛选]提供了基于ICMP有效负载的ICMP筛选示例。
This filtering technique has been implemented in OpenBSD's Packet Filter [OpenBSD-PF], which has in turn been ported to a number of systems, including FreeBSD [FreeBSD].
这种过滤技术已经在OpenBSD的包过滤器[OpenBSD PF]中实现，该过滤器又被移植到许多系统，包括FreeBSD[FreeBSD]。
When TCP is handed an ICMP error message, it will perform its fault recovery function, as follows:
当TCP收到ICMP错误消息时，它将执行其故障恢复功能，如下所示：
o If the network problem being reported is a "hard error", TCP will abort the corresponding connection.
o 如果报告的网络问题是“硬错误”，TCP将中止相应的连接。
o If the network problem being reported is a "soft error", TCP will just record this information, and repeatedly retransmit its data until they either get acknowledged, or the connection times out.
o 如果报告的网络问题是“软错误”，TCP将只记录此信息，并重复传输其数据，直到它们得到确认或连接超时。
The Host Requirements RFC [RFC1122] states (in Section 4.2.3.9) that a host SHOULD abort the corresponding connection when receiving an ICMPv4 error message that indicates a "hard error", and states that ICMPv4 error messages of type 3 (Destination Unreachable), codes 2 (protocol unreachable), 3 (port unreachable), and 4 (fragmentation needed and DF bit set) should be considered as indicating "hard errors". In the case of ICMPv4 port unreachables, the specifications are ambiguous, as Section 4.2.3.9 of [RFC1122] states that TCP SHOULD abort the corresponding connection in response to them, but Section 3.2.2.1 of the same RFC ([RFC1122]) states that TCP MUST abort the connection in response to them.
主机要求RFC[RFC1122]规定（在第4.2.3.9节中），当接收到指示“硬错误”的ICMPv4错误消息时，主机应中止相应的连接，并规定类型为3（目标不可访问）、代码2（协议不可访问）、3（端口不可访问）和4的ICMPv4错误消息（需要分段和DF位设置）应视为指示“硬错误”。如果ICMPv4端口无法访问，则规范不明确，因为[RFC1122]的第4.2.3.9节规定TCP应中止相应的连接以响应它们，但相同RFC的第3.2.2.1节（[RFC1122]）声明TCP必须中止连接以响应它们。
While [RFC4443] did not exist when [RFC1122] was published, one could extrapolate the concept of "hard errors" to ICMPv6 error messages of type 1 (Destination Unreachable), codes 1 (communication with destination administratively prohibited), and 4 (port unreachable).
虽然[RFC4443]在[RFC1122]发布时不存在，但可以将“硬错误”的概念外推到类型1（目标不可访问）、代码1（与目标管理禁止的通信）和4（端口不可访问）的ICMPv6错误消息。
Thus, an attacker could use ICMP to perform a blind connection-reset attack by sending any ICMP error message that indicates a "hard error" to either of the two TCP endpoints of the connection. Because of TCP's fault recovery policy, the connection would be immediately aborted.
因此，攻击者可以通过向连接的两个TCP端点中的任何一个发送指示“硬错误”的ICMP错误消息，使用ICMP执行盲连接重置攻击。由于TCP的故障恢复策略，连接将立即中止。
Some stacks are known to extrapolate ICMP "hard errors" across TCP connections, increasing the impact of this attack, as a single ICMP packet could bring down all the TCP connections between the corresponding peers.
已知一些堆栈会在TCP连接中推断ICMP“硬错误”，从而增加此攻击的影响，因为单个ICMP数据包可能导致相应对等方之间的所有TCP连接中断。
It is important to note that even if TCP itself were protected against the blind connection-reset attack described in [Watson] and [TCPM-TCPSECURE] by means of authentication at the network layer [RFC4301], by means of the TCP MD5 signature option [RFC2385], by means of the TCP-AO [RFC5925], or by means of the mechanism specified in [TCPM-TCPSECURE], the blind connection-reset attack described in this document would still succeed.
需要注意的是，即使TCP本身通过网络层身份验证[RFC4301]、TCP MD5签名选项[RFC2385]、TCP-AO[RFC5925]或中指定的机制受到保护，不受[Watson]和[TCPM-TCPSECURE]中所述的盲连接重置攻击[TCPM-TCPSECURE]，本文档中描述的盲连接重置攻击仍然会成功。
An analysis of the circumstances in which ICMP messages that indicate "hard errors" may be received can shed some light on opportunities to mitigate the impact of ICMP-based blind connection-reset attacks.
对可能接收到指示“硬错误”的ICMP消息的情况进行分析，有助于了解减轻基于ICMP的盲连接重置攻击影响的机会。
ICMPv4 type 3 (Destination Unreachable), code 2 (protocol unreachable)
ICMPv4类型3（无法访问目标），代码2（无法访问协议）
This ICMP error message indicates that the host sending the ICMP error message received a packet meant for a transport protocol it does not support. For connection-oriented protocols such as TCP, one could expect to receive such an error as the result of a connection-establishment attempt. However, it would be strange to get such an error during the life of a connection, as this would indicate that support for that transport protocol has been removed from the system sending the error message during the life of the corresponding connection.
此ICMP错误消息表示发送ICMP错误消息的主机收到的数据包不支持传输协议。对于面向连接的协议（如TCP），可以预期连接建立尝试会导致这样的错误。但是，在连接的生命周期内出现这样的错误是很奇怪的，因为这将表明在相应连接的生命周期内发送错误消息的系统已删除对该传输协议的支持。
ICMPv4 type 3 (Destination Unreachable), code 3 (port unreachable)
ICMPv4类型3（无法访问目标），代码3（无法访问端口）
This error message indicates that the system sending the ICMP error message received a packet meant for a socket (IP address, port number) on which there is no process listening. Those transport protocols that have their own mechanisms for signaling this condition should not be receiving these error messages, as the protocol would signal the port unreachable condition by means of its own mechanisms. Assuming that once a connection is established it is not usual for the transport protocol to change (or be reloaded), it should be unusual to get these error messages.
此错误消息表示发送ICMP错误消息的系统接收到一个数据包，该数据包用于没有进程侦听的套接字（IP地址、端口号）。那些有自己的机制来通知这种情况的传输协议不应该接收这些错误消息，因为该协议将通过自己的机制通知端口不可访问的情况。假设一旦建立了连接，传输协议通常不会更改（或重新加载），那么获取这些错误消息应该是不常见的。
ICMPv4 type 3 (Destination Unreachable), code 4 (fragmentation needed and DF bit set)
ICMPv4类型3（无法到达目的地），代码4（需要碎片和DF位设置）
This error message indicates that an intermediate node needed to fragment a datagram, but the DF (Don't Fragment) bit in the IP header was set. It is considered a "soft error" when TCP implements PMTUD, and a "hard error" if TCP does not implement PMTUD. Those TCP/IP stacks that do not implement PMTUD (or have disabled it) but support IP fragmentation/reassembly should not be sending their IP packets with the DF bit set, and thus should not be receiving these ICMP error messages. Some TCP/IP stacks that do not implement PMTUD and that do not support IP fragmentation/ reassembly are known to send their packets with the DF bit set, and thus could legitimately receive these ICMP error messages.
此错误消息表示中间节点需要对数据报进行分段，但IP报头中的DF（不分段）位已设置。当TCP实现PMTUD时，它被视为“软错误”，如果TCP不实现PMTUD，则被视为“硬错误”。那些不实现PMTUD（或已禁用PMTUD）但支持IP分段/重组的TCP/IP堆栈不应发送其设置了DF位的IP数据包，因此不应接收这些ICMP错误消息。已知一些不实现PMTUD且不支持IP分段/重组的TCP/IP堆栈使用DF位集发送数据包，因此可以合法地接收这些ICMP错误消息。
ICMPv6 type 1 (Destination Unreachable), code 1 (communication with destination administratively prohibited)
ICMPv6类型1（无法到达目的地），代码1（管理禁止与目的地通信）
This error message indicates that the destination is unreachable because of an administrative policy. For connection-oriented protocols such as TCP, one could expect to receive such an error as the result of a connection-establishment attempt. Receiving such an error for a connection in any of the synchronized states would mean that the administrative policy changed during the life of the connection. However, in the same way this error condition (which was not present when the connection was established) appeared, it could get solved in the near term.
此错误消息表示由于管理策略而无法访问目标。对于面向连接的协议（如TCP），可以预期连接建立尝试会导致这样的错误。对于处于任何同步状态的连接，接收到这样的错误将意味着管理策略在连接的生命周期内发生更改。然而，以同样的方式出现这种错误情况（建立连接时不存在这种情况），它可以在短期内得到解决。
ICMPv6 type 1 (Destination Unreachable), code 4 (port unreachable)
ICMPv6类型1（无法访问目标），代码4（无法访问端口）
This error message is analogous to the ICMPv4 type 3 (Destination Unreachable), code 3 (port unreachable) error message discussed above. Therefore, the same considerations apply.
此错误消息类似于上面讨论的ICMPv4类型3（目标不可访问）、代码3（端口不可访问）错误消息。因此，同样的考虑也适用。
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that TCP SHOULD abort the corresponding connection in response to ICMPv4 messages of type 3 (Destination Unreachable), codes 2 (protocol unreachable), 3 (port unreachable), and 4 (fragmentation needed and DF bit set). However, Section 3.2.2.1 states that TCP MUST accept an ICMPv4 port unreachable (type 3, code 3) for the same purpose as a RST. Therefore, for ICMPv4 messages of type 3, codes 2 and 4, there is room to go against the advice provided in the existing specifications, while in the case of ICMPv4 messages of type 3, code 3, there is ambiguity in the specifications that may or may not provide some room to go against that advice.
主机要求RFC[RFC1122]在第4.2.3.9节中指出，TCP应中止相应的连接，以响应类型3（目标不可访问）、代码2（协议不可访问）、3（端口不可访问）和4（需要分段和DF位设置）的ICMPv4消息。但是，第3.2.2.1节规定，TCP必须接受无法访问的ICMPv4端口（类型3，代码3），用于与RST相同的目的。因此，对于类型3、代码2和代码4的ICMPv4消息，存在违背现有规范中提供的建议的空间，而对于类型3、代码3的ICMPv4消息，规范中存在歧义，可能会或可能不会提供违背该建议的空间。
Based on this analysis, most popular TCP implementations treat all ICMP "hard errors" received for connections in any of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT) as "soft errors". That is, they do not abort the corresponding connection upon receipt of them.
基于此分析，大多数流行的TCP实现将在任何同步状态（已建立、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSE、LAST-ACK或TIME-WAIT）下接收的连接的所有ICMP“硬错误”视为“软错误”。也就是说，它们不会在收到相应的连接后中止相应的连接。
Additionally, they do not extrapolate ICMP errors across TCP connections. This policy is based on the premise that TCP should be as robust as possible. Aborting the connection would be to ignore the valuable feature of the Internet -- that for many internal failures, it reconstructs its function without any disruption of the endpoints [RFC0816].
此外，它们不会跨TCP连接推断ICMP错误。该策略基于TCP应尽可能健壮的前提。中止连接将忽略互联网的重要功能——对于许多内部故障，它在不中断端点的情况下重建其功能[RFC0816]。
It should be noted that treating ICMP "hard errors" as "soft errors" for connections in any of the synchronized states may prevent TCP from responding quickly to a legitimate ICMP error message.
应该注意，对于处于任何同步状态的连接，将ICMP“硬错误”视为“软错误”可能会阻止TCP快速响应合法的ICMP错误消息。
It is interesting to note that, as ICMP error messages are transmitted unreliably, transport protocols should not depend on them for correct functioning. In the event one of these messages were legitimate, the corresponding connection would eventually time out. Also, applications may still be notified asynchronously about the error condition, and thus may still abort their connections on their own if they consider it appropriate.
值得注意的是，由于ICMP错误消息的传输不可靠，因此传输协议不应依赖于ICMP错误消息来实现正确的功能。如果其中一条消息是合法的，则相应的连接最终将超时。此外，应用程序仍然可以异步地通知有关错误情况，因此如果他们认为合适的话，仍然可以自行中止它们的连接。
In scenarios such as that in which an intermediate system sets the DF bit in the segments transmitted by a TCP that does not implement PMTUD, or the TCP at one of the endpoints of the connection is dynamically disabled, TCP would only abort the connection after a USER TIMEOUT [RFC0793], losing responsiveness. However, these scenarios are very unlikely in production environments, and it is probably preferable to potentially lose responsiveness for the sake of robustness. It should also be noted that applications may still be notified asynchronously about the error condition, and thus may still abort their connections on their own if they consider it appropriate.
在诸如中间系统在未实现PMTUD的TCP传输的段中设置DF位，或连接的一个端点处的TCP被动态禁用的情况下，TCP只会在用户超时[RFC0793]后中止连接，从而失去响应。但是，这些场景在生产环境中不太可能出现，而且为了健壮性，最好是可能会失去响应能力。还应该注意到，应用程序仍然可以异步地通知有关错误情况，因此如果他们认为合适的话，仍然可以自行中止它们的连接。
In scenarios of multipath routing or route changes, failures in some (but not all) of the paths may elicit ICMP error messages that would likely not cause a connection abort if any of the counter-measures described in this section were implemented. However, aborting the connection would be to ignore the valuable feature of the Internet -- that for many internal failures, it reconstructs its function without any disruption of the endpoints [RFC0816]. That is, communication should survive if there is still a working path to the destination system [DClark]. Additionally, applications may still be notified asynchronously about the error condition, and thus may still abort their connections on their own if they consider it appropriate.
在多路径路由或路由更改的情况下，某些（但不是全部）路径中的故障可能会引发ICMP错误消息，如果实施了本节中描述的任何对策，这些消息可能不会导致连接中止。然而，中止连接将忽略互联网的重要功能——对于许多内部故障，它在不中断端点的情况下重建其功能[RFC0816]。也就是说，如果仍然存在到目标系统[DClark]的工作路径，则通信应该继续存在。此外，应用程序仍然可以异步地通知有关错误情况，因此如果他们认为合适的话，仍然可以自行中止它们的连接。
This counter-measure has been implemented in BSD-derived TCP/IP implementations (e.g., [FreeBSD], [NetBSD], and [OpenBSD]) for more than ten years [Wright][McKusick]. The Linux kernel has also implemented this policy for more than ten years [Linux].
这一对策已经在BSD派生的TCP/IP实现（例如[FreeBSD]、[NetBSD]和[OpenBSD]）中实施了十多年[Wright][McKusick]。Linux内核也实施了这一政策十多年[Linux]。
The Host Requirements RFC [RFC1122] states in Section 4.2.3.9 that hosts MUST react to ICMPv4 Source Quench messages by slowing transmission on the connection. Thus, an attacker could send ICMPv4 Source Quench (type 4, code 0) messages to a TCP endpoint to make it reduce the rate at which it sends data to the other endpoint of the connection. [RFC1122] further adds that the RECOMMENDED procedure is to put the corresponding connection in the slow-start phase of TCP's congestion control algorithm [RFC5681]. In the case of those implementations that use an initial congestion window of one segment, a sustained attack would reduce the throughput of the attacked connection to about SMSS (Sender Maximum Segment Size) [RFC5681] bytes per RTT (round-trip time). The throughput achieved during an attack might be a little higher if a larger initial congestion window is in use [RFC3390].
主机要求RFC[RFC1122]在第4.2.3.9节中指出，主机必须通过减慢连接上的传输速度来对ICMPv4源猝灭消息作出反应。因此，攻击者可以向TCP端点发送ICMPv4源猝灭（类型4，代码0）消息，使其降低向连接的另一个端点发送数据的速率。[RFC1122]进一步补充，建议的程序是将相应的连接置于TCP拥塞控制算法[RFC5681]的慢启动阶段。对于使用一个段的初始拥塞窗口的那些实现，持续攻击会将受攻击连接的吞吐量降低到大约SMSS（发送方最大段大小）[RFC5681]字节/RTT（往返时间）。如果使用较大的初始拥塞窗口，攻击期间实现的吞吐量可能会稍高一些[RFC3390]。
As discussed in the "Requirements for IP Version 4 Routers" RFC
[RFC1812], research seems to suggest that ICMPv4 Source Quench
messages are an ineffective (and unfair) antidote for congestion.
[RFC1812] further states that routers SHOULD NOT send ICMPv4 Source
Quench messages in response to congestion. Furthermore, TCP
implements its own congestion control mechanisms ([RFC5681]
[RFC3168]) that do not depend on ICMPv4 Source Quench messages.
As discussed in the "Requirements for IP Version 4 Routers" RFC
[RFC1812], research seems to suggest that ICMPv4 Source Quench
messages are an ineffective (and unfair) antidote for congestion.
[RFC1812] further states that routers SHOULD NOT send ICMPv4 Source
Quench messages in response to congestion. Furthermore, TCP
implements its own congestion control mechanisms ([RFC5681]
[RFC3168]) that do not depend on ICMPv4 Source Quench messages.
Based on this reasoning, a large number of implementations completely ignore ICMPv4 Source Quench messages meant for TCP connections. This behavior has been implemented in, at least, Linux [Linux] since 2004, and in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] since 2005. However, it must be noted that this behavior violates the requirement in [RFC1122] to react to ICMPv4 Source Quench messages by slowing transmission on the connection.
基于这种推理，许多实现完全忽略了用于TCP连接的ICMPv4源猝灭消息。至少从2004年起，Linux[Linux]已经实现了这种行为，从2005年起，FreeBSD[FreeBSD]、NetBSD[NetBSD]和OpenBSD[OpenBSD]已经实现了这种行为。但是，必须注意的是，这种行为违反了[RFC1122]中的要求，即通过减慢连接上的传输来对ICMPv4源猝灭消息作出反应。
When one IP system has a large amount of data to send to another system, the data will be transmitted as a series of IP datagrams. It is usually preferable that these datagrams be of the largest size that does not require fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the Path MTU (PMTU) and is equal to the minimum of the MTUs of each hop in the path. A technique called "Path MTU Discovery" (PMTUD) lets IP
当一个IP系统有大量数据要发送到另一个系统时，数据将作为一系列IP数据报进行传输。通常，这些数据报最好具有最大的大小，在从源到目的地的路径上的任何地方都不需要碎片。该数据报大小称为路径MTU（PMTU），等于路径中每个跃点的MTU的最小值。一种称为“路径MTU发现”（PMTUD）的技术使IP
systems determine the Path MTU of an arbitrary internet path. [RFC1191] and [RFC1981] specify the PMTUD mechanism for IPv4 and IPv6, respectively.
系统确定任意internet路径的路径MTU。[RFC1191]和[RFC1981]分别指定IPv4和IPv6的PMTUD机制。
The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the IP header to dynamically discover the Path MTU. The basic idea behind the PMTUD mechanism is that a source system assumes that the MTU of the path is that of the first hop, and sends all its datagrams with the DF bit set. If any of the datagrams is too large to be forwarded without fragmentation by some intermediate router, the router will discard the corresponding datagram and will return an ICMPv4 "Destination Unreachable, fragmentation needed and DF set" (type 3, code 4) error message to the sending system. This message will report the MTU of the constricting hop, so that the sending system can reduce the assumed Path-MTU accordingly.
IPv4的PMTUD机制使用IP报头中的Don't Fragment（DF）位来动态发现路径MTU。PMTUD机制背后的基本思想是源系统假设路径的MTU是第一跳的MTU，并使用DF位集发送其所有数据报。如果任何数据报太大，无法在没有碎片的情况下由某个中间路由器转发，路由器将丢弃相应的数据报，并将向发送系统返回ICMPv4“目的地不可到达，需要碎片和DF设置”（类型3，代码4）错误消息。此消息将报告压缩跃点的MTU，以便发送系统可以相应地减少假定路径MTU。
For IPv6, intermediate systems do not fragment packets. Thus, there's an "implicit" DF bit set in every packet sent on a network. If any of the datagrams is too large to be forwarded without fragmentation by some intermediate router, the router will discard the corresponding datagram, and will return an ICMPv6 "Packet Too Big" (type 2, code 0) error message to the sending system. This message will report the MTU of the constricting hop, so that the sending system can reduce the assumed Path-MTU accordingly.
对于IPv6，中间系统不会对数据包进行分段。因此，在网络上发送的每个数据包中都设置了一个“隐式”DF位。如果任何数据报太大，无法在没有碎片的情况下由某个中间路由器转发，路由器将丢弃相应的数据报，并将向发送系统返回ICMPv6“数据包太大”（类型2，代码0）错误消息。此消息将报告压缩跃点的MTU，以便发送系统可以相应地减少假定路径MTU。
As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery mechanism can be used to attack TCP. An attacker could send a crafted ICMPv4 "Destination Unreachable, fragmentation needed and DF set" packet (or their ICMPv6 counterpart) to the sending system, advertising a small Next-Hop MTU. As a result, the attacked system would reduce the size of the packets it sends for the corresponding connection accordingly.
如[RFC1191]和[RFC1981]中所述，路径MTU发现机制可用于攻击TCP。攻击者可以向发送系统发送精心编制的ICMPv4“目的地不可到达，需要碎片和DF设置”数据包（或其ICMPv6对应数据包），并宣传一个小的下一跳MTU。因此，受攻击的系统会相应地减小它为相应连接发送的数据包的大小。
The effect of this attack is two-fold. On one hand, it will increase the headers/data ratio, thus increasing the overhead needed to send data to the remote TCP endpoint. On the other hand, if the attacked system wanted to keep the same throughput it was achieving before being attacked, it would have to increase the packet rate. On virtually all systems, this will lead to an increased processing overhead, thus degrading the overall system performance.
这种攻击的效果是双重的。一方面，它将增加头/数据比率，从而增加向远程TCP端点发送数据所需的开销。另一方面，如果被攻击的系统想要保持被攻击前的吞吐量不变，就必须提高数据包速率。在几乎所有系统上，这将导致增加处理开销，从而降低系统的整体性能。
A particular scenario that may take place is one in which an attacker reports a Next-Hop MTU smaller than or equal to the amount of bytes needed for headers (IP header, plus TCP header). For example, if the attacker reports a Next-Hop MTU of 68 bytes, and the amount of bytes used for headers (IP header, plus TCP header) is larger than 68 bytes, the assumed Path-MTU will not even allow the attacked system to send a single byte of application data without
可能发生的一种特殊情况是，攻击者报告下一跳MTU小于或等于报头（IP报头加TCP报头）所需的字节数。例如，如果攻击者报告一个68字节的下一跳MTU，并且用于报头（IP报头加TCP报头）的字节数大于68字节，则假定的路径MTU甚至不允许受攻击的系统发送单个字节的应用程序数据，而不发送数据
fragmentation. This particular scenario might lead to unpredictable results. Another possible scenario is one in which a TCP connection is being secured by means of IPsec. If the Next-Hop MTU reported by the attacker is smaller than the amount of bytes needed for headers (IP and IPsec, in this case), the assumed Path-MTU will not even allow the attacked system to send a single byte of the TCP header without fragmentation. This is another scenario that may lead to unpredictable results.
碎片化。这种特殊情况可能导致不可预测的结果。另一种可能的情况是通过IPsec保护TCP连接。如果攻击者报告的下一跳MTU小于报头所需的字节数（在本例中为IP和IPsec），则假定路径MTU甚至不允许受攻击系统发送TCP报头的单个字节而不出现碎片。这是另一种可能导致不可预测结果的情况。
For IPv4, the reported Next-Hop MTU could be as small as 68 octets, as [RFC0791] requires every internet module to be able to forward a datagram of 68 octets without further fragmentation. For IPv6, while the required minimum IPv6 MTU is 1280, the reported Next-Hop MTU can be smaller than 1280 octets [RFC2460]. If the reported Next-Hop MTU is smaller than the minimum IPv6 MTU, the receiving host is not required to reduce the Path-MTU to a value smaller than 1280, but is required to include a fragmentation header in the outgoing packets to that destination from that moment on.
对于IPv4，报告的下一跳MTU可能小到68个八位字节，因为[RFC0791]要求每个互联网模块能够转发68个八位字节的数据报，而无需进一步分段。对于IPv6，虽然要求的最小IPv6 MTU为1280，但报告的下一跳MTU可以小于1280个八位字节[RFC2460]。如果报告的下一跳MTU小于最小IPv6 MTU，则接收主机不需要将路径MTU减少到小于1280的值，但需要从那时起在到该目的地的传出数据包中包括分段头。
The IETF has standardized a Path-MTU Discovery mechanism called "Packetization Layer Path MTU Discovery" (PLPMTUD) that does not depend on ICMP error messages. Implementation of the aforementioned mechanism in replacement of the traditional PMTUD (specified in [RFC1191] and [RFC1981]) eliminates this vulnerability. However, it can also lead to an increase in PMTUD convergence time.
IETF标准化了一种称为“打包层路径MTU发现”（PLPMTUD）的路径MTU发现机制，该机制不依赖于ICMP错误消息。采用上述机制替代传统PMTUD（在[RFC1191]和[RFC1981]中指定）可消除此漏洞。然而，这也会导致PMTUD收敛时间的增加。
This section describes a modification to the PMTUD mechanism specified in [RFC1191] and [RFC1981] that has been incorporated in OpenBSD and NetBSD (since 2005) to improve TCP's resistance to the blind performance-degrading attack described in Section 7.1. The described counter-measure basically disregards ICMP messages when a connection makes progress, without violating any of the requirements stated in [RFC1191] and [RFC1981].
本节描述了对[RFC1191]和[RFC1981]中规定的PMTUD机制的修改，该机制已并入OpenBSD和NetBSD（自2005年以来），以提高TCP对第7.1节中所述的盲性能降级攻击的抵抗力。当连接进行时，所述反措施基本上忽略ICMP消息，而不违反[RFC1191]和[RFC1981]中规定的任何要求。
Henceforth, we will refer to both ICMPv4 "fragmentation needed and DF bit set" and ICMPv6 "Packet Too Big" messages as "ICMP Packet Too Big" messages.
此后，我们将ICMPv4“需要碎片和DF位设置”和ICMPv6“数据包太大”消息称为“ICMP数据包太大”消息。
In addition to the general validation check described in Section 4.1, these implementations include a modification to TCP's reaction to ICMP "Packet Too Big" error messages that disregards them when a connection makes progress, and honors them only after the corresponding data have been retransmitted a specified number of times. This means that upon receipt of an ICMP "Packet Too Big"
除了第4.1节中描述的一般验证检查外，这些实现还包括修改TCP对ICMP“数据包太大”错误消息的反应，该错误消息在连接进行时忽略这些消息，并且仅在相应的数据被重新传输指定次数后才予以尊重。这意味着在收到ICMP“数据包太大”时
error message, TCP just records this information, and honors it only when the corresponding data have already been retransmitted a specified number of times.
错误消息，TCP只记录此信息，并且仅当相应的数据已被重新传输指定次数时才接受此信息。
While this basic policy would greatly mitigate the impact of the attack against the PMTUD mechanism, it would also mean that it might take TCP more time to discover the Path-MTU for a TCP connection. This would be particularly annoying for connections that have just been established, as it might take TCP several transmission attempts (and the corresponding timeouts) before it discovers the PMTU for the corresponding connection. Thus, this policy would increase the time it takes for data to begin to be received at the destination host.
虽然此基本策略将极大地减轻针对PMTUD机制的攻击的影响，但也意味着TCP可能需要更多的时间来发现TCP连接的路径MTU。对于刚刚建立的连接来说，这尤其令人恼火，因为TCP可能需要多次传输尝试（以及相应的超时），然后才能发现相应连接的PMTU。因此，此策略将增加目标主机开始接收数据所需的时间。
In order to protect TCP from the attack against the PMTUD mechanism, while still allowing TCP to quickly determine the initial Path-MTU for a connection, the aforementioned implementations have divided the traditional PMTUD mechanism into two stages: Initial Path-MTU Discovery and Path-MTU Update.
为了保护TCP免受PMTUD机制的攻击，同时仍然允许TCP快速确定连接的初始路径MTU，上述实现将传统的PMTUD机制分为两个阶段：初始路径MTU发现和路径MTU更新。
The Initial Path-MTU Discovery stage is when TCP tries to send segments that are larger than the ones that have so far been sent and acknowledged for this connection. That is, in the Initial Path-MTU Discovery stage, TCP has no record of these large segments getting to the destination host, and thus these implementations believe the network when it reports that these packets are too large to reach the destination host without being fragmented.
初始路径MTU发现阶段是TCP尝试发送比迄今为止已发送并确认的连接段大的段时。也就是说，在初始路径MTU发现阶段，TCP没有这些大段到达目标主机的记录，因此这些实现在报告这些数据包太大而无法到达目标主机而不被碎片化时相信网络。
The Path-MTU Update stage is when TCP tries to send segments that are equal to or smaller than the ones that have already been sent and acknowledged for this connection. During the Path-MTU Update stage, TCP already has knowledge of the estimated Path-MTU for the given connection. Thus, in this case, these implementations are more cautious with the errors being reported by the network.
路径MTU更新阶段是TCP尝试发送等于或小于已发送并确认用于此连接的段的段。在路径MTU更新阶段，TCP已经知道给定连接的估计路径MTU。因此，在这种情况下，这些实现对网络报告的错误更加谨慎。
In order to allow TCP to distinguish segments between those performing Initial Path-MTU Discovery and those performing Path-MTU Update, two new variables are introduced to TCP: maxsizesent and maxsizeacked.
为了使TCP能够区分执行初始路径MTU发现和执行路径MTU更新的段，TCP中引入了两个新变量：maxsizesent和maxsizeacked。
The maxsizesent variable holds the size (in octets) of the largest packet that has so far been sent for this connection. It is initialized to 68 (the minimum IPv4 MTU) when the underlying Internet Protocol is IPv4, and is initialized to 1280 (the minimum IPv6 MTU) when the underlying Internet Protocol is IPv6. Whenever a packet larger than maxsizesent octets is sent, maxsizesent is set to that value.
maxsizesent变量保存迄今为止为此连接发送的最大数据包的大小（以八位字节为单位）。当基础Internet协议为IPv4时，它被初始化为68（最小IPv4 MTU），当基础Internet协议为IPv6时，它被初始化为1280（最小IPv6 MTU）。每当发送大于maxsizesent八位字节的数据包时，maxsizesent将设置为该值。
On the other hand, maxsizeacked holds the size (in octets) of the largest packet (data, plus headers) that has so far been acknowledged for this connection. It is initialized to 68 (the minimum IPv4 MTU) when the underlying Internet Protocol is IPv4, and is initialized to 1280 (the minimum IPv6 MTU) when the underlying Internet Protocol is IPv6. Whenever an acknowledgement for a packet larger than maxsizeacked octets is received, maxsizeacked is set to the size of that acknowledged packet. Note that because of TCP's cumulative acknowledgement, a single ACK may acknowledge the receipt of more than one packet. When that happens, the algorithm may "incorrectly" assume it is in the "Path-MTU Update" stage, rather than the "Initial Path-MTU Discovery" stage (as described below).
另一方面，maxsizecked保存迄今为止已确认的该连接的最大数据包（数据，加上报头）的大小（以八位字节为单位）。当基础Internet协议为IPv4时，它被初始化为68（最小IPv4 MTU），当基础Internet协议为IPv6时，它被初始化为1280（最小IPv6 MTU）。每当收到大于maxsizeacked八位字节的数据包的确认时，maxsizeacked被设置为该确认数据包的大小。请注意，由于TCP的累积确认，单个ACK可能会确认收到多个数据包。当这种情况发生时，算法可能“错误地”假设它处于“路径MTU更新”阶段，而不是“初始路径MTU发现”阶段（如下所述）。
Upon receipt of an ICMP "Packet Too Big" error message, the Next-Hop MTU claimed by the ICMP message (henceforth "claimedmtu") is compared with maxsizesent. If claimedmtu is larger than maxsizesent, then the ICMP error message is silently discarded. The rationale for this is that the ICMP error message cannot be legitimate if it claims to have been triggered by a packet larger than the largest packet we have so far sent for this connection.
在收到ICMP“数据包太大”错误消息后，将ICMP消息（此后称为“claimedmtu”）声明的下一跳MTU与maxsizesent进行比较。如果claimedmtu大于maxsizesent，则ICMP错误消息将自动丢弃。这样做的理由是，如果ICMP错误消息声称是由比我们迄今为止为此连接发送的最大数据包更大的数据包触发的，则ICMP错误消息不可能是合法的。
If this check is passed, claimedmtu is compared with maxsizeacked. If claimedmtu is equal to or larger than maxsizeacked, TCP is supposed to be at the Initial Path-MTU Discovery stage, and thus the ICMP "Packet Too Big" error message is honored immediately. That is, the assumed Path-MTU is updated according to the Next-Hop MTU claimed in the ICMP error message. Also, maxsizesent is reset to the minimum MTU of the Internet Protocol in use (68 for IPv4, and 1280 for IPv6).
如果此检查通过，则将claimedmtu与maxsizeacked进行比较。如果claimedmtu等于或大于MaxSizecked，则TCP应处于初始路径MTU发现阶段，因此ICMP“数据包太大”错误消息将立即生效。即，根据ICMP错误消息中声明的下一跳MTU更新假定路径MTU。此外，maxsizesent被重置为正在使用的Internet协议的最小MTU（IPv4为68，IPv6为1280）。
On the other hand, if claimedmtu is smaller than maxsizeacked, TCP is supposed to be in the Path-MTU Update stage. At this stage, these implementations are more cautious with the errors being reported by the network, and therefore just record the received error message, and delay the update of the assumed Path-MTU.
另一方面，如果claimedmtu小于maxsizecked，则TCP应该处于路径MTU更新阶段。在此阶段，这些实现对网络报告的错误更加谨慎，因此只记录接收到的错误消息，并延迟假定路径MTU的更新。
To perform this delay, one new variable and one new parameter are introduced to TCP: nsegrto and MAXSEGRTO. The nsegrto variable holds the number of times a specified segment has timed out. It is initialized to zero, and is incremented by one every time the corresponding segment times out. MAXSEGRTO specifies the number of times a given segment must time out before an ICMP "Packet Too Big" error message can be honored, and can be set, in principle, to any value greater than or equal to 0.
为了执行此延迟，TCP中引入了一个新变量和一个新参数：nsegrto和MAXSEGRTO。nsegrto变量保存指定段超时的次数。它被初始化为零，并在每次相应的段超时时递增1。MAXSEGRTO指定在接收ICMP“数据包太大”错误消息之前，给定数据段必须超时的次数，原则上可以设置为大于或等于0的任何值。
Thus, if nsegrto is greater than or equal to MAXSEGRTO, and there's a pending ICMP "Packet Too Big" error message, the corresponding error message is processed. At that point, maxsizeacked is set to claimedmtu, and maxsizesent is set to 68 (for IPv4) or 1280 (for IPv6).
因此，如果nsegrto大于或等于MAXSEGRTO，并且存在挂起的ICMP“数据包太大”错误消息，则会处理相应的错误消息。此时，maxsizeacked设置为claimedmtu，maxsizesent设置为68（对于IPv4）或1280（对于IPv6）。
If, while there is a pending ICMP "Packet Too Big" error message, the TCP SEQ claimed by the pending message is acknowledged (i.e., an ACK that acknowledges that sequence number is received), then the "pending error" condition is cleared.
如果在存在未决ICMP“数据包太大”错误消息时，确认了未决消息声明的TCP SEQ（即，确认接收到序列号的ACK），则清除“未决错误”条件。
The rationale behind performing this delayed processing of ICMP "Packet Too Big" messages is that if there is progress on the connection, the ICMP "Packet Too Big" errors must be a false claim. By checking for progress on the connection, rather than just for staleness of the received ICMP messages, TCP is protected from attack even if the offending ICMP messages are "in window", and as a corollary, is made more robust to spurious ICMP messages triggered by, for example, corrupted TCP segments.
执行此延迟处理ICMP“数据包过大”消息的基本原理是，如果连接有进展，ICMP“数据包过大”错误必须是错误声明。通过检查连接的进度，而不仅仅是检查接收到的ICMP消息是否过时，即使有问题的ICMP消息处于“窗口”中，TCP也可以免受攻击，因此，对于由损坏的TCP段等触发的虚假ICMP消息，TCP会变得更加健壮。
MAXSEGRTO can be set, in principle, to any value greater than or equal to 0. Setting MAXSEGRTO to 0 would make TCP perform the traditional PMTUD mechanism defined in [RFC1191] and [RFC1981]. A MAXSEGRTO of 1 provides enough protection for most cases. In any case, implementations are free to choose higher values for this constant. MAXSEGRTO could be a function of the Next-Hop MTU claimed in the received ICMP "Packet Too Big" message. That is, higher values for MAXSEGRTO could be imposed when the received ICMP "Packet Too Big" message claims a Next-Hop MTU that is smaller than some specified value. Both OpenBSD and NetBSD set MAXSEGRTO to 1.
原则上，可以将MAXSEGRTO设置为大于或等于0的任何值。将MAXSEGRTO设置为0将使TCP执行[RFC1191]和[RFC1981]中定义的传统PMTUD机制。MAXSEGRTO为1可为大多数情况提供足够的保护。在任何情况下，实现都可以为该常量自由选择更高的值。MAXSEGRTO可能是接收到的ICMP“数据包太大”消息中声明的下一跳MTU的函数。也就是说，当接收到的ICMP“Packet Too Big”（数据包太大）消息声称下一跳MTU小于某个指定值时，可以为MAXSEGRTO施加更高的值。OpenBSD和NetBSD都将MAXSEGRTO设置为1。
In the event a higher level of protection is desired at the expense of a higher delay in the discovery of the Path-MTU, an implementation could consider TCP to always be in the Path-MTU Update stage, thus always delaying the update of the assumed Path-MTU.
如果需要在路径MTU的发现中花费较高的延迟来保护更高级别，则实现可以考虑TCP始终处于路径MTU更新阶段，因此总是延迟假定路径MTU的更新。
Section 7.3 shows this counter-measure in action. Section 7.4 shows this counter-measure in pseudo-code.
第7.3节显示了该反措施的作用。第7.4节以伪代码的形式显示了这种反措施。
It is important to note that the mechanism described in this section is an improvement to the current Path-MTU discovery mechanism, to mitigate its security implications. The current PMTUD mechanism, as specified by [RFC1191] and [RFC1981], still suffers from some functionality problems [RFC2923] that this document does not aim to address. A mechanism that addresses those issues is described in [RFC4821].
需要注意的是，本节中描述的机制是对当前Path MTU发现机制的改进，以减轻其安全影响。[RFC1191]和[RFC1981]指定的当前PMTUD机制仍存在一些功能问题[RFC2923]，本文档不打算解决这些问题。[RFC4821]中描述了解决这些问题的机制。
This section illustrates the operation of the counter-measure for the ICMP attack against the PMTUD mechanism that has been implemented in OpenBSD and NetBSD. It shows both how the fix protects TCP from being attacked and how the counter-measure works in normal scenarios. As discussed in Section 7.2, this section assumes the PMTUD-specific counter-measure is implemented in addition to the TCP sequence number checking described in Section 4.1.
本节说明了针对已在OpenBSD和NetBSD中实现的PMTUD机制的ICMP攻击的反措施的操作。它显示了修复程序如何保护TCP不受攻击，以及在正常情况下反措施如何工作。如第7.2节所述，本节假设除第4.1节所述的TCP序列号检查外，还实施了特定于PMTUD的计数器措施。
Figure 1 illustrates a hypothetical scenario in which two hosts are connected by means of three intermediate routers. It also shows the MTU of each hypothetical hop. All the following subsections assume the network setup of this figure.
图1演示了一个假设场景，其中两台主机通过三个中间路由器连接。它还显示了每个假设跃点的MTU。以下所有小节均假定此图的网络设置。
Also, for simplicity's sake, all subsections assume an IP header of 20 octets and a TCP header of 20 octets. Thus, for example, when the PMTU is assumed to be 1500 octets, TCP will send segments that contain, at most, 1460 octets of data.
此外，为了简单起见，所有小节都假定IP报头为20个八位字节，TCP报头为20个八位字节。因此，例如，当假定PMTU为1500个八位字节时，TCP将发送最多包含1460个八位字节数据的段。
For simplicity's sake, all the following subsections assume the TCP implementation at Host 1 (H1) has chosen a MAXSEGRTO of 1.
为了简单起见，以下所有小节都假设主机1（H1）上的TCP实现选择了MAXSEGRTO为1。
+----+ +----+ +----+ +----+ +----+
| H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 |
+----+ +----+ +----+ +----+ +----+
MTU=4464 MTU=2048 MTU=1500 MTU=4464
+----+ +----+ +----+ +----+ +----+
| H1 |--------| R1 |--------| R2 |--------| R3 |--------| H2 |
+----+ +----+ +----+ +----+ +----+
MTU=4464 MTU=2048 MTU=1500 MTU=4464
Figure 1: Hypothetical Scenario
图1：假设情景
This subsection shows the counter-measure in normal operation, when a TCP connection is used for bulk transfers. That is, it shows how the counter-measure works when there is no attack taking place and a TCP connection is used for transferring large amounts of data. This section assumes that just after the connection is established, one of the TCP endpoints begins to transfer data in packets that are as large as possible.
本小节显示了当TCP连接用于批量传输时，正常操作中的计数器措施。也就是说，它显示了在没有发生攻击并且TCP连接用于传输大量数据时，反措施是如何工作的。本节假设在建立连接之后，其中一个TCP端点开始以尽可能大的数据包传输数据。
Host 1 Host 2
主机1主机2
1. --> <SEQ=100><CTL=SYN> -->
2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=4424> -->
5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1
6. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=2008> -->
7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2
8. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=1460> -->
9. <-- <SEQ=X+1><ACK=1561><CTL=ACK> <--
1. --> <SEQ=100><CTL=SYN> -->
2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=4424> -->
5. <--- ICMP "Packet Too Big" MTU=2048, TCPseq#=101 <--- R1
6. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=2008> -->
7. <--- ICMP "Packet Too Big" MTU=1500, TCPseq#=101 <--- R2
8. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=1460> -->
9. <-- <SEQ=X+1><ACK=1561><CTL=ACK> <--
Figure 2: Normal Operation for Bulk Transfers
图2：批量传输的正常操作
The nsegrto variable is initialized to zero. Both maxsizeacked and maxsizesent are initialized to the minimum MTU for the Internet Protocol being used (68 for IPv4, and 1280 for IPv6).
nsegrto变量初始化为零。maxsizeacked和maxsizesent都被初始化为所使用的Internet协议的最小MTU（IPv4为68，IPv6为1280）。
In lines 1 to 3, the three-way handshake takes place, and the connection is established. In line 4, H1 tries to send a full-sized TCP segment. As described by [RFC1191] and [RFC1981], in this case, TCP will try to send a segment with 4424 bytes of data, which will result in an IP packet of 4464 octets. Therefore, maxsizesent is set to 4464. When the packet reaches R1, it elicits an ICMP "Packet Too Big" error message.
在第1到第3行中，发生三方握手，并建立连接。在第4行中，H1尝试发送一个完整大小的TCP段。如[RFC1191]和[RFC1981]所述，在这种情况下，TCP将尝试发送包含4424字节数据的段，这将产生4464个八位字节的IP数据包。因此，maxsizesent设置为4464。当数据包到达R1时，它会引发ICMP“数据包太大”错误消息。
In line 5, H1 receives the ICMP error message, which reports a Next-Hop MTU of 2048 octets. After performing the TCP sequence number check described in Section 4.1, the Next-Hop MTU reported by the ICMP error message (claimedmtu) is compared with maxsizesent. As it is smaller than maxsizesent, it passes the check, and thus is then compared with maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes that the corresponding TCP segment was performing the Initial PMTU Discovery. Therefore, the TCP at H1 honors the ICMP message by updating the assumed Path-MTU. The maxsizesent variable is reset to the minimum MTU of the Internet Protocol in use (68 for IPv4, and 1280 for IPv6).
在第5行中，H1接收ICMP错误消息，该消息报告2048个八位字节的下一跳MTU。执行第4.1节所述的TCP序列号检查后，将ICMP错误消息（claimedmtu）报告的下一跳MTU与maxsizesent进行比较。由于它小于maxsizesent，因此通过检查，然后与maxsizeacked进行比较。由于claimedmtu大于maxsizeacked，TCP假定相应的TCP段正在执行初始PMTU发现。因此，H1的TCP通过更新假定的路径MTU来尊重ICMP消息。maxsizesent变量被重置为正在使用的Internet协议的最小MTU（IPv4为68，IPv6为1280）。
In line 6, the TCP at H1 sends a segment with 2008 bytes of data, which results in an IP packet of 2048 octets. The maxsizesent variable is thus set to 2008 bytes. When the packet reaches R2, it elicits an ICMP "Packet Too Big" error message.
在第6行中，H1处的TCP发送一个包含2008字节数据的段，这导致一个2048个八位字节的IP数据包。因此，maxsizesent变量设置为2008字节。当数据包到达R2时，它会引发ICMP“数据包太大”错误消息。
In line 7, H1 receives the ICMP error message, which reports a Next-Hop MTU of 1500 octets. After performing the TCP sequence number check, the Next-Hop MTU reported by the ICMP error message (claimedmtu) is compared with maxsizesent. As it is smaller than maxsizesent, it passes the check, and thus is then compared with
在第7行中，H1接收ICMP错误消息，该消息报告下一跳MTU为1500个八位字节。执行TCP序列号检查后，将ICMP错误消息（claimedmtu）报告的下一跳MTU与maxsizesent进行比较。由于它小于maxsizesent，因此通过检查，然后与
maxsizeacked. As claimedmtu is larger than maxsizeacked, TCP assumes that the corresponding TCP segment was performing the Initial PMTU Discovery. Therefore, the TCP at H1 honors the ICMP message by updating the assumed Path-MTU. The maxsizesent variable is reset to the minimum MTU of the Internet Protocol in use.
麦克斯笑了。由于claimedmtu大于maxsizeacked，TCP假定相应的TCP段正在执行初始PMTU发现。因此，H1的TCP通过更新假定的路径MTU来尊重ICMP消息。maxsizesent变量被重置为正在使用的Internet协议的最小MTU。
In line 8, the TCP at H1 sends a segment with 1460 bytes of data, which results in an IP packet of 1500 octets. Thus, maxsizesent is set to 1500. This packet reaches H2, where it elicits an acknowledgement (ACK) segment.
在第8行中，H1处的TCP发送一个包含1460字节数据的段，这将产生1500个八位字节的IP数据包。因此，maxsizesent设置为1500。该数据包到达H2，在H2中它引发确认（ACK）段。
In line 9, H1 finally gets the acknowledgement for the data segment. As the corresponding packet was larger than maxsizeacked, TCP updates maxsizeacked, setting it to 1500. At this point, TCP has discovered the Path-MTU for this TCP connection.
在第9行中，H1最终获得数据段的确认。由于相应的数据包大于maxsizeacked，TCP更新maxsizeacked，将其设置为1500。此时，TCP已发现此TCP连接的路径MTU。
Let us suppose a TCP connection between H1 and H2 has already been established, and that the PMTU for the connection has already been discovered to be 1500. At this point, both maxsizesent and maxsizeacked are equal to 1500, and nsegrto is equal to 0. Suppose some time later the PMTU decreases to 1492. For simplicity, let us suppose that the Path-MTU has decreased because the MTU of the link between R2 and R3 has decreased from 1500 to 1492. Figure 3 illustrates how the counter-measure would work in this scenario.
假设已经建立了H1和H2之间的TCP连接，并且已经发现该连接的PMTU为1500。此时，maxsizesent和maxsizecked都等于1500，nsegrto等于0。假设一段时间后，PMTU降至1492。为了简单起见，让我们假设路径MTU已经减少，因为R2和R3之间链路的MTU已经从1500减少到1492。图3说明了反措施在该场景中的工作方式。
Host 1 Host 2
主机1主机2
1. (Path-MTU decreases)
2. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2
4. (Segment times out)
5. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1452> -->
6. <-- <SEQ=X><ACK=1552><CTL=ACK> <--
1. (Path-MTU decreases)
2. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
3. <--- ICMP "Packet Too Big" MTU=1492, TCPseq#=100 <--- R2
4. (Segment times out)
5. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1452> -->
6. <-- <SEQ=X><ACK=1552><CTL=ACK> <--
Figure 3: Operation during Path-MTU Changes
图3：路径MTU更改期间的操作
In line 1, the Path-MTU for this connection decreases from 1500 to 1492. In line 2, the TCP at H1, without being aware of the Path-MTU change, sends a 1500-byte packet to H2. When the packet reaches R2, it elicits an ICMP "Packet Too Big" error message.
在第1行中，此连接的路径MTU从1500减少到1492。在第2行中，H1处的TCP在不知道路径MTU更改的情况下向H2发送1500字节的数据包。当数据包到达R2时，它会引发ICMP“数据包太大”错误消息。
In line 3, H1 receives the ICMP error message, which reports a Next-Hop MTU of 1492 octets. After performing the TCP sequence number check, the Next-Hop MTU reported by the ICMP error message (claimedmtu) is compared with maxsizesent. As claimedmtu is smaller than maxsizesent, it is then compared with maxsizeacked. As
在第3行中，H1接收ICMP错误消息，该消息报告1492个八位字节的下一跳MTU。执行TCP序列号检查后，将ICMP错误消息（claimedmtu）报告的下一跳MTU与maxsizesent进行比较。由于claimedmtu小于maxsizesent，因此将其与maxsizeacked进行比较。像
claimedmtu is smaller than maxsizeacked (full-sized packets were getting to the remote endpoint), this packet is assumed to be performing Path-MTU Update, and a "pending error" condition is recorded.
claimedmtu小于maxsizeacked（全尺寸数据包到达远程端点），假定此数据包正在执行路径MTU更新，并记录“挂起错误”情况。
In line 4, the segment times out. Thus, nsegrto is incremented by 1. As nsegrto is greater than or equal to MAXSEGRTO, the assumed Path-MTU is updated. The nsegrto variable is reset to 0, maxsizeacked is set to claimedmtu, and maxsizesent is set to the minimum MTU of the Internet Protocol in use.
在第4行中，段超时。因此，nsegrto增加1。当nsegrto大于或等于MAXSEGRTO时，将更新假定路径MTU。nsegrto变量重置为0，maxsizeacked设置为claimedmtu，maxsizesent设置为正在使用的Internet协议的最小MTU。
In line 5, H1 retransmits the data using the updated PMTU, and thus maxsizesent is set to 1492. The resulting packet reaches H2, where it elicits an acknowledgement (ACK) segment.
在第5行中，H1使用更新的PMTU重新传输数据，因此maxsizesent设置为1492。产生的数据包到达H2，在那里它引发确认（ACK）段。
In line 6, H1 finally gets the acknowledgement for the data segment. At this point, TCP has discovered the new Path-MTU for this TCP connection.
在第6行中，H1最终获得数据段的确认。此时，TCP已发现此TCP连接的新路径MTU。
Let us suppose a TCP connection between H1 and H2 has already been established, and the PMTU for the connection has already been discovered to be 1500. Figure 4 shows a sample time-line diagram that illustrates an idle connection being attacked.
假设已经建立了H1和H2之间的TCP连接，并且已经发现该连接的PMTU为1500。图4显示了一个示例时间线图，它说明了一个被攻击的空闲连接。
Host 1 Host 2
主机1主机2
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=50> -->
2. <-- <SEQ=X><ACK=150><CTL=ACK> <--
3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=50> -->
2. <-- <SEQ=X><ACK=150><CTL=ACK> <--
3. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
4. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
Figure 4: Idle Connection Being Attacked
图4：被攻击的空闲连接
In line 1, H1 sends its last bunch of data. In line 2, H2 acknowledges the receipt of these data. Then the connection becomes idle. In lines 3, 4, and 5, an attacker sends forged ICMP "Packet Too Big" error messages to H1. Regardless of how many packets it sends and of the TCP sequence number each ICMP packet includes, none of these ICMP error messages will pass the TCP sequence number check described in Section 4.1, as H1 has no unacknowledged data "in flight" to H2. Therefore, the attack does not succeed.
在第1行中，H1发送其最后一组数据。在第2行中，H2确认收到这些数据。然后连接变为空闲。在第3、4和5行中，攻击者向H1发送伪造的ICMP“数据包太大”错误消息。无论发送多少数据包以及每个ICMP数据包包含多少TCP序列号，这些ICMP错误消息都不会通过第4.1节所述的TCP序列号检查，因为H1没有“正在传输”到H2的未确认数据。因此，攻击没有成功。
Let us suppose an attacker attacks a TCP connection for which the PMTU has already been discovered. In this case, as illustrated in Figure 1, the PMTU would be found to be 1500 bytes. Figure 5 shows a possible packet exchange.
假设攻击者攻击已发现PMTU的TCP连接。在这种情况下，如图1所示，将发现PMTU为1500字节。图5显示了一个可能的数据包交换。
Host 1 Host 2
主机1主机2
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
2. --> <SEQ=1560><ACK=X><CTL=ACK><DATA=1460> -->
3. --> <SEQ=3020><ACK=X><CTL=ACK><DATA=1460> -->
4. --> <SEQ=4480><ACK=X><CTL=ACK><DATA=1460> -->
5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
6. <-- <SEQ=X><CTL=ACK><ACK=1560> <--
1. --> <SEQ=100><ACK=X><CTL=ACK><DATA=1460> -->
2. --> <SEQ=1560><ACK=X><CTL=ACK><DATA=1460> -->
3. --> <SEQ=3020><ACK=X><CTL=ACK><DATA=1460> -->
4. --> <SEQ=4480><ACK=X><CTL=ACK><DATA=1460> -->
5. <--- ICMP "Packet Too Big" MTU=68, TCPseq#=100 <---
6. <-- <SEQ=X><CTL=ACK><ACK=1560> <--
Figure 5: Active Connection Being Attacked after Discovery of PMTU
图5：发现PMTU后被攻击的活动连接
As we assume the PMTU has already been discovered, we also assume both maxsizesent and maxsizeacked are equal to 1500. We assume nsegrto is equal to zero, as there have been no segment timeouts.
由于我们假设已经发现PMTU，我们还假设maxsizesent和maxsizeacked都等于1500。我们假设nsegrto等于零，因为没有段超时。
In lines 1, 2, 3, and 4, H1 sends four data segments to H2. In line 5, an attacker sends a forged ICMP error message to H1. We assume the attacker is lucky enough to guess both the four-tuple that identifies the connection and a valid TCP sequence number. As the Next-Hop MTU claimed in the ICMP "Packet Too Big" message (claimedmtu) is smaller than maxsizeacked, this packet is assumed to be performing Path-MTU Update. Thus, the error message is recorded.
在第1、2、3和4行中，H1向H2发送四个数据段。在第5行中，攻击者向H1发送伪造的ICMP错误消息。我们假设攻击者幸运地猜到了标识连接的四元组和有效的TCP序列号。由于ICMP“Packet to Big”（数据包太大）消息（claimedmtu）中声明的下一跳MTU小于MaxSizecked，因此假定该数据包正在执行路径MTU更新。因此，将记录错误消息。
In line 6, H1 receives an acknowledgement for the segment sent in line 1, before it times out. At this point, the "pending error" condition is cleared, and the recorded ICMP "Packet Too Big" error message is ignored. Therefore, the attack does not succeed.
在第6行中，H1在超时之前接收第1行中发送的段的确认。此时，“挂起的错误”条件被清除，记录的ICMP“数据包太大”错误消息被忽略。因此，攻击没有成功。
7.3.5. TCP Peer Attacked when Sending Small Packets Just after the Three-Way Handshake
7.3.5. 在三次握手后发送小数据包时，TCP对等方受到攻击
This section analyzes a scenario in which a TCP peer that is sending small segments just after the connection has been established is attacked. The connection could be in use by protocols such as SMTP [RFC5321] and HTTP [RFC2616], for example, which usually behave like this.
本节分析了一个场景，在该场景中，在建立连接后发送小段的TCP对等方受到攻击。例如，SMTP[RFC5321]和HTTP[RFC2616]等协议可以使用该连接，它们的行为通常如下所示。
Figure 6 shows a possible packet exchange for such a scenario.
图6显示了这种情况下可能的数据包交换。
Host 1 Host 2
主机1主机2
1. --> <SEQ=100><CTL=SYN> -->
2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=100> -->
5. <-- <SEQ=X+1><ACK=201><CTL=ACK> <--
6. --> <SEQ=201><ACK=X+1><CTL=ACK><DATA=100> -->
7. --> <SEQ=301><ACK=X+1><CTL=ACK><DATA=100> -->
8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=201 <---
1. --> <SEQ=100><CTL=SYN> -->
2. <-- <SEQ=X><ACK=101><CTL=SYN,ACK> <--
3. --> <SEQ=101><ACK=X+1><CTL=ACK> -->
4. --> <SEQ=101><ACK=X+1><CTL=ACK><DATA=100> -->
5. <-- <SEQ=X+1><ACK=201><CTL=ACK> <--
6. --> <SEQ=201><ACK=X+1><CTL=ACK><DATA=100> -->
7. --> <SEQ=301><ACK=X+1><CTL=ACK><DATA=100> -->
8. <--- ICMP "Packet Too Big" MTU=150, TCPseq#=201 <---
Figure 6: TCP Peer Attacked when Sending Small Packets Just after the Three-Way Handshake
图6：三方握手后发送小数据包时TCP对等攻击
The nsegrto variable is initialized to zero. Both maxsizesent and maxsizeacked are initialized to the minimum MTU for the Internet Protocol being used (68 for IPv4, and 1280 for IPv6).
nsegrto变量初始化为零。maxsizesent和maxsizeacked都被初始化为所使用的Internet协议的最小MTU（IPv4为68，IPv6为1280）。
In lines 1 to 3, the three-way handshake takes place, and the connection is established. At this point, the assumed Path-MTU for this connection is 4464. In line 4, H1 sends a small segment (which results in a 140-byte packet) to H2. Therefore, maxsizesent is set to 140. In line 5, this segment is acknowledged, and thus maxsizeacked is set to 140.
在第1到第3行中，发生三方握手，并建立连接。此时，此连接的假定路径MTU为4464。在第4行中，H1向H2发送一个小段（结果是一个140字节的数据包）。因此，maxsizesent设置为140。在第5行中，该段被确认，因此maxsizeacked被设置为140。
In lines 6 and 7, H1 sends two small segments to H2. In line 8, while the segments from lines 6 and 7 are still "in flight" to H2, an attacker sends a forged ICMP "Packet Too Big" error message to H1. Assuming the attacker is lucky enough to guess a valid TCP sequence number, this ICMP message will pass the TCP sequence number check. The Next-Hop MTU reported by the ICMP error message (claimedmtu) is then compared with maxsizesent. As claimedmtu is larger than maxsizesent, the ICMP error message is silently discarded. Therefore, the attack does not succeed.
在第6行和第7行中，H1向H2发送两个小段。在第8行中，当第6行和第7行的数据段仍在“飞行”到H2时，攻击者向H1发送伪造的ICMP“数据包太大”错误消息。假设攻击者幸运地猜到了有效的TCP序列号，则此ICMP消息将通过TCP序列号检查。然后将ICMP错误消息（claimedmtu）报告的下一跳MTU与maxsizesent进行比较。由于claimedmtu大于maxsizesent，ICMP错误消息将被自动丢弃。因此，攻击没有成功。
7.4. Pseudo-Code for the Counter-Measure for the Blind Performance-Degrading Attack
7.4. 针对盲性能下降攻击的对策伪码
This section contains a pseudo-code version of the counter-measure described in Section 7.2 for the blind performance-degrading attack described in Section 7. It is meant as guidance for developers on how to implement this counter-measure.
本节包含第7.2节中描述的针对第7节中描述的盲性能降低攻击的反措施的伪代码版本。这是为了指导开发者如何实施这一对策。
The pseudo-code makes use of the following variables, constants, and functions:
伪代码使用以下变量、常量和函数：
ack Variable holding the acknowledgement number contained in the TCP segment that has just been received.
ack变量，该变量保存刚刚接收到的TCP段中包含的确认号。
acked_packet_size Variable holding the packet size (data, plus headers) that the ACK that has just been received is acknowledging.
acked_packet_size变量，该变量保存刚刚收到的ACK正在确认的数据包大小（数据，加上报头）。
adjust_mtu() Function that adjusts the MTU for this connection, according to the ICMP "Packet Too Big" that was last received.
adjust_mtu（）函数，用于根据上次收到的ICMP“数据包太大”调整此连接的mtu。
claimedmtu Variable holding the Next-Hop MTU advertised by the ICMP "Packet Too Big" error message.
claimedmtu变量，包含ICMP“数据包太大”错误消息播发的下一跳MTU。
claimedtcpseq Variable holding the TCP sequence number contained in the payload of the ICMP "Packet Too Big" message that has just been received or was last recorded.
claimedtcpseq变量，该变量包含刚刚收到或上次记录的ICMP“数据包太大”消息的有效负载中包含的TCP序列号。
current_mtu Variable holding the assumed Path-MTU for this connection.
保存此连接的假定路径mtu的当前_mtu变量。
drop_message() Function that performs the necessary actions to drop the ICMP message being processed.
drop_message（）函数，用于执行删除正在处理的ICMP消息所需的操作。
initial_mtu Variable holding the MTU for new connections, as explained in [RFC1191] and [RFC1981].
初始mtu变量为新连接保存mtu，如[RFC1191]和[RFC1981]中所述。
maxsizeacked Variable holding the largest packet size (data, plus headers) that has so far been acked for this connection, as explained in Section 7.2.
maxsizeacked变量，包含迄今为止为该连接确认的最大数据包大小（数据，加上报头），如第7.2节所述。
maxsizesent Variable holding the largest packet size (data, plus headers) that has so far been sent for this connection, as explained in Section 7.2.
maxsizesent变量，保存迄今为止为该连接发送的最大数据包大小（数据，加上报头），如第7.2节所述。
nsegrto Variable holding the number of times this segment has timed out, as explained in Section 7.2.
如第7.2节所述，nsegrto变量保存此段超时的次数。
packet_size Variable holding the size of the IP datagram being sent.
packet_size变量，用于保存正在发送的IP数据报的大小。
pending_message Variable (flag) that indicates whether there is a pending ICMP "Packet Too Big" message to be processed.
pending_消息变量（标志），指示是否有待处理的挂起ICMP“数据包太大”消息。
save_message() Function that records the ICMP "Packet Too Big" message that has just been received.
save_message（）函数，用于记录刚刚收到的ICMP“数据包太大”消息。
MINIMUM_MTU Constant holding the minimum MTU for the Internet Protocol in use (68 for IPv4, and 1280 for IPv6).
MINIMUM_MTU常量，用于保存正在使用的Internet协议的最小MTU（IPv4为68，IPv6为1280）。
MAXSEGRTO Constant holding the number of times a given segment must time out before an ICMP "Packet Too Big" error message can be honored.
MAXSEGRTO常量，表示在接收ICMP“数据包太大”错误消息之前，给定段必须超时的次数。
EVENT: New TCP connection
事件：新建TCP连接
current_mtu = initial_mtu;
maxsizesent = MINIMUM_MTU;
maxsizeacked = MINIMUM_MTU;
nsegrto = 0;
pending_message = 0;
current_mtu = initial_mtu;
maxsizesent = MINIMUM_MTU;
maxsizeacked = MINIMUM_MTU;
nsegrto = 0;
pending_message = 0;
EVENT: Segment is sent
事件：发送段
if (packet_size > maxsizesent) maxsizesent = packet_size;
如果（数据包大小>maxsizesent）maxsizesent=数据包大小；
EVENT: Segment is received
事件：收到段
if (acked_packet_size > maxsizeacked) maxsizeacked = acked_packet_size;
如果（acked_packet_size>maxsizecked）maxsizecked=acked_packet_size；
if (pending_message)
if (ack > claimedtcpseq){
pending_message = 0;
nsegrto = 0;
}
if (pending_message)
if (ack > claimedtcpseq){
pending_message = 0;
nsegrto = 0;
}
EVENT: ICMP "Packet Too Big" message is received
事件：收到ICMP“数据包太大”消息
if (claimedmtu <= MINIMUM_MTU)
drop_message();
if (claimedmtu <= MINIMUM_MTU)
drop_message();
if (claimedtcpseq < SND.UNA || claimedtcpseq >= SND.NXT)
drop_message();
if (claimedtcpseq < SND.UNA || claimedtcpseq >= SND.NXT)
drop_message();
else {
if (claimedmtu > maxsizesent || claimedmtu >= current_mtu)
drop_message();
else {
if (claimedmtu > maxsizesent || claimedmtu >= current_mtu)
drop_message();
else {
if (claimedmtu > maxsizeacked){
adjust_mtu();
current_mtu = claimedmtu;
maxsizesent = MINIMUM_MTU;
}
else {
if (claimedmtu > maxsizeacked){
adjust_mtu();
current_mtu = claimedmtu;
maxsizesent = MINIMUM_MTU;
}
else {
pending_message = 1;
save_message();
}
}
}
else {
pending_message = 1;
save_message();
}
}
}
EVENT: Segment times out
事件：段超时
nsegrto++;
nsegrto++;
if (pending_message && nsegrto >= MAXSEGRTO){
adjust_mtu();
nsegrto = 0;
pending_message = 0;
maxsizeacked = claimedmtu;
maxsizesent = MINIMUM_MTU;
current_mtu = claimedmtu;
}
if (pending_message && nsegrto >= MAXSEGRTO){
adjust_mtu();
nsegrto = 0;
pending_message = 0;
maxsizeacked = claimedmtu;
maxsizesent = MINIMUM_MTU;
current_mtu = claimedmtu;
}
Notes: All comparisons between sequence numbers must be performed using sequence number arithmetic.
注：序列号之间的所有比较都必须使用序列号算法进行。
The pseudo-code implements the mechanism described in Section 7.2, the TCP sequence number checking described in Section 4.1, and the validation check on the advertised Next-Hop MTU described in [RFC1191] and [RFC1981].
伪代码实现了第7.2节中描述的机制、第4.1节中描述的TCP序列号检查以及[RFC1191]和[RFC1981]中描述的对公布的下一跳MTU的验证检查。
This document describes the use of ICMP error messages to perform a number of attacks against TCP, and describes a number of widely implemented counter-measures that either eliminate or reduce the impact of these attacks when they are performed by off-path attackers.
本文档描述了使用ICMP错误消息对TCP执行的一系列攻击，并描述了一些广泛实施的应对措施，这些措施可以消除或减少非路径攻击者执行这些攻击时的影响。
Section 4.1 describes a validation check that could be enforced on ICMP error messages, such that TCP reacts only to those ICMP error messages that appear to relate to segments currently "in flight" to the destination system. This requires more effort on the side of an off-path attacker at the expense of possible reduced responsiveness to network errors.
第4.1节描述了可对ICMP错误消息实施的验证检查，以便TCP仅对那些似乎与当前“飞行”到目标系统的段相关的ICMP错误消息作出反应。这需要路径外攻击者付出更多的努力，代价是可能降低对网络错误的响应能力。
Section 4.2 describes how randomization of TCP ephemeral ports requires more effort on the side of the attacker to successfully exploit any of the attacks described in this document.
第4.2节描述了TCP临时端口的随机化需要攻击者付出更多努力才能成功利用本文档中描述的任何攻击。
Section 4.3 describes how ICMP error messages could possibly be filtered based on their payload, to prevent users of the local network from successfully performing attacks against third-party connections. This is analogous to ingress filtering and egress filtering of IP packets [IP-filtering].
第4.3节描述了如何根据有效载荷过滤ICMP错误消息，以防止本地网络用户成功执行针对第三方连接的攻击。这类似于IP数据包的入口过滤和出口过滤[IP过滤]。
Section 5.2 describes an attack-specific counter-measure for the blind connection-reset attack. It describes the processing of ICMP "hard errors" as "soft errors" when they are received for connections in any of the synchronized states. This counter-measure eliminates the aforementioned vulnerability in synchronized connections at the expense of possible reduced responsiveness in some network scenarios.
第5.2节描述了针对盲连接重置攻击的特定攻击对策。它将ICMP“硬错误”的处理描述为在任何同步状态下接收连接时的“软错误”。此反措施消除了同步连接中的上述漏洞，但在某些网络场景中可能会降低响应能力。
Section 6.2 describes an attack-specific counter-measure for the blind throughput-reduction attack. It suggests that the aforementioned vulnerability can be eliminated by ignoring ICMPv4 Source Quench messages meant for TCP connections. This is in accordance with research results that indicate that ICMPv4 Source Quench messages are ineffective and are an unfair antidote for congestion.
第6.2节描述了针对盲吞吐量降低攻击的特定攻击对策。这表明，可以通过忽略用于TCP连接的ICMPv4源猝灭消息来消除上述漏洞。这与研究结果一致，研究结果表明ICMPv4源猝灭消息无效，是不公平的拥塞解药。
Finally, Section 7.2 describes an attack-specific counter-measure for the blind performance-degrading attack. It consists of the validation check described in Section 4.1, with a modification that makes TCP react to ICMP "Packet Too Big" error messages such that they are processed when an outstanding TCP segment times out. This counter-measure parallels the Packetization Layer Path MTU Discovery (PLPMTUD) mechanism [RFC4821]. It should be noted that if this counter-measure is implemented, in some scenarios TCP may respond more slowly to valid ICMP "Packet Too Big" error messages.
最后，第7.2节描述了针对盲性能下降攻击的特定攻击对策。它包括第4.1节中描述的验证检查，并进行了修改，使TCP对ICMP“数据包太大”错误消息作出反应，以便在未完成的TCP段超时时处理这些错误消息。此计数器措施与打包层路径MTU发现（PLPMTUD）机制[RFC4821]并行。应该注意的是，如果实施此计数器措施，在某些情况下，TCP对有效ICMP“数据包太大”错误消息的响应可能会更慢。
A discussion of these and other attack vectors for performing similar attacks against TCP (along with possible counter-measures) can be found in [CPNI-TCP] and [TCP-SECURITY].
在[CPNI-TCP]和[TCP-SECURITY]中可以找到对这些和其他攻击向量进行类似TCP攻击（以及可能的对策）的讨论。
This document was inspired by Mika Liljeberg, while discussing some issues related to [RFC5461] by private e-mail. The author would like to thank (in alphabetical order): Bora Akyol, Mark Allman, Ran Atkinson, James Carlson, Alan Cox, Theo de Raadt, Wesley Eddy, Lars Eggert, Ted Faber, Juan Fraschini, Markus Friedl, Guillermo Gont, John Heffner, Alfred Hoenes, Vivek Kakkar, Michael Kerrisk, Mika Liljeberg, Matt Mathis, David Miller, Toby Moncaster, Miles Nordin, Eloy Paris, Kacheong Poon, Andrew Powell, Pekka Savola, Donald Smith, Pyda Srisuresh, Fred Templin, and Joe Touch for contributing many valuable comments.
本文档受Mika Liljeberg的启发，同时通过私人电子邮件讨论了与[RFC5461]相关的一些问题。作者要感谢（按字母顺序）：波拉·阿克约尔、马克·奥尔曼、冉·阿特金森、詹姆斯·卡尔森、艾伦·考克斯、西奥·德·拉阿德、韦斯利·艾迪、拉尔斯·艾格特、特德·费伯、胡安·弗拉希尼、马库斯·弗里德尔、吉列尔莫·贡特、约翰·赫夫纳、阿尔弗雷德·霍恩斯、维韦克·卡卡尔、迈克尔·克里克斯、米卡·利耶贝格、马特·马蒂斯、大卫·米勒、托比·蒙卡斯特、，Miles Nordin、Eloy Paris、Kacheong Poon、安德鲁·鲍威尔、佩卡·萨沃拉、唐纳德·史密斯、皮达·斯里苏雷什、弗雷德·坦普林和乔·图奇发表了许多有价值的评论。
Juan Fraschini and the author of this document implemented freely available audit tools to help vendors audit their systems by reproducing the attacks discussed in this document. These tools are available at http://www.gont.com.ar/tools/index.html.
Juan Fraschini和本文档作者实现了免费提供的审计工具，通过复制本文档中讨论的攻击，帮助供应商审计其系统。这些工具可在http://www.gont.com.ar/tools/index.html.
Markus Friedl, Chad Loder, and the author of this document produced and tested in OpenBSD [OpenBSD] the first implementation of the counter-measure described in Section 7.2. This first implementation helped to test the effectiveness of the ideas introduced in this document, and has served as a reference implementation for other operating systems.
Markus Friedl、Chad Loder和本文件作者在OpenBSD[OpenBSD]中制作并测试了第7.2节所述的第一个反措施实施。第一次实现有助于测试本文档中介绍的思想的有效性，并作为其他操作系统的参考实现。
The author would like to thank the UK's Centre for the Protection of National Infrastructure (CPNI) -- formerly the National Infrastructure Security Co-ordination Centre (NISCC) -- for coordinating the disclosure of these issues with a large number of vendors and CSIRTs (Computer Security Incident Response Teams).
作者要感谢英国国家基础设施保护中心（CPNI）——前身为国家基础设施安全协调中心（NISCC）——与大量供应商和CSIRT（计算机安全事件响应团队）协调披露这些问题。
The author wishes to express deep and heartfelt gratitude to Jorge Oscar Gont and Nelida Garcia, for their precious motivation and guidance.
作者希望向豪尔赫·奥斯卡·贡特和内丽达·加西亚表示深切和衷心的感谢，感谢他们的宝贵动机和指导。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[RFC4884]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“支持多部分消息的扩展ICMP”，RFC 4884，2007年4月。
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", http://www.cpni.gov.uk/ Docs/tn-03-09-security-assessment-TCP.pdf, 2009.
[CPNI-TCP]CPNI，“传输控制协议（TCP）的安全评估”，http://www.cpni.gov.uk/ 文件/tn-03-09-security-assessment-TCP.pdf，2009年。
[DClark] Clark, D., "The Design Philosophy of the DARPA Internet Protocols", Computer Communication Review Vol. 18, No. 4, 1988.
[DClark]Clark，D.，“DARPA互联网协议的设计哲学”，《计算机通信评论》第18卷，第4期，1988年。
[FreeBSD] The FreeBSD Project, http://www.freebsd.org.
[FreeBSD]FreeBSD项目，http://www.freebsd.org.
[ICMP-Filtering] Gont, F., "Filtering of ICMP error messages", http ://www.gont.com.ar/papers/ filtering-of-icmp-error-messages.pdf.
[ICMP过滤]Gont，F.，“ICMP错误消息的过滤”，http://www.Gont.com.ar/papers/Filtering-of-ICMP-error-messages.pdf。
[IP-filtering] NISCC, "NISCC Technical Note 01/2006: Egress and Ingress Filtering", http://www.cpni.gov.uk/Docs/re-20060420-00294.pdf, 2006.
[IP过滤]NISCC，“NISCC技术说明01/2006：进出过滤”，http://www.cpni.gov.uk/Docs/re-20060420-00294.pdf, 2006.
[Linux] The Linux Project, "http://www.kernel.org".
[Linux]Linux项目，”http://www.kernel.org".
[McKusick] McKusick, M., Bostic, K., Karels, M., and J. Quarterman, "The Design and Implementation of the 4.4 BSD Operating System", Addison-Wesley, 1996.
[McKusick]McKusick，M.，Bostic，K.，Karels，M.，和J.Quarterman，“4.4 BSD操作系统的设计和实现”，Addison Wesley，1996年。
[NISCC] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ ICMP: Vulnerability Issues in ICMP packets with TCP payloads", http://www.cpni.gov.uk/docs/ re-20050412-00303.pdf?lang=en, 2005.
[NISCC]NISCC，“NISCC漏洞咨询532967/NISCC/ICMP：具有TCP有效负载的ICMP数据包中的漏洞问题”，http://www.cpni.gov.uk/docs/ re-20050412-00303.pdf？lang=en，2005年。
[NetBSD] The NetBSD Project, "http://www.netbsd.org".
[NetBSD]NetBSD项目，“http://www.netbsd.org".
[OpenBSD] The OpenBSD Project, "http://www.openbsd.org".
[OpenBSD]OpenBSD项目http://www.openbsd.org".
[OpenBSD-PF] The OpenBSD Packet Filter, "http://www.openbsd.org/faq/pf/".
[OpenBSD PF]OpenBSD数据包筛选器，“http://www.openbsd.org/faq/pf/".
[PORT-RANDOM] Larsen, M. and F. Gont, "Transport Protocol Port Randomization Recommendations", Work in Progress, April 2010.
[PORT-RANDOM]Larsen，M.和F.Gont，“运输协议端口随机化建议”，正在进行的工作，2010年4月。
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, July 1982.
[RFC0816]Clark，D.，“故障隔离和恢复”，RFC 816，1982年7月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[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月。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，2002年10月。
[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月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4907] Aboba, B., "Architectural Implications of Link Indications", RFC 4907, June 2007.
[RFC4907]Aboba，B.“连接指示的建筑影响”，RFC 4907，2007年6月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]Touch，J.“保护TCP免受欺骗攻击”，RFC 4953，2007年7月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC5461]Gont，F.，“TCP对软错误的反应”，RFC 54612009年2月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[TCP-SECURITY] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, February 2010.
[TCP-SECURITY]Gont，F.，“传输控制协议（TCP）的安全评估”，正在进行的工作，2010年2月。
[TCPM-TCPSECURE] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, May 2010.
[TCPM-TCPSECURE]Ramaiah，A.，Stewart，R.，和M.Dalal，“提高TCP对窗口内盲攻击的鲁棒性”，正在进行的工作，2010年5月。
[US-CERT] US-CERT, "US-CERT Vulnerability Note VU#222750: TCP/IP Implementations do not adequately validate ICMP error messages", http://www.kb.cert.org/vuls/id/222750, 2005.
[US-CERT]US-CERT，“US-CERT漏洞注意事项VU#222750:TCP/IP实施未充分验证ICMP错误消息”，http://www.kb.cert.org/vuls/id/222750, 2005.
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", CanSecWest Conference, 2004.
[Watson]Watson，P.，“在窗口中滑动：TCP重置攻击”，CanSecWest会议，2004年。
[Wright] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1994.
[Wright]Wright，G.和W.Stevens，“TCP/IP图解，第2卷：实现”，Addison-Wesley，1994年。
Author's Address
作者地址
Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
阿根廷布宜诺斯艾利斯省费尔南多·冈特国家技术大学/学院地区哈多·埃瓦里斯托·卡里戈2644哈多1706
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar
URI: http://www.gont.com.ar
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar
URI: http://www.gont.com.ar