doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc6429.txt b/doc/rfc/rfc6429.txt
new file mode 100644
index 0000000..6df45da
--- /dev/null
+++ b/doc/rfc/rfc6429.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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 as
+   specified in 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.
+
+1.1.  Requirements Language
+
+   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].
+
+2.  Discussion of RFC 1122 Requirement
+
+   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.
+
+   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.
+
+
+
+Bashyam, et al.               Informational                     [Page 3]
+
+RFC 6429                  TCP Persist Condition            December 2011
+
+
+   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.
+
+   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.
+
+   The problem is applicable to TCP and TCP-derived flow-controlled
+   transport protocols such as the Stream Control Transmission Protocol
+   (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.
+
+3.  Description of One Simple Attack
+
+   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.
+
+   A clever application needs to detect such attacks with connections
+   that are not making progress, and could close these connections.
+
+
+
+Bashyam, et al.               Informational                     [Page 4]
+
+RFC 6429                  TCP Persist Condition            December 2011
+
+
+   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.
+
+   The US Computer Emergency Readiness Team (CERT) has released an
+   advisory in this regard [VU723308] and is making vendors aware of
+   this DoS scenario.
+
+4.  Clarification Regarding RFC 1122 Requirements
+
+   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.
+
+   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].
+
+5.  Security Considerations
+
+   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.
+
+   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.
+
+6.  Acknowledgments
+
+   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
+
+
+
+Bashyam, et al.               Informational                     [Page 5]
+
+RFC 6429                  TCP Persist Condition            December 2011
+
+
+   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.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC0793]   Postel, J., "Transmission Control Protocol", STD 7,
+               RFC 793, September 1981.
+
+   [RFC1122]   Braden, R., Ed., "Requirements for Internet Hosts -
+               Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+7.2.  Informative References
+
+   [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.
+
+   [RFC3552]   Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+               Text on Security Considerations", BCP 72, RFC 3552,
+               July 2003.
+
+   [RFC4732]   Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
+               Denial-of-Service Considerations", RFC 4732,
+               December 2006.
+
+   [TCPM]      IETF, "TCP Maintenance and Minor Extensions (tcpm) -
+               Charter", <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>.
+
+
+
+
+
+
+
+
+
+
+
+
+Bashyam, et al.               Informational                     [Page 6]
+
+RFC 6429                  TCP Persist Condition            December 2011
+
+
+Authors' Addresses
+
+   Murali Bashyam
+   Ocarina Networks, Inc.
+   42 Airport Parkway
+   San Jose, CA  95110
+   USA
+
+   Phone: +1 (408) 512-2966
+   EMail: mbashyam@ocarinanetworks.com
+
+
+   Mahesh Jethanandani
+   Cisco
+   170 Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   Phone: +1 (408) 527-8230
+   EMail: mjethanandani@gmail.com
+
+
+   Anantha Ramaiah
+   Cisco
+   170 Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   Phone: +1 (408) 525-6486
+   EMail: ananth@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bashyam, et al.               Informational                     [Page 7]
+