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