Internet Engineering Task Force (IETF) M. Bashyam
Request for Comments: 6429 Ocarina Networks, Inc.
Category: Informational M. Jethanandani
ISSN: 2070-1721 A. Ramaiah
Cisco
December 2011
Internet Engineering Task Force (IETF) M. Bashyam
Request for Comments: 6429 Ocarina Networks, Inc.
Category: Informational M. Jethanandani
ISSN: 2070-1721 A. Ramaiah
Cisco
December 2011
TCP Sender Clarification for Persist Condition
持久条件的TCP发送方澄清
Abstract
摘要
This document clarifies the Zero Window Probes (ZWPs) described in RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122.
本文件澄清了RFC 1122（“互联网主机要求——通信层”）中描述的零窗口探测（ZWPs）。特别是，它阐明了在遇到ZWP情况的连接上可以采取的措施。本文件没有对标准进行更改，而是澄清了迄今为止RFC 1122中规定的对标准的误解。
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/rfc6429.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6429.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
1.1. Requirements Language ......................................3
2. Discussion of RFC 1122 Requirement ..............................3
3. Description of One Simple Attack ................................4
4. Clarification Regarding RFC 1122 Requirements ...................5
5. Security Considerations .........................................5
6. Acknowledgments .................................................5
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Discussion of RFC 1122 Requirement ..............................3
3. Description of One Simple Attack ................................4
4. Clarification Regarding RFC 1122 Requirements ...................5
5. Security Considerations .........................................5
6. Acknowledgments .................................................5
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
Section 4.2.2.17 of "Requirements for Internet Hosts -- Communication Layers" [RFC1122] says:
“互联网主机要求——通信层”[RFC1122]第4.2.2.17节规定：
"A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open.
TCP可能会无限期地关闭其提供的接收窗口。只要接收TCP继续发送确认以响应探测段，发送TCP必须允许连接保持打开状态。
DISCUSSION:
讨论：
It is extremely important to remember that ACK (acknowledgment) segments that contain no data are not reliably transmitted by TCP".
务必记住，不包含数据的ACK（确认）段不能通过TCP可靠传输”。
Therefore, zero window probing needs to be supported to prevent a connection from hanging forever if ACK segments that re-open the window are lost. The condition where the sender goes into the Zero Window Probe (ZWP) mode is typically known as the 'persist condition'.
因此，如果重新打开窗口的ACK段丢失，则需要支持零窗口探测以防止连接永久挂起。发送方进入零窗口探测（ZWP）模式的情况通常称为“持续状态”。
This guidance is not intended to preclude resource management by the operating system or application, which may request that connections be aborted regardless of whether or not they are in the persist condition. The TCP implementation needs to, of course, comply by aborting such connections. If such resource management is not performed external to the protocol implementation, TCP implementations that misinterpret Section 4.2.2.17 of [RFC1122] have the potential to make systems vulnerable to denial-of-service (DoS) [RFC4732] scenarios where attackers tie up resources by keeping connections in the persist condition.
本指南并非旨在排除操作系统或应用程序的资源管理，操作系统或应用程序可能会请求中止连接，而不管连接是否处于持久状态。当然，TCP实现需要通过中止此类连接来遵守。如果未在协议实施外部执行此类资源管理，则误解[RFC1122]第4.2.2.17节的TCP实施有可能使系统易受拒绝服务（DoS）[RFC4732]情况的攻击，在这种情况下，攻击者通过保持连接处于持续状态来占用资源。
Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122 [RFC1122].
本文件没有对标准进行更改，而是澄清了迄今为止RFC 1122[RFC1122]中规定的对标准的误解。
Section 2 of this document describes why implementations might not close connections merely because they are in the persist condition, yet need to still allow such connections to be closed on command. Section 3 outlines a simple attack on systems that do not sufficiently manage connections in this state. Section 4 concludes with a requirements-language clarification to the RFC 1122 requirement.
本文档的第2节描述了为什么实现可能不会仅仅因为连接处于持久状态而关闭连接，但仍然需要允许在命令下关闭此类连接。第3节概述了对在这种状态下无法充分管理连接的系统的简单攻击。第4节最后对RFC 1122需求进行了需求语言澄清。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Per [RFC1122], as long as the ACKs are being received for window probes, a connection can continue to stay in the persist condition. This is an important feature, because applications typically would want the TCP connection to stay open unless an application explicitly closes the connection.
根据[RFC1122]，只要接收到用于窗口探测的ACK，连接就可以继续保持持续状态。这是一个重要特性，因为应用程序通常希望TCP连接保持打开状态，除非应用程序显式关闭连接。
For example, take the case of a user running a network print job during which the printer runs out of paper and is waiting for the user to reload the paper tray (user intervention). The printer may not be reading data from the printing application during this time.
例如，以用户运行网络打印作业为例，在此期间，打印机用完纸张，等待用户重新装入纸盘（用户干预）。在此期间，打印机可能没有从打印应用程序读取数据。
Although this may result in a prolonged ZWP state, it would be premature for TCP to take action on its own and close the printer connection merely due to its lack of progress. Once the printer's paper tray is reloaded (which may be minutes, hours, or days later), the print job needs to be able to continue uninterrupted over the same TCP connection.
虽然这可能会导致ZWP状态延长，但TCP单独采取行动并仅因为没有进展而关闭打印机连接还为时过早。重新装入打印机的纸盘后（可能是几分钟、几小时或几天后），打印作业需要能够通过相同的TCP连接不间断地继续进行。
However, systems that misinterpret Section 4.2.2.17 of [RFC1122] may fall victim to DoS attacks by not supporting sufficient mechanisms to allow release of system resources tied up by connections in the persist condition during times of resource exhaustion. For example, take the case of a busy server where multiple (attacker) clients can advertise a zero window forever (by reliably acknowledging the ZWPs). This could eventually lead to resource exhaustion in the server system. In such cases, the application or operating system would need to take appropriate action on the TCP connection to reclaim their resources and continue to maintain legitimate connections.
但是，误解[RFC1122]第4.2.2.17节的系统可能会成为DoS攻击的受害者，因为它不支持足够的机制来允许在资源耗尽期间释放持久状态下由连接捆绑的系统资源。例如，以繁忙的服务器为例，其中多个（攻击者）客户端可以永久播发零窗口（通过可靠地确认ZWPs）。这最终可能导致服务器系统中的资源耗尽。在这种情况下，应用程序或操作系统需要对TCP连接采取适当的操作，以回收其资源并继续维护合法连接。
The problem is applicable to TCP and TCP-derived flow-controlled transport protocols such as the Stream Control Transmission Protocol (SCTP).
该问题适用于TCP和TCP派生的流控制传输协议，如流控制传输协议（SCTP）。
Clearly, a system needs to be robust to such attacks and allow connections in the persist condition to be aborted in the same way as any other connection. Section 4 of this document provides the requisite clarification to permit such resource management.
显然，系统需要对此类攻击具有鲁棒性，并允许以与任何其他连接相同的方式中止处于持久状态的连接。本文件第4节提供了允许此类资源管理的必要澄清。
To illustrate a potential DoS scenario, consider the case where many client applications open TCP connections with an HTTP [RFC2616] server, and each sends a GET request for a large page and stops reading the response partway through. This causes the client's TCP implementation to advertise a zero window to the server. For every large HTTP response, the server is left holding on to the response data in its sending queue. The amount of response data held will depend on the size of the send buffer and the advertised window. If the clients never read the data in their receive queues and therefore do not clear the persist condition, the server will continue to hold that data indefinitely. Since there may be a limit to the operating system kernel memory available for TCP buffers, this may result in DoS to legitimate connections by locking up the necessary resources. If the above scenario persists for an extended period of time, it will lead to starvation of TCP buffers and connection blocks, causing legitimate existing connections and new connection attempts to fail.
为了说明一个潜在的DOS场景，考虑许多客户端应用程序与HTTP[RFC2616]服务器打开TCP连接的情况，每个服务器发送一个大页面的GET请求，并停止读取响应。这会导致客户端的TCP实现向服务器播发零窗口。对于每个大型HTTP响应，服务器保留其发送队列中的响应数据。保留的响应数据量将取决于发送缓冲区和播发窗口的大小。如果客户端从未读取其接收队列中的数据，因此未清除持久条件，则服务器将继续无限期地保留该数据。由于可用于TCP缓冲区的操作系统内核内存可能会受到限制，这可能会通过锁定必要的资源而导致对合法连接的拒绝。如果上述情况持续较长时间，将导致TCP缓冲区和连接块不足，导致合法的现有连接和新连接尝试失败。
A clever application needs to detect such attacks with connections that are not making progress, and could close these connections.
一个聪明的应用程序需要通过没有进展的连接来检测此类攻击，并可能关闭这些连接。
However, some applications might have transferred all the data to the TCP socket and subsequently closed the socket, leaving the connections with no controlling process; such connections are referred to as orphaned connections. These orphaned connections might be left holding the data indefinitely in their sending queue.
但是，有些应用程序可能已经将所有数据传输到TCP套接字，然后关闭套接字，使连接没有控制过程；这种连接称为孤立连接。这些孤立连接可能会在其发送队列中无限期地保留数据。
The US Computer Emergency Readiness Team (CERT) has released an advisory in this regard [VU723308] and is making vendors aware of this DoS scenario.
美国计算机应急准备小组（CERT）就此发布了一条建议[VU723308]，并让供应商了解这种DoS情况。
As stated in [RFC1122], a TCP implementation MUST NOT close a connection merely because it seems to be stuck in the ZWP or persist condition. Though unstated in RFC 1122, but implicit for system robustness, a TCP implementation needs to allow connections in the ZWP or persist condition to be closed or aborted by their applications or other resource management routines in the operating system.
如[RFC1122]中所述，TCP实现不能仅仅因为连接似乎处于ZWP或持久状态而关闭连接。尽管RFC 1122中未说明，但对于系统健壮性而言，TCP实现需要允许ZWP或PERSISTER条件中的连接被其应用程序或操作系统中的其他资源管理例程关闭或中止。
An interface that allows an application to inform TCP on what to do when the connection stays in the persist condition, or that allows an application or other resource manager to query the health of the TCP connection, is considered outside the scope of this document. All such techniques, however, are in complete compliance with TCP [RFC0793] and [RFC1122].
允许应用程序在连接处于持久状态时通知TCP执行什么操作的接口，或允许应用程序或其他资源管理器查询TCP连接的运行状况的接口，不在本文档的范围内。然而，所有这些技术都完全符合TCP[RFC0793]和[RFC1122]。
This document discusses one system security consideration that is listed in "Guidelines for Writing RFC Text on Security Considerations" [RFC3552]. In particular, it describes an inappropriate use of a system that is acting as a server for many users. That use and a possible DoS attack are discussed in Section 3.
本文件讨论了“关于安全注意事项的RFC文本编写指南”[RFC3552]中列出的一个系统安全注意事项。特别是，它描述了对作为许多用户的服务器的系统的不当使用。第3节讨论了这种使用和可能的DoS攻击。
This document limits itself to clarifying RFC 1122. It does not discuss what can happen with orphaned connections and other possible mitigation techniques, as these are considered outside the scope of this document.
本文件仅限于澄清RFC 1122。本节不讨论孤立连接和其他可能的缓解技术会发生什么情况，因为这些都不在本文档的范围内。
This document was inspired by the recent discussions that took place regarding the TCP persist condition issue in the TCP Maintenance and Minor Extensions (TCPM) Working Group mailing list [TCPM]. The outcome of those discussions was to come up with a document that would clarify the intentions of the ZWP as discussed in RFC 1122. We
本文档的灵感来源于最近在TCP维护和小型扩展（TCPM）工作组邮件列表[TCPM]中就TCP持久化条件问题进行的讨论。这些讨论的结果是提出一份文件，澄清RFC 1122中讨论的ZWP的意图。我们
would like to thank Mark Allman, Ted Faber, and David Borman for clarifying the objective behind this document. Thanks also go to Wesley Eddy for his extensive editorial comments and to Dan Wing, Mark Allman, and Fernando Gont for providing feedback on this document.
感谢Mark Allman、Ted Faber和David Borman澄清本文件背后的目标。还感谢卫斯理·艾迪（Wesley Eddy）的广泛评论，以及丹·温（Dan Wing）、马克·奥尔曼（Mark Allman）和费尔南多·冈特（Fernando Gont）对本文件的反馈。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[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月。
[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月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Ed.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 47322006年12月。
[TCPM] IETF, "TCP Maintenance and Minor Extensions (tcpm) - Charter", <http://datatracker.ietf.org/wg/tcpm/charter/>.
[TCPM]IETF，“TCP维护和小型扩展（TCPM）-章程”<http://datatracker.ietf.org/wg/tcpm/charter/>.
[VU723308] Manion, A. and D. Warren, "TCP may keep its offered receive window closed indefinitely (RFC 1122)", November 2009, <http://www.kb.cert.org/vuls/id/723308>.
[VU723308]Manion，A.和D.Warren，“TCP可能会无限期关闭其提供的接收窗口（RFC 1122）”，2009年11月<http://www.kb.cert.org/vuls/id/723308>.
Authors' Addresses
作者地址
Murali Bashyam Ocarina Networks, Inc. 42 Airport Parkway San Jose, CA 95110 USA
Murali Bashyam Ocarina Networks，Inc.美国加利福尼亚州圣何塞机场大道42号，邮编95110
Phone: +1 (408) 512-2966
EMail: mbashyam@ocarinanetworks.com
Phone: +1 (408) 512-2966
EMail: mbashyam@ocarinanetworks.com
Mahesh Jethanandani Cisco 170 Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道170号，邮编95134
Phone: +1 (408) 527-8230
EMail: mjethanandani@gmail.com
Phone: +1 (408) 527-8230
EMail: mjethanandani@gmail.com
Anantha Ramaiah Cisco 170 Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道170号，邮编95134
Phone: +1 (408) 525-6486
EMail: ananth@cisco.com
Phone: +1 (408) 525-6486
EMail: ananth@cisco.com