Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6633 UTN-FRH / SI6 Networks
Updates: 792, 1122, 1812 May 2012
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6633 UTN-FRH / SI6 Networks
Updates: 792, 1122, 1812 May 2012
Category: Standards Track
ISSN: 2070-1721
Deprecation of ICMP Source Quench Messages
ICMP源消息的弃用
Abstract
摘要
This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812.
本文档正式反对传输协议使用ICMP源猝灭消息，正式更新RFC 792、RFC 1122和RFC 1812。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6633.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6633.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. ICMP Source Quench Messages .....................................3
3. Updating RFC 1122 ...............................................3
4. Updating RFC 1812 ...............................................4
5. Clarification for UDP, SCTP, and DCCP ...........................4
6. General Advice to Transport Protocols ...........................4
7. Recommendation Regarding RFC 1016 ...............................5
8. Security Considerations .........................................5
9. IANA Considerations .............................................5
10. Acknowledgements ...............................................5
11. References .....................................................6
11.1. Normative References ......................................6
11.2. Informative References ....................................7
Appendix A. Survey of Support of ICMP Source Quench in Some
Popular TCP/IP Implementations ........................8
1. Introduction ....................................................2
2. ICMP Source Quench Messages .....................................3
3. Updating RFC 1122 ...............................................3
4. Updating RFC 1812 ...............................................4
5. Clarification for UDP, SCTP, and DCCP ...........................4
6. General Advice to Transport Protocols ...........................4
7. Recommendation Regarding RFC 1016 ...............................5
8. Security Considerations .........................................5
9. IANA Considerations .............................................5
10. Acknowledgements ...............................................5
11. References .....................................................6
11.1. Normative References ......................................6
11.2. Informative References ....................................7
Appendix A. Survey of Support of ICMP Source Quench in Some
Popular TCP/IP Implementations ........................8
The ICMP specification [RFC0792] defined the ICMP Source Quench message (type 4, code 0), which was meant as a mechanism for congestion control. ICMP Source Quench has been known to be an ineffective (and unfair) antidote for congestion, and generation of ICMP Source Quench messages by routers has been formally deprecated by [RFC1812] since 1995. However, reaction to ICMP Source Quench messages in transport protocols has never been formally deprecated.
ICMP规范[RFC0792]定义了ICMP源猝灭消息（类型4，代码0），该消息用于拥塞控制机制。众所周知，ICMP源猝灭是一种无效（且不公平）的拥塞解药，自1995年以来，[RFC1812]正式反对通过路由器生成ICMP源猝灭消息。然而，传输协议中对ICMP源猝灭消息的反应从未被正式否决过。
This document formally deprecates reaction to ICMP Source Quench messages by transport protocols such as TCP [RFC0793], formally updating [RFC0792], [RFC1122], and [RFC1812]. Additionally, it provides a recommendation against the implementation of [RFC1016]. The rationale for these specification updates is as follows:
本文档正式反对通过传输协议（如TCP[RFC0793]、正式更新[RFC0792]、[RFC1122]和[RFC1812]对ICMP源猝灭消息的反应。此外，它还针对[RFC1016]的实施提出了建议。这些规范更新的基本原理如下：
o Processing of ICMP Source Quench messages by routers has been deprecated for nearly 17 years [RFC1812].
o 路由器对ICMP源猝灭消息的处理已被弃用近17年[RFC1812]。
o Virtually all popular host implementations have removed support for ICMP Source Quench messages since (at least) 2005 [RFC5927].
o 自（至少）2005年[RFC5927]以来，几乎所有流行的主机实现都取消了对ICMP源猝灭消息的支持。
o Widespread deployment of ICMP filtering makes it impossible to rely on ICMP Source Quench messages for congestion control.
o ICMP过滤的广泛部署使得不可能依靠ICMP源猝灭消息进行拥塞控制。
o The IETF has moved away from ICMP Source Quench messages for congestion control (e.g., note the development of Explicit Congestion Notification (ECN) [RFC3168] and the fact that ICMPv6 [RFC4443] does not even specify a Source Quench message).
o IETF已经不再使用ICMP源猝灭消息进行拥塞控制（例如，请注意显式拥塞通知（ECN）[RFC3168]的开发以及ICMPv6[RFC4443]甚至没有指定源猝灭消息的事实）。
ICMP Source Quench messages are not normally seen in the deployed Internet and were considered rare at least as far back as 1994 [Floyd1994].
ICMP源猝灭消息通常不会在部署的Internet中看到，至少早在1994年就被认为是罕见的[Floyd1994]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The ICMP specification [RFC0792] defined the ICMP Source Quench message (type 4, code 0), which was meant to provide a mechanism for congestion control. The Host Requirements RFC [RFC1122] stated in Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages by slowing transmission on the connection, and further added that the RECOMMENDED procedure was to put the corresponding connection in the slow-start phase of TCP's congestion control algorithm [RFC5681].
ICMP规范[RFC0792]定义了ICMP源猝灭消息（类型4，代码0），旨在提供拥塞控制机制。主机要求RFC[RFC1122]在第4.2.3.9节中规定，主机必须通过减慢连接上的传输来对ICMP源猝灭消息作出反应，并进一步补充，建议的程序是将相应的连接置于TCP拥塞控制算法[RFC5681]的慢启动阶段。
[RFC1812] noted that research suggested that ICMP Source Quench was an ineffective (and unfair) antidote for congestion, and formally deprecated the generation of ICMP Source Quench messages by routers, stating that routers SHOULD NOT send ICMP Source Quench messages in response to congestion.
[RFC1812]指出，研究表明ICMP源猝灭是一种无效（且不公平）的拥塞解药，并正式反对路由器生成ICMP源猝灭消息，指出路由器不应发送ICMP源猝灭消息以响应拥塞。
[RFC5927] discussed the use of ICMP Source Quench messages for performing "blind throughput-reduction" attacks, and noted that most TCP implementations silently ignore ICMP Source Quench messages.
[RFC5927]讨论了使用ICMP源猝灭消息执行“盲吞吐量降低”攻击，并指出大多数TCP实现都会默默忽略ICMP源猝灭消息。
We note that TCP implements its own congestion control mechanisms [RFC5681] [RFC3168], which do not depend on ICMP Source Quench messages.
我们注意到TCP实现了自己的拥塞控制机制[RFC5681][RFC3168]，它不依赖于ICMP源猝灭消息。
It is interesting to note that ICMPv6 [RFC4443] does not specify a Source Quench message.
值得注意的是，ICMPv6[RFC4443]没有指定源猝灭消息。
This document hereby updates Section 3.2.2.3 of [RFC1122] as follows:
本文件在此更新[RFC1122]第3.2.2.3节如下：
A host MUST NOT send ICMP Source Quench messages.
主机不得发送ICMP源终止消息。
If a Source Quench message is received, the IP layer MAY silently discard it.
如果接收到源猝灭消息，IP层可能会自动丢弃该消息。
Section 4.2.3.9 of [RFC1122] is updated as follows:
[RFC1122]第4.2.3.9节更新如下：
TCP MUST silently discard any received ICMP Source Quench messages.
TCP必须以静默方式放弃任何接收到的ICMP源消息。
The consensus of the TSV WG was that there are no valid reasons for a host to generate or react to an ICMP Source Quench message in the current Internet. The recommendation that a sender "MUST NOT" send an ICMP Source Quench message is because there is no known valid reason for a host to generate this message. The only known impact of a sender ignoring this requirement is that it may necessarily consume network and endpoint resources. Discarding ICMP Source Quench messages at the Internet layer (rather than at the transport layer) is a performance optimization that is permitted by this update.
TSV工作组的共识是，在当前的互联网上，主机没有有效的理由生成ICMP源信息或对ICMP源信息作出反应。建议发送方“不得”发送ICMP源猝灭消息是因为主机生成此消息的原因不明。发送方忽略此要求的唯一已知影响是，它可能会消耗网络和端点资源。在Internet层（而不是传输层）丢弃ICMP源猝灭消息是此更新允许的性能优化。
This document hereby updates Section 4.3.3.3 of [RFC1812] as follows:
本文件在此更新[RFC1812]第4.3.3.3节如下：
A router MUST ignore any ICMP Source Quench messages it receives.
路由器必须忽略它接收到的任何ICMP源猝灭消息。
The consensus of the TSV WG was that there are no valid reasons for a router to react to ICMP Source Quench messages in the current Internet.
TSV工作组的共识是，在当前的互联网上，路由器对ICMP源猝灭消息做出反应是没有正当理由的。
UDP [RFC0768] did not explicitly specify support for ICMP Source Quench messages. Hereby, we clarify that UDP endpoints MUST silently discard received ICMP Source Quench messages.
UDP[RFC0768]未明确指定对ICMP源消息的支持。因此，我们澄清UDP端点必须静默地丢弃接收到的ICMP源消息。
It is understood that SCTP [RFC4960] and DCCP [RFC4340] did not specify support for processing received ICMP Source Quench messages. Hereby, we clarify that DCCP and SCTP endpoints MUST silently discard received ICMP Source Quench messages.
可以理解的是，SCTP[RFC4960]和DCCP[RFC4340]没有指定对处理接收到的ICMP源猝灭消息的支持。在此，我们澄清DCCP和SCTP端点必须静默地丢弃接收到的ICMP源消息。
If a Source Quench message is received by any other transport-protocol instance, it MUST be silently ignored.
如果任何其他传输协议实例接收到源猝灭消息，则必须以静默方式忽略该消息。
The TSV WG is not aware of any mechanism that requires processing of these messages and therefore expects other transports to follow the recommendations in Section 3. Note that since generation of ICMP Source Quench messages has been deprecated for many years, and since this document additionally deprecates reaction to ICMP Source Quench messages by IETF-specified transports, future applications cannot expect to receive these messages.
TSV工作组不知道需要处理这些消息的任何机制，因此希望其他传输遵循第3节中的建议。请注意，由于ICMP源猝灭消息的生成已被弃用多年，并且由于本文档还弃用了IETF指定传输对ICMP源猝灭消息的反应，因此未来的应用程序无法期望收到这些消息。
[RFC1016] describes an experimental approach to the handling of ICMP Source Quench messages in hosts that was considered in 1987. Even though RFC 1016 has never been on the IETF Standards Track, for clarity and avoidance of doubt we note that the approach described in [RFC1016] MUST NOT be implemented.
[RFC1016]描述了1987年考虑的在主机中处理ICMP源猝灭消息的实验方法。尽管RFC 1016从未出现在IETF标准轨道上，但为了清晰和避免疑问，我们注意到不得实施[RFC1016]中描述的方法。
ICMP Source Quench messages could be leveraged for performing blind throughput-reduction attacks against TCP and similar protocols. This attack vector, along with possible countermeasures, has been discussed in great detail in [RFC5927] and [CPNI-TCP]. Silently ignoring ICMP Source Quench messages, as specified in this document, eliminates the aforementioned attack vector.
ICMP源猝灭消息可用于对TCP和类似协议执行盲吞吐量降低攻击。这种攻击向量，以及可能的对策，已经在[RCF5927 ]和[CPNi-TCP ]中详细讨论。如本文中所指定的，无视ICMP源猝灭消息，消除上述攻击向量。
For current TCP implementations, receipt of an ICMP Source Quench message should not result in security issues because, as noted in [RFC5927] and [CPNI-TCP], virtually all current versions of popular TCP implementations already silently ignore ICMP Source Quench messages. This is also the case for SCTP and DCCP implementations.
对于当前的TCP实现，接收ICMP源猝灭消息不应导致安全问题，因为如[RFC5927]和[CPNI-TCP]中所述，几乎所有当前版本的流行TCP实现都已默认忽略ICMP源猝灭消息。SCTP和DCCP实现也是如此。
Hosts, security gateways, and firewalls MUST silently discard received ICMP Source Quench packets and SHOULD log such drops as a security fault with at least minimal details (IP Source Address, IP Destination Address, ICMP message type, and date/time the packet was seen).
主机、安全网关和防火墙必须以静默方式丢弃接收到的ICMP源猝灭数据包，并应至少以最少的详细信息（IP源地址、IP目标地址、ICMP消息类型和看到数据包的日期/时间）将此类丢弃记录为安全故障。
We note that security devices such as the Snort Network Intrusion Detection System (NIDS) have logged ICMP Source Quench messages as such for more than ten years [Anderson2002].
我们注意到，Snort网络入侵检测系统（NIDS）等安全设备已经记录ICMP源猝灭消息十多年了[Anderson2002]。
IANA has marked ICMP type 4 (Source Quench) as "Deprecated" in the ICMP Parameters registry [ICMPPARREG] with a reference to this document.
IANA已在ICMP参数注册表[ICMPPARREG]中将ICMP类型4（源猝灭）标记为“已弃用”，并引用了本文档。
The author of this document would like to thank Ran Atkinson, who contributed text that was incorporated into this document and also provided valuable feedback on earlier versions of this document.
本文件的作者要感谢Ran Atkinson，他提供了纳入本文件的文本，并就本文件的早期版本提供了宝贵的反馈。
The author of this document would like to thank (in alphabetical order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh
本文件的作者（按字母顺序）感谢弗雷德·贝克、大卫·布莱克、斯科特·布拉德纳、詹姆斯·卡尔森、安东尼奥·德·西蒙尼、韦斯利·艾迪、戈里·费尔赫斯特、阿尔弗雷德·霍恩斯、马赫什
Jethanandani, Kathleen Moriarty, Carlos Pignataro, James Polk, Anantha Ramaiah, Randall Stewart, Dan Wing, and Andrew Yourtchenko, for providing valuable feedback on earlier versions of this document. This document has also benefited from discussions within the TCPM Working Group while working on [RFC5927].
Jethanandani、Kathleen Moriarty、Carlos Pignataro、James Polk、Anantha Ramaiah、Randall Stewart、Dan Wing和Andrew Yourtchenko为本文件的早期版本提供了宝贵的反馈。本文件还得益于TCPM工作组在研究[RFC5927]时进行的讨论。
Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and Guillermo Gont for their love and support.
费尔南多·贡特感谢豪尔赫·奥斯卡·贡特、内丽达·加西亚和吉列尔莫·贡特对他的爱和支持。
Fernando Gont's attendance to IETF meetings was supported by ISOC's "Fellowship to the IETF" program.
费尔南多·冈特出席IETF会议得到了ISOC“IETF奖学金”计划的支持。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[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月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[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月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[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月。
[Anderson2002] Anderson, D., Fong, M., and A. Valdes, "Heterogeneous Sensor Correlation: A Case Study of Live Traffic Analysis", Proceedings of the 3rd Annual IEEE Information Assurance Workshop New York, NY, USA, 2002.
[Anderson 2002]Anderson，D.，Fong，M.，和A.Valdes，“异构传感器相关性：实时流量分析的案例研究”，第三届IEEE信息保障年度研讨会论文集，纽约，纽约，美国，2002年。
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf>.
[CPNI-TCP]CPNI，“传输控制协议（TCP）的安全评估”，2009年<http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf>。
[Floyd1994] Floyd, S., "TCP and Explicit Congestion Notification", ACM CCR New York, NY, Volume 24, Issue 5, October 1994.
[Floyd1994]Floyd，S.，“TCP和显式拥塞通知”，纽约州纽约ACM CCR，第24卷，第5期，1994年10月。
[FreeBSD] The FreeBSD Project, <http://www.freebsd.org>.
[FreeBSD]FreeBSD项目<http://www.freebsd.org>.
[ICMPPARREG] IANA, "Internet Control Message Protocol (ICMP) Parameters", <http://www.iana.org/assignments/icmp-parameters>.
[ICMPPareg]IANA，“互联网控制消息协议（ICMP）参数”<http://www.iana.org/assignments/icmp-parameters>.
[Linux] The Linux Project, <http://www.kernel.org>.
[Linux]Linux项目<http://www.kernel.org>.
[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>.
[OpenSolaris] OpenSolaris, <http://www.opensolaris.org>.
[OpenSolaris]OpenSolaris<http://www.opensolaris.org>.
[RFC1016] Prue, W. and J. Postel, "Something a host could do with source quench: The Source Quench Introduced Delay (SQuID)", RFC 1016, July 1987.
[RFC1016]Prue，W.和J.Postel，“主机与源猝灭的关系：源猝灭引入延迟（SQuID）”，RFC 1016，1987年7月。
[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月。
[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月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927]Gont，F.，“针对TCP的ICMP攻击”，RFC 5927，2010年7月。
Appendix A. Survey of Support of ICMP Source Quench in Some Popular TCP/IP Implementations
附录A.在一些流行的TCP/IP实现中对ICMP源猝灭的支持调查
A large number of implementations completely ignore ICMP 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], OpenBSD [OpenBSD], and Solaris 10 since 2005. Additionally, OpenSolaris [OpenSolaris] has always shipped with support for ICMP Source Quench messages disabled.
许多实现完全忽略了用于TCP连接的ICMP源猝灭消息。自2004年以来，至少在Linux[Linux]中实现了此行为，自2005年以来，在FreeBSD[FreeBSD]、NetBSD[NetBSD]、OpenBSD[OpenBSD]和Solaris 10中实现了此行为。此外，OpenSolaris[OpenSolaris]始终附带对禁用的ICMP源消息的支持。
Author's Address
作者地址
Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont UTN-FRH/SI6 Networks Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com