idnits 2.17.1 draft-ietf-tcpm-persist-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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). -- The document date (February 14, 2011) is 4821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 271, 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: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: August 18, 2011 Cisco 7 February 14, 2011 9 Clarification of sender behavior in persist condition. 10 draft-ietf-tcpm-persist-02.txt 12 Abstract 14 This document clarifies the Zero Window Probes (ZWP) described in 15 [RFC1122]. In particular, it clarifies the actions that can be taken 16 on connections which are experiencing the ZWP condition. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 18, 2011. 35 Copyright Notice 37 Copyright (c) 2011 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 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 4 54 3. Description of one Simple Attack . . . . . . . . . . . . . . . 5 55 4. Clarification Regarding RFC 1122 Requirements . . . . . . . . 6 56 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Appendix A, Programming Considerations . . . . . . . . . . . . 8 58 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 61 1. Introduction 63 Section 4.2.2.17 of [RFC1122] says: 65 "A TCP MAY keep its offered receive window closed indefinitely. 66 As long as the receiving TCP continues to send acknowledgments in 67 response to the probe segments, the sending TCP MUST allow the 68 connection to stay open." 70 DISCUSSION: 72 It is extremely important to remember that ACK (acknowledgment) 73 segments that contain no data are not reliably transmitted by 74 TCP. 76 Therefore zero window probing SHOULD be supported to prevent a 77 connection from hanging forever if ACK segments that re-opens the 78 window is lost. The condition where the sender goes into the Zero- 79 Window Probe (ZWP) mode is typically known as the 'persist 80 condition'. 82 This guidance is not intended to preclude resource management by the 83 operating system or application, which may request connections to be 84 aborted regardless of them being in the persist condition, and the 85 TCP implementation should, of course, comply by aborting such 86 connections. TCP implementations strictly adhering to Section 87 4.2.2.17 of [RFC1122] have the potential to make systems vulnerable 88 to Denial of Service (DoS) scenarios where attackers tie up resources 89 by keeping connections in the persist condition, if such resource 90 management is not performed external to the protocol implementation. 92 Section 2 of this document describes why implementations must not 93 close connections merely because they are in the persist condition, 94 yet must still allow such connections to be closed on command. 95 Section 3 outlines a simple attack on systems that do not 96 sufficiently manage connections in this state. Section 4 concludes 97 with a requirements-language clarification to the RFC 1122 98 requirement. 100 2. Discussion on RFC 1122 Requirement 102 Per [RFC1122] as long as the ACK's are being received for window 103 probes, a connection can continue to stay in the persist condition. 104 This is an important feature because typically applications would 105 want the TCP connection to stay open unless an application explicitly 106 closes the connection. 108 For example take the case of user running a network print job during 109 which the printer runs out of paper and is waiting for the user 110 intervention to reload the paper tray. The printer may not be 111 reading data from the printing application during this time. 112 Although this may result in a prolonged ZWP state, it would be 113 premature for TCP to take action on its own and close the printer 114 connecting merely due to its lack of progress. Once the printer's 115 paper tray is reloaded (which may be minutes, hours, or days later), 116 the print job should be able to continue uninterrupted over the same 117 TCP connection. 119 Systems that adhere too strictly to the above verbiage of [RFC1122] 120 may fall victim to DoS attacks, by not supporting sufficient 121 mechanisms to allow release of system resources tied up by 122 connections in the persist condition during times of resource 123 exhaustion. For example, if we take the case of a busy server where 124 multiple (attacker) clients can advertise a zero window forever (by 125 reliably acknowledging the ZWPs). This could eventually lead to the 126 resource exhaustion in the server system. In such cases the 127 application or operating system would need to take appropriate action 128 on the TCP connection to reclaim their resources and continue to 129 persist legitimate connections. 131 The problem is applicable to TCP and TCP derived flow-controlled 132 transport protocols like SCTP. 134 Clearly, a system should be robust to such attacks and allow 135 connections in the persist condition to be aborted in the same way as 136 any other connection. Section 4 of this document provides the 137 requisite clarification, in standards language, to permit such 138 resource management 140 3. Description of one Simple Attack 142 To illustrate a potential DoS scenario, consider the case where many 143 client applications open TCP connection with a HTTP [RFC2616] server, 144 and each sends a GET request for a large page and stops reading the 145 response partway through. This causes the client's TCP 146 implementation to advertise a zero window to the server. For every 147 large HTTP response, the server is left holding on to the response 148 data in its sending queue. The amount of response data held will 149 depend on the size of the send buffer and the advertised window. If 150 the clients never read the data in their receive queues in order to 151 clear the persist condition, the server will continue to hold that 152 data indefinitely. Since there may be a limit to the operating 153 system kernel memory available for TCP buffers, this may result in 154 DoS to legitimate connections by locking up the necessary resources. 155 If the above scenario persists for an extended period of time, it 156 will lead to TCP buffers and connection blocks starvation causing 157 legitimate existing connections and new connection attempts to fail. 159 A clever application might detect such attacks with connections that 160 are not making progress, and could close these connections. However, 161 some applications might have transferred all the data to the TCP 162 socket and subsequently closed the socket leaving the connection with 163 no controlling process, hereby referred to as orphaned connections. 164 Such orphaned connections might be left holding the data indefinitely 165 in their sending queue. 167 CERT has released an advisory in this regard[VU723308] and is making 168 vendors aware of this DoS scenario. 170 Appendix A of this document provides a simple mitigation to such 171 attacks. More sophisticated attacks are possible which can build on 172 this vulnerability and may remain effective even when mitigated with 173 the mechanism prescribed in Appendix A of this document. 175 4. Clarification Regarding RFC 1122 Requirements 177 As stated in [RFC1122], a TCP implementation MUST NOT close a 178 connection merely because it seems to be stuck in the ZWP or persist 179 condition. Unstated in RFC 1122, but implicit for system robustness, 180 a TCP implementation MUST allow connections in the ZWP or persist 181 condition to be closed or aborted by their applications or other 182 resource management routines in the operating system. 184 In order to provide some level of robustness to DoS attacks, a TCP 185 implementation MAY provide a feedback regarding the persist condition 186 to the application if requested to do so or an application or other 187 resource manager can query the health of the TCP connection allowing 188 it to take the desired action. All such techniques are in complete 189 compliance of [RFC0793] and [RFC1122]. 191 5. Acknowledgments 193 This document was inspired by the recent discussions that took place 194 regarding the TCP persist condition issue in the TCPM WG mailing list 195 [TCPM]. The outcome of those discussions was to come up with a draft 196 that would clarify the intentions of the ZWP referred by RFC 1122. 197 We would like to thank Mark Allman, Ted Faber and David Borman for 198 clarifying the objective behind this draft. To Wesley Eddy for his 199 extensive editorial comments and to Dan Wing, Mark Allman and 200 Fernando Gont on providing feedback on the document. 202 6. Appendix A, Programming Considerations 204 As a potential implementation guideline, the authors are documenting 205 some of the programming considerations. This should not be in any 206 way construed as the only way that the mitigation against the DoS 207 condition can be achieved. Applications can choose their own 208 implementations on how to deal with this DoS scenario, and should be 209 aware that this mitigation is only effective at combating the simple 210 attack scenario described in this document, and does not handle even 211 slightly more sophisticated attacks based on the same or similar 212 concepts. 214 Note, this persist condition is mutually exclusive from a persist 215 condition where we are not getting zero windows acknowledgement for 216 the probes. 218 The technique described here allows an application to specify to the 219 operating system that it consents to aborting such connections. 220 Implementers can choose to in addition provide an asynchronous 221 notification interface to inform the application of the connection in 222 the persist condition, if they want the application to abort the 223 connection. In the case where the application has terminated or 224 orphaned the connection, the TCP or kernel code will go ahead and 225 clear the connection and reclaim its resources. 227 The key consideration in putting a solution together is to be able to 228 detect a connection that is in persist condition. The application 229 through the socket interface will be able to inform TCP 230 implementation or kernel of how long they are willing to have 231 connections wait in the persist condition. 233 PERSIST_TIMEOUT 235 Format: 237 int setsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO, 238 persist_timeout_value, length) 240 int getsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO, 241 persist_timeout_value, length) 243 where persist_timeout_value recorded in seconds is of type int, the 244 length is set to four. 246 The above interface allows applications to inform TCP what to do when 247 the local connection stays in the persist condition. Note that the 248 default value of persist_timeout_value is -1 which implies it is 249 infinite. 251 TCP sender will save the current time in the connection block when it 252 receives a zero window ACK. This time is referred to as the persist 253 entry time. Thereafter every time the probe timer expires and before 254 it sends another probe or an ACK carrying zero window is received a 255 check will be done to see how long the connection has been in persist 256 condition by comparing the current time to the persist entry time. 257 If the timeout has been exceeded, the connection will be aborted. 259 Any time a ACK is received that advertises a non-zero window, the 260 persist entry time is cleared to take the connection out of the 261 persist condition. 263 7. Informative References 265 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 266 RFC 793, September 1981. 268 [RFC1122] Braden, R., "Requirements for Internet Hosts - 269 Communication Layers", STD 3, RFC 1122, October 1989. 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, March 1997. 274 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 275 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 276 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 278 [TCPM] TCPM, "IETF TCPM Working Group and mailing list 279 http://www.ietf.org/html.charters/tcpm.charter.html". 281 [VU723308] 282 Manion, "Vulnerability in Web Servers 283 http://www.kb.cert.org/vuls/id/723308", July 2009. 285 Authors' Addresses 287 Murali Bashyam 288 Ocarina Networks, Inc 289 42 Airport Parkway 290 San Jose, CA 95110 291 USA 293 Phone: +1 (408) 512-2966 294 Email: mbashyam@ocarinanetworks.com 296 Mahesh Jethanandani 297 Cisco 298 170 Tasman Drive 299 San Jose, CA 95134 300 USA 302 Phone: +1 (408) 527-8230 303 Email: mahesh@cisco.com 305 Anantha Ramaiah 306 Cisco 307 170 Tasman Drive 308 San Jose, CA 95134 309 USA 311 Phone: +1 (408) 525-6486 312 Email: ananth@cisco.com