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. draft-ananth-tcpm-persist-00.txt 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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 Abstract 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 4.2.2.17, 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 793. 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 language. 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 http://www.ietf.org/html.charters/tcpm-charter.html". 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 USA Phone: +1 (408) 512-2966 Email: mbashyam@ocarinanetworks.com Mahesh Jethanandani Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Phone: +1 (408) 527-8230 Email: mahesh@cisco.com Anantha Ramaiah Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Phone: +1 (408) 525-6486 Email: ananth@cisco.com 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. Bashyam, et al. Expires December 30, 2008 [Page 10]