idnits 2.17.1 draft-ananth-tcpm-persist-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC1122]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The document addresses the fact that terminating TCP connections stuck in the persist condition does not violate RFC 1122 or RFC 793. It also suggests that TCP MUST not abort any connection until either explicitly requested by the application to do so. The implementation guidelines of the request and the action are documented in Section 7, and the details of mitigating the DoS attack are left to the implementer. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2009) is 5396 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 202, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 208, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor M. Bashyam 3 Extensions Working Group Ocarina Networks, Inc 4 Internet-Draft M. Jethanandani 5 Intended status: Informational A. Ramaiah 6 Expires: January 11, 2010 Cisco Systems 7 July 10, 2009 9 Clarification of sender behaviour in persist condition. 10 draft-ananth-tcpm-persist-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 11, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document attempts to clarify the notion of the Zero Window 49 Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it 50 clarifies the actions that can be taken on connections which are 51 experiencing the ZWP condition. The motivation for this document 52 stems from the belief that TCP implementations strictly adhering to 53 the current RFC language have the potential to become vulnerable to 54 Denial of Service (DoS) scenarios. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 4 60 3. Description of Attack . . . . . . . . . . . . . . . . . . . . 5 61 4. Clarification Regarding RFC 1122 Requirements . . . . . . . . 6 62 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Programming Considerations . . . . . . . . . . . . . . . . . . 9 65 8. Informative References . . . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 According to RFC 1122 [RFC1122] Section 4.2.2.17: A TCP MAY keep it's 71 offered receive window closed indefinitely. As long as the receiving 72 TCP continues to send acknowledgments in response to the probe 73 segments, the sending TCP MUST allow the connection to stay open. It 74 is important to remember that ACK (acknowledgement) segments that 75 contain no data are not reliably transmitted by TCP. Therefore zero 76 window probing SHOULD be supported to prevent a connection from 77 hanging forever if ACK segments that re-opens the window is lost. 78 The condition where the sender goes into the ZWP mode is typically 79 known as the persist condition. 81 2. Discussion on RFC 1122 Requirement 83 It needs to be emphasised that TCP MUST NOT take any action of its 84 own when a particular connection is in persist state for a long time. 85 As per RFC 1122 as long as the ACK's are being received for window 86 probes, it can continue to stay in persist mode. This is important 87 because typically applications would want the TCP connection to stay 88 open unless it explicitly closes the connection. For example take 89 the case of user running a print job and the printer ran out of paper 90 waiting for the user intervention. It would be premature for TCP to 91 take action on its own. Hence TCP cannot act as a resource manager 92 and it is the system or application's responsibility to take 93 appropriate action. 95 At the same time, many existing TCP implementations that adhere 96 strictly to the above verbiage of RFC 1122, may fall victim to DOS 97 attacks, if appropriate measures are not followed. For example, if 98 we take the case of a busy server where multiple clients can 99 advertise a zero forever (by reliably acknowledging the ZWP's), it 100 could eventually lead to the resource exhaustion in the system. In 101 such cases the system would need to take appropriate action on the 102 TCP connection to reclaim the resources. The document is not 103 intended to provide any advice on any particular resource management 104 scheme that can be implemented to circumvent DOS issues arising due 105 to the connections stuck in the persist state. The problem is 106 applicable to TCP and TCP derived transport protocols like SCTP. 108 3. Description of Attack 110 If TCP implementations strictly follow RFC 1122 and there is no 111 instruction on what to do in persist condition, connections will 112 encounter an indefinite wait. To illustrate this, consider the case 113 where the client application opens a TCP connection with a HTTP 114 [RFC2616] server, sends a GET request for a large page and stops 115 reading the response. This would cause the client TCP to advertise a 116 zero window to the server. For every large HTTP response, the server 117 is left holding on to all the response data in it's send queue. If 118 the client never clears the persist condition, the server will 119 continue to hold that data indefinitely. Multiple such TCP 120 connections stuck in the same scenario on the server would cause 121 resource depletion resulting in a DoS situation on the server. 123 Applications on the sender can transfer all the data to the TCP 124 socket and subsequently close the socket leaving the connection in 125 orphaned state. If the application on the receiver refuses to read 126 the data, the orphaned connection will be left holding the data 127 indefinitely in its send queue. 129 If the above scenario persists for an extended period of time, it 130 will lead to TCP buffers and connection blocks starvation causing 131 legitimate existing connections and new connection attempts to fail. 133 CERT is putting a advisory in this regard[VU723308] and is making 134 vendors aware of this DoS scenario. 136 4. Clarification Regarding RFC 1122 Requirements 138 A consequence of adhering to the above requirement mandated by RFC 139 1122 is that multiple TCP receivers advertising a zero window to a 140 server could exhaust the connection and buffer resources of the 141 sender. In such cases, and specially when the receiver is reliably 142 acknowledging zero window probe, to achieve robustness, the system 143 should be able to take appropriate action on those TCP connections 144 and reclaim resources. A possible action could be to terminate the 145 connection and such an action is in the spirit of RFC 1122. 147 In order to accomplish this action, TCP MAY provide a feedback 148 regarding the persist condition to the application if requested to do 149 so or the application or the resource manager can query the health of 150 the TCP connection which would allow it to take the desired action. 151 All such actions are in complete compliance of RFC 793 and RFC 1122. 153 5. Conclusion 155 The document addresses the fact that terminating TCP connections 156 stuck in the persist condition does not violate RFC 1122 or RFC 793. 157 It also suggests that TCP MUST not abort any connection until either 158 explicitly requested by the application to do so. The implementation 159 guidelines of the request and the action are documented in Section 7, 160 and the details of mitigating the DoS attack are left to the 161 implementer. 163 6. Acknowledgments 165 This document was inspired by the recent discussions that took place 166 regarding the TCP persist condition issue in the TCPM WG mailing list 167 [TCPM]. The outcome of those discussions was to come up with a draft 168 that would clarify the intentions of the ZWP referred by RFC 1122. 169 We would like to thank Mark Allman and David Borman for clarifying 170 the objective behind this draft. 172 7. Programming Considerations 174 To enable a server to clear connections in persist condition and 175 reclaim resources, a socket interface needs to be defined. Note, 176 this condition is mutually exclusive from a persist condition where 177 we are not getting zero windows acknowledgement for the probes. 179 PERSIST_TIMEOUT 181 Format: setsockopt(fd, SOL_TCP, PERSIST_TIMEOUT, 182 persist_timeout_value) 184 The interface allows applications to inform TCP that when the local 185 connection stays in persist condition it can be cleared after a set 186 time. Note that the default value of this option is indefinite. 188 TCP sender will save the current time in the connection block when it 189 receives a zero window ACK. This time is referred to as the persist 190 entry time. Thereafter every time the probe timer expires and before 191 it sends another probe or an ACK carrying zero window is received a 192 check will be done to see how long the connection has been in persist 193 condition by comparing the current time to the persist entry time. 194 If the timeout has been exceeded, the connection will be aborted. 196 Any time a ACK is received that advertises a non-zero window, the 197 persist entry time is cleared to take the connection out of persist 198 condition. 200 8. Informative References 202 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 203 RFC 793, September 1981. 205 [RFC1122] Braden, R., "Requirements for Internet Hosts - 206 Communication Layers", STD 3, RFC 1122, October 1989. 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 212 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 213 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 215 [TCPM] TCPM, "IETF TCPM Working Group and mailing list 216 http://www.ietf.org/html.charters/tcpm-charter.html". 218 [VU723308] 219 Manion, "Vulnerability is Web Servers 220 http://www.kb.cert.org/vuls/id/723308", July 2009. 222 Authors' Addresses 224 Murali Bashyam 225 Ocarina Networks, Inc 226 42 Airport parkway 227 San Jose, CA 95110 228 USA 230 Phone: +1 (408) 512-2966 231 Email: mbashyam@ocarinanetworks.com 233 Mahesh Jethanandani 234 Cisco Systems 235 170 Tasman Drive 236 San Jose, CA 95134 237 USA 239 Phone: +1 (408) 527-8230 240 Email: mahesh@cisco.com 242 Anantha Ramaiah 243 Cisco Systems 244 170 Tasman Drive 245 San Jose, CA 95134 246 USA 248 Phone: +1 (408) 525-6486 249 Email: ananth@cisco.com