TCP Sender Clarification for Persist Condition
RFC 6429
Document | Type | RFC - Informational (December 2011; No errata) | |
---|---|---|---|
Authors | Murali Bashyam , Anantha Ramaiah , Mahesh Jethanandani | ||
Last updated | 2015-10-14 | ||
Replaces | draft-ananth-tcpm-persist | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6429 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Wesley Eddy | ||
IESG note | Michael Scharf (michael.scharf@alcatel-lucent.com) is the document shepherd. | ||
Send notices to | (None) |
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 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. 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. 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. Bashyam, et al. Informational [Page 1] RFC 6429 TCP Persist Condition December 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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. 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 Section 4.2.2.17 of "Requirements for Internet Hosts -- Communication Layers" [RFC1122] says: "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. DISCUSSION: It is extremely important to remember that ACK (acknowledgment) segments that contain no data are not reliably transmitted by TCP". Bashyam, et al. Informational [Page 2] RFC 6429 TCP Persist Condition December 2011 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'. 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. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard asShow full document text