TCP Maintenance and Minor                                     M. Bashyam
Extensions Working Group                           Ocarina Networks, Inc
Internet-Draft                                           M. Jethanandani
Intended status: Informational                                A. Ramaiah
Expires: December 30, 2008                                 Cisco Systems
                                                           June 28, 2008

        Clarification of sender behaviour in persist condition.

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 30, 2008.

Bashyam, et al.         Expires December 30, 2008               [Page 1]

Internet-Draft             TCP persist anomaly                 June 2008


   This document attempts to clarify the notion of the Zero Window
   Probes (ZWP) described in RFC 1122 [RFC1122].  In particular, it
   clarifies the actions that can be taken on connections which are
   experiencing the ZWP condition.  The motivation for this document
   stems from the belief that TCP implementations strictly adhering to
   the current RFC language have the potential to become vulnerable to
   Denial of Service (DoS) scenarios.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   4.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Informative References . . . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10

Bashyam, et al.         Expires December 30, 2008               [Page 2]

Internet-Draft             TCP persist anomaly                 June 2008

1.  Introduction

   RFC 1122 [RFC1122] Section, page 92 says that: A TCP MAY
   keep it's 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.  The RFC goes on to say that it is important to remember that
   ACK (acknowledgement) segments that contain no data are not reliably
   transmitted by TCP.  Therefore zero window probing SHOULD be
   supported to prevent a connection from hanging forever if ACK
   segments that re-opens the window is lost.  The condition where the
   sender goes into the ZWP mode is typically known as the persist
   condition.  The problem is applicable to TCP and TCP derived
   transport protocols like SCTP.

   A consequence of adhering to the above requirement mandated by RFC
   1122 is that multiple TCP receivers (clients) advertising a zero
   window to a busy server indefinitely (by reliably acknowledging the
   ZWP), could exhaust the connection and buffer resources of the sender
   (server).  In such cases, to achieve robustness, the system should be
   able to take appropriate action on those TCP connections and reclaim
   resources.  The purpose of this document is to clarify that such
   actions are in the spirit of RFC 1122 and they don't violate RFC
   1122.  The remainder of the document briefly describes the DoS
   scenario, analyzes the current verbiage surrounding the ZWP in RFC
   1122 and attempts to disambiguate the notion presented by RFC 1122.

Bashyam, et al.         Expires December 30, 2008               [Page 3]

Internet-Draft             TCP persist anomaly                 June 2008

2.  Discussion

   Having the sender accumulate buffers and connection table entries
   when the receiver has deliberately and maliciously closed the window
   ultimately leads to resource exhaustion on the sender.  This
   particular dependence on the receiver to open its zero window can be
   easily exploited by a malicious receiver TCP application to launch a
   DoS attack against the sender.  In this scenario the sender's
   legitimate connections do not get established and already established
   well behaved TCP connections are unable to transmit any data.  The
   sender enters the persist condition and is stuck waiting indefinitely
   for the receiver to open up its window.

   To illustrate this, consider the case where the client application
   opens a TCP connection with a HTTP [RFC2616] server, sends a GET
   request for a large page and stops reading the response.  This would
   cause the client TCP to advertise a zero window to the server.  For
   every large HTTP response, the server is left holding on to all the
   response data in it's send queue.  If the client never clears the
   persist condition, the server will continue to hold that data
   indefinitely.  Multiple such TCP connections stuck in the same
   scenario on the server would cause resource depletion resulting in a
   DoS situation on the server.

   In such scenarios it should be possible for the application or the
   system or a resource management entity to instruct TCP to terminate
   connections stalled in the persist condition.  These actions are
   necessary to prevent resource exhaustion on the server.

   An extensive discussion took place recently about this issue on the
   TCPM WG mailing list [TCPM].  The general opinion seemed to be that
   terminating a TCP connection in persist condition does not violate
   RFC 1122.  In particular the operating system, a resource manager, or
   an application can instruct TCP to abort a connection in the persist
   condition.  TCP itself SHOULD not take any action and continue to
   keep the connection open as mandated by RFC 1122 unless otherwise
   instructed to do so.  The exact mechanism by which the instruction to
   abort the connection is conveyed to TCP is an implementation decision
   and falls beyond the scope of the current memo.  To determine which
   TCP connection to abort the entity can use the connection attributes
   obtained from some interface similar to STATUS call mentioned in RFC

Bashyam, et al.         Expires December 30, 2008               [Page 4]

Internet-Draft             TCP persist anomaly                 June 2008

3.  Security Considerations

   This memo primarily focuses on robustness of the system in general
   and robustness of TCP implementations during the persist condition in
   particular.  This memo is intended to clarify that, actions like
   aborting TCP connections is well within the scope of the RFC 1122

Bashyam, et al.         Expires December 30, 2008               [Page 5]

Internet-Draft             TCP persist anomaly                 June 2008

4.  Conclusions

   The document addresses the fact that terminating TCP connections
   stuck in the persist condition does not violate any RFC.  It also
   suggests that TCP MUST not abort any connection until and unless
   explicitly requested to do so.  The implementation details of the
   request is left to the implementer.

Bashyam, et al.         Expires December 30, 2008               [Page 6]

Internet-Draft             TCP persist anomaly                 June 2008

5.  Acknowledgments

   This document was inspired by the recent discussions that took place
   regarding the TCP persist condition issue in the TCPM WG mailing list
   [TCPM].  The outcome of those discussions was to come up with a draft
   that would clarify the intentions of the ZWP referred by RFC 1122.
   We would like to thank Mark Allman and David Borman for clarifying
   the objective behind this draft.

Bashyam, et al.         Expires December 30, 2008               [Page 7]

Internet-Draft             TCP persist anomaly                 June 2008

6.  Informative References

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1122]  Braden, R., "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.

   [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.

   [TCPM]     TCPM, "IETF TCPM Working Group and mailing list

Bashyam, et al.         Expires December 30, 2008               [Page 8]

Internet-Draft             TCP persist anomaly                 June 2008

Authors' Addresses

   Murali Bashyam
   Ocarina Networks, Inc
   42 Airport parkway
   San Jose, CA  95110

   Phone: +1 (408) 512-2966

   Mahesh Jethanandani
   Cisco Systems
   170 Tasman Drive
   San Jose, CA  95134

   Phone: +1 (408) 527-8230

   Anantha Ramaiah
   Cisco Systems
   170 Tasman Drive
   San Jose, CA  95134

   Phone: +1 (408) 525-6486

Bashyam, et al.         Expires December 30, 2008               [Page 9]

Internet-Draft             TCP persist anomaly                 June 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Bashyam, et al.         Expires December 30, 2008              [Page 10]