TCP Sender Clarification for Persist Condition
RFC 6429
|
| Document |
Type |
|
RFC - Informational
(December 2011; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Replaces |
|
draft-ananth-tcpm-persist
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 6429 (Informational)
|
|
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)
Show full document text