idnits 2.17.1 draft-ietf-tcpm-persist-04.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. == 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 date (March 29, 2011) is 4777 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 (~~), 2 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: September 30, 2011 Cisco 7 March 29, 2011 9 Clarification of sender behavior in persist condition. 10 draft-ietf-tcpm-persist-04.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 September 30, 2011. 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. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 5 56 4. Description of one Simple Attack . . . . . . . . . . . . . . . 6 57 5. Clarification Regarding RFC 1122 Requirements . . . . . . . . 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 strictly adhering to Section 92 4.2.2.17 of Requirements for Internet Hosts [RFC1122] have the 93 potential to make systems vulnerable to Denial of Service (DoS) 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 3 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 4 outlines a simple attack on systems that do not 102 sufficiently manage connections in this state. Section 5 concludes 103 with a requirements-language clarification to the RFC 1122 104 requirement. 106 2. Requirements 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119. 112 When used in lowercase, these words convey their typical use in 113 common language, and they are not to be interpreted as described in 114 Key words for use in RFCs [RFC2119]. 116 3. Discussion on RFC 1122 Requirement 118 Per Requirements for Internet Hosts [RFC1122] as long as the ACK's 119 are being received for window probes, a connection can continue to 120 stay in the persist condition. This is an important feature because 121 typically applications would want the TCP connection to stay open 122 unless an application explicitly closes the connection. 124 For example take the case of user running a network print job during 125 which the printer runs out of paper and is waiting for the user 126 intervention to reload the paper tray. The printer may not be 127 reading data from the printing application during this time. 128 Although this may result in a prolonged ZWP state, it would be 129 premature for TCP to take action on its own and close the printer 130 connecting merely due to its lack of progress. Once the printer's 131 paper tray is reloaded (which may be minutes, hours, or days later), 132 the print job should be able to continue uninterrupted over the same 133 TCP connection. 135 Systems that adhere too strictly to the above verbiage of 136 Requirements for Internet Hosts [RFC1122] may fall victim to DoS 137 attacks, by not supporting sufficient mechanisms to allow release of 138 system resources tied up by connections in the persist condition 139 during times of resource exhaustion. For example, if we take the 140 case of a busy server where multiple (attacker) clients can advertise 141 a zero window forever (by reliably acknowledging the ZWPs). This 142 could eventually lead to the resource exhaustion in the server 143 system. In such cases the application or operating system would need 144 to take appropriate action on the TCP connection to reclaim their 145 resources and continue to persist legitimate connections. 147 The problem is applicable to TCP and TCP derived flow-controlled 148 transport protocols like SCTP. 150 Clearly, a system should be robust to such attacks and allow 151 connections in the persist condition to be aborted in the same way as 152 any other connection. Section 5 of this document provides the 153 requisite clarification, in standards language, to permit such 154 resource management 156 4. Description of one Simple Attack 158 To illustrate a potential DoS scenario, consider the case where many 159 client applications open TCP connection with a HTTP [RFC2616] server, 160 and each sends a GET request for a large page and stops reading the 161 response partway through. This causes the client's TCP 162 implementation to advertise a zero window to the server. For every 163 large HTTP response, the server is left holding on to the response 164 data in its sending queue. The amount of response data held will 165 depend on the size of the send buffer and the advertised window. If 166 the clients never read the data in their receive queues in order to 167 clear the persist condition, the server will continue to hold that 168 data indefinitely. Since there may be a limit to the operating 169 system kernel memory available for TCP buffers, this may result in 170 DoS to legitimate connections by locking up the necessary resources. 171 If the above scenario persists for an extended period of time, it 172 will lead to TCP buffers and connection blocks starvation causing 173 legitimate existing connections and new connection attempts to fail. 175 A clever application might detect such attacks with connections that 176 are not making progress, and could close these connections. However, 177 some applications might have transferred all the data to the TCP 178 socket and subsequently closed the socket leaving the connection with 179 no controlling process, hereby referred to as orphaned connections. 180 Such orphaned connections might be left holding the data indefinitely 181 in their sending queue. 183 CERT has released an advisory in this regard[VU723308] and is making 184 vendors aware of this DoS scenario. 186 5. Clarification Regarding RFC 1122 Requirements 188 As stated in Requirements for Internet Hosts [RFC1122], a TCP 189 implementation MUST NOT close a connection merely because it seems to 190 be stuck in the ZWP or persist condition. Unstated in RFC 1122, but 191 implicit for system robustness, a TCP implementation MUST allow 192 connections in the ZWP or persist condition to be closed or aborted 193 by their applications or other resource management routines in the 194 operating system. 196 An interface that allows an application to inform TCP on what to do 197 when the connection stays in persist condition, or for application or 198 other resource manager to query the health of the TCP connection is 199 considered outside the scope of this document. All such techniques 200 however are in complete compliance of TCP [RFC0793] and Requirements 201 for Internet Hosts [RFC1122]. 203 6. IANA Considerations 205 This document has no actions for IANA. 207 7. Security Considerations 209 This document discusses one system security consideration as 210 described in Security Considerations Guidelines [RFC3552]. In 211 particular it describes a inappropriate use of a system that is 212 acting as a server for many users. That and a possible DoS attack is 213 discussed in Section 3. 215 8. Acknowledgments 217 This document was inspired by the recent discussions that took place 218 regarding the TCP persist condition issue in the TCPM WG mailing list 219 [TCPM]. The outcome of those discussions was to come up with a draft 220 that would clarify the intentions of the ZWP referred by RFC 1122. 221 We would like to thank Mark Allman, Ted Faber and David Borman for 222 clarifying the objective behind this draft. To Wesley Eddy for his 223 extensive editorial comments and to Dan Wing, Mark Allman and 224 Fernando Gont on providing feedback on the document. 226 9. References 228 9.1. Normative References 230 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 231 RFC 793, September 1981. 233 [RFC1122] Braden, R., "Requirements for Internet Hosts - 234 Communication Layers", STD 3, RFC 1122, October 1989. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 9.2. Informative References 241 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 242 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 243 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 245 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 246 Text on Security Considerations", BCP 72, RFC 3552, 247 July 2003. 249 [TCPM] TCPM, "IETF TCPM Working Group and mailing list 250 http://www.ietf.org/html.charters/tcpm.charter.html". 252 [VU723308] 253 Manion, "Vulnerability in Web Servers 254 http://www.kb.cert.org/vuls/id/723308", July 2009. 256 Authors' Addresses 258 Murali Bashyam 259 Ocarina Networks, Inc 260 42 Airport Parkway 261 San Jose, CA 95110 262 USA 264 Phone: +1 (408) 512-2966 265 Email: mbashyam@ocarinanetworks.com 267 Mahesh Jethanandani 268 Cisco 269 170 Tasman Drive 270 San Jose, CA 95134 271 USA 273 Phone: +1 (408) 527-8230 274 Email: mahesh@cisco.com 276 Anantha Ramaiah 277 Cisco 278 170 Tasman Drive 279 San Jose, CA 95134 280 USA 282 Phone: +1 (408) 525-6486 283 Email: ananth@cisco.com