idnits 2.17.1 draft-ietf-tcpm-persist-05.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 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). -- The document date (August 22, 2011) is 4630 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 242, but no explicit reference was found in the text ** Obsolete normative reference: 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions M. Bashyam 3 Working Group Ocarina Networks, Inc 4 Internet-Draft M. Jethanandani 5 Intended status: Informational A. Ramaiah 6 Expires: February 23, 2012 Cisco 7 August 22, 2011 9 Clarification of sender behavior in persist condition. 10 draft-ietf-tcpm-persist-05.txt 12 Abstract 14 This document clarifies the Zero Window Probes (ZWP) described in 15 Requirements for Internet Hosts [RFC1122]. In particular, it 16 clarifies the actions that can be taken on connections which are 17 experiencing the ZWP condition. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 23, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 4 55 3. Description of one Simple Attack . . . . . . . . . . . . . . . 5 56 4. Clarification Regarding RFC 1122 Requirements . . . . . . . . 6 57 5. Scope of Changes . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 66 1. Introduction 68 Section 4.2.2.17 of Requirements for Internet Hosts [RFC1122] says: 70 "A TCP MAY keep its offered receive window closed indefinitely. 71 As long as the receiving TCP continues to send acknowledgments in 72 response to the probe segments, the sending TCP MUST allow the 73 connection to stay open." 75 DISCUSSION: 77 It is extremely important to remember that ACK (acknowledgment) 78 segments that contain no data are not reliably transmitted by 79 TCP. 81 Therefore zero window probing should be supported to prevent a 82 connection from hanging forever if ACK segments that re-opens the 83 window is lost. The condition where the sender goes into the Zero 84 Window Probe (ZWP) mode is typically known as the 'persist 85 condition'. 87 This guidance is not intended to preclude resource management by the 88 operating system or application, which may request connections to be 89 aborted regardless of them being in the persist condition, and the 90 TCP implementation should, of course, comply by aborting such 91 connections. TCP implementations that misinterpret Section 4.2.2.17 92 of Requirements for Internet Hosts [RFC1122] have the potential to 93 make systems vulnerable to Denial of Service (DoS) [RFC4732] 94 scenarios where attackers tie up resources by keeping connections in 95 the persist condition, if such resource management is not performed 96 external to the protocol implementation. 98 Section 2 of this document describes why implementations must not 99 close connections merely because they are in the persist condition, 100 yet must still allow such connections to be closed on command. 101 Section 3 outlines a simple attack on systems that do not 102 sufficiently manage connections in this state. Section 4 concludes 103 with a requirements-language clarification to the RFC 1122 104 requirement. 106 2. Discussion on RFC 1122 Requirement 108 Per Requirements for Internet Hosts [RFC1122] as long as the ACK's 109 are being received for window probes, a connection can continue to 110 stay in the persist condition. This is an important feature because 111 typically applications would want the TCP connection to stay open 112 unless an application explicitly closes the connection. 114 For example take the case of user running a network print job during 115 which the printer runs out of paper and is waiting for the user 116 intervention to reload the paper tray. The printer may not be 117 reading data from the printing application during this time. 118 Although this may result in a prolonged ZWP state, it would be 119 premature for TCP to take action on its own and close the printer 120 connecting merely due to its lack of progress. Once the printer's 121 paper tray is reloaded (which may be minutes, hours, or days later), 122 the print job should be able to continue uninterrupted over the same 123 TCP connection. 125 Systems that misinterpret the above section of Requirements for 126 Internet Hosts [RFC1122] may fall victim to DoS attacks, by not 127 supporting sufficient mechanisms to allow release of system resources 128 tied up by connections in the persist condition during times of 129 resource exhaustion. For example, if we take the case of a busy 130 server where multiple (attacker) clients can advertise a zero window 131 forever (by reliably acknowledging the ZWPs). This could eventually 132 lead to the resource exhaustion in the server system. In such cases 133 the application or operating system would need to take appropriate 134 action on the TCP connection to reclaim their resources and continue 135 to maintain legitimate connections. 137 The problem is applicable to TCP and TCP derived flow-controlled 138 transport protocols like SCTP. 140 Clearly, a system should be robust to such attacks and allow 141 connections in the persist condition to be aborted in the same way as 142 any other connection. Section 4 of this document provides the 143 requisite clarification, in standards language, to permit such 144 resource management 146 3. Description of one Simple Attack 148 To illustrate a potential DoS scenario, consider the case where many 149 client applications open TCP connection with a HTTP [RFC2616] server, 150 and each sends a GET request for a large page and stops reading the 151 response partway through. This causes the client's TCP 152 implementation to advertise a zero window to the server. For every 153 large HTTP response, the server is left holding on to the response 154 data in its sending queue. The amount of response data held will 155 depend on the size of the send buffer and the advertised window. If 156 the clients never read the data in their receive queues in order to 157 clear the persist condition, the server will continue to hold that 158 data indefinitely. Since there may be a limit to the operating 159 system kernel memory available for TCP buffers, this may result in 160 DoS to legitimate connections by locking up the necessary resources. 161 If the above scenario persists for an extended period of time, it 162 will lead to TCP buffers and connection blocks starvation causing 163 legitimate existing connections and new connection attempts to fail. 165 A clever application might detect such attacks with connections that 166 are not making progress, and could close these connections. However, 167 some applications might have transferred all the data to the TCP 168 socket and subsequently closed the socket leaving the connection with 169 no controlling process, hereby referred to as orphaned connections. 170 Such orphaned connections might be left holding the data indefinitely 171 in their sending queue. 173 CERT has released an advisory in this regard[VU723308] and is making 174 vendors aware of this DoS scenario. 176 4. Clarification Regarding RFC 1122 Requirements 178 As stated in Requirements for Internet Hosts [RFC1122], a TCP 179 implementation MUST NOT close a connection merely because it seems to 180 be stuck in the ZWP or persist condition. Unstated in RFC 1122, but 181 implicit for system robustness, a TCP implementation must allow 182 connections in the ZWP or persist condition to be closed or aborted 183 by their applications or other resource management routines in the 184 operating system. 186 An interface that allows an application to inform TCP on what to do 187 when the connection stays in persist condition, or for application or 188 other resource manager to query the health of the TCP connection is 189 considered outside the scope of this document. All such techniques 190 however are in complete compliance of TCP [RFC0793] and Requirements 191 for Internet Hosts [RFC1122]. 193 5. Scope of Changes 195 There was a question within the IETF TCP Maintenance and Minor 196 Extensions (TCPM) working group about the scope of this document. 197 After a lot of discussion it came down to whether this draft was 198 suggesting a change in the standard. The workgroup consensus was 199 that the draft clarifies what has been till now a misinterpretation 200 of the standard as specified in RFC 1122 [RFC1122], rather than a 201 change in standard. Therefore it felt that the document should be 202 published as a Information RFC rather than a standards document. 204 6. IANA Considerations 206 This document has no actions for IANA. 208 7. Security Considerations 210 This document discusses one system security consideration as 211 described in Security Considerations Guidelines [RFC3552]. In 212 particular it describes a inappropriate use of a system that is 213 acting as a server for many users. That and a possible DoS attack is 214 discussed in Section 3. 216 The document limits itself to clarifying RFC 1122. It does not 217 discuss what should happen with orphaned connections and other 218 possible mitigation techniques, as these are considered outside the 219 scope of this document. 221 8. Acknowledgments 223 This document was inspired by the recent discussions that took place 224 regarding the TCP persist condition issue in the TCPM WG mailing list 225 [TCPM]. The outcome of those discussions was to come up with a draft 226 that would clarify the intentions of the ZWP referred by RFC 1122. 227 We would like to thank Mark Allman, Ted Faber and David Borman for 228 clarifying the objective behind this draft. To Wesley Eddy for his 229 extensive editorial comments and to Dan Wing, Mark Allman and 230 Fernando Gont on providing feedback on the document. 232 9. References 234 9.1. Normative References 236 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 237 RFC 793, September 1981. 239 [RFC1122] Braden, R., "Requirements for Internet Hosts - 240 Communication Layers", STD 3, RFC 1122, October 1989. 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 9.2. Informative References 247 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 248 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 249 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 251 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 252 Text on Security Considerations", BCP 72, RFC 3552, 253 July 2003. 255 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 256 Service Considerations", RFC 4732, December 2006. 258 [TCPM] TCPM, "IETF TCPM Working Group and mailing list 259 http://www.ietf.org/html.charters/tcpm.charter.html". 261 [VU723308] 262 Manion, "Vulnerability in Web Servers 263 http://www.kb.cert.org/vuls/id/723308", July 2009. 265 Authors' Addresses 267 Murali Bashyam 268 Ocarina Networks, Inc 269 42 Airport Parkway 270 San Jose, CA 95110 271 USA 273 Phone: +1 (408) 512-2966 274 Email: mbashyam@ocarinanetworks.com 276 Mahesh Jethanandani 277 Cisco 278 170 Tasman Drive 279 San Jose, CA 95134 280 USA 282 Phone: +1 (408) 527-8230 283 Email: mjethanandani@gmail.com 285 Anantha Ramaiah 286 Cisco 287 170 Tasman Drive 288 San Jose, CA 95134 289 USA 291 Phone: +1 (408) 525-6486 292 Email: ananth@cisco.com