idnits 2.17.1 draft-ietf-tcpm-persist-01.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. 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 (November 10, 2010) is 4888 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 251, 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: May 14, 2011 Cisco Systems 7 November 10, 2010 9 Clarification of sender behaviour in persist condition. 10 draft-ietf-tcpm-persist-01.txt 12 Abstract 14 This document attempts to clarify the notion of the Zero Window 15 Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it 16 clarifies the actions that can be taken on connections which are 17 experiencing the ZWP condition. The motivation for this document 18 stems from the belief that TCP implementations strictly adhering to 19 the current RFC language have the potential to become vulnerable to 20 Denial of Service (DoS) scenarios. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 14, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Discussion on RFC 1122 Requirement . . . . . . . . . . . . . . 4 58 3. Description of Attack . . . . . . . . . . . . . . . . . . . . 5 59 4. Clarification Regarding RFC 1122 Requirements . . . . . . . . 6 60 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. Programming Considerations . . . . . . . . . . . . . . . . . . 9 63 8. Informative References . . . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 66 1. Introduction 68 TCP implementations strictly adhering to Section 4.2.2.17 of 69 [RFC1122] have the potential to become vulnerable to Denial of 70 Service (DoS) scenarios. That section of [RFC1122] says: 72 "A TCP MAY keep its offered receive window closed indefinitely. 73 As long as the receiving TCP continues to send acknowledgments in 74 response to the probe segments, the sending TCP MUST allow the 75 connection to stay open." 77 DISCUSSION: 79 It is extremely important to remember that ACK (acknowledgment) 80 segments that contain no data are not reliably transmitted by 81 TCP. 83 Therefore zero window probing SHOULD be supported to prevent a 84 connection from hanging forever if ACK segments that re-opens the 85 window is lost. The condition where the sender goes into the Zero- 86 Window Probe (ZWP) mode is typically known as the 'persist 87 condition'. It is under this condition that the sending TCP can 88 become vulnerable to DoS. 90 2. Discussion on RFC 1122 Requirement 92 It needs to be emphasised that TCP MUST NOT take any action of its 93 own when a particular connection is in persist condition for a long 94 time. As per RFC 1122 as long as the ACK's are being received for 95 window probes, it can continue to stay in persist condition. This is 96 important because typically applications would want the TCP 97 connection to stay open unless it explicitly closes the connection. 98 For example take the case of user running a print job and the printer 99 ran out of paper waiting for the user intervention. It would be 100 premature for TCP to take action on its own. Hence TCP cannot act as 101 a resource manager and it is the system or application's 102 responsibility to take appropriate action. 104 At the same time, many existing TCP implementations that adhere 105 strictly to the above verbiage of RFC 1122 may fall victim to DOS 106 attacks, if appropriate measures are not followed. For example, if 107 we take the case of a busy server where multiple clients can 108 advertise a zero forever (by reliably acknowledging the ZWP's), it 109 could eventually lead to the resource exhaustion in the system. In 110 such cases the system would need to take appropriate action on the 111 TCP connection to reclaim the resources. 113 This document is not intended to provide any advice on any particular 114 resource management scheme that can be implemented to circumvent DOS 115 issues arising due to the connections stuck in the persist state. 117 The problem is applicable to TCP and TCP derived transport protocols 118 like SCTP. 120 In summary, TCP MUST NOT take any action on its own to abort a 121 connection in persist condition. Applications however can request 122 that a connection in persist condition be aborted. The resource 123 manager in the operating system when faced with depleted resources 124 can also ask TCP to abort a connection. 126 3. Description of Attack 128 If TCP implementations strictly follow RFC 1122 and there is no 129 instruction on what to do in persist condition, connections will 130 encounter an indefinite wait. To illustrate this, consider the case 131 where the client application opens a TCP connection with a HTTP 132 [RFC2616] server, sends a GET request for a large page and stops 133 reading the response. This would cause the client TCP to advertise a 134 zero window to the server. For every large HTTP response, the server 135 is left holding on to the response data in its send queue. The 136 amount of response data held will depend on the size of the send 137 buffer and the advertised window. If the client never reads the data 138 in its receive queue or clears the persist condition, the server will 139 continue to hold that data indefinitely. Multiple such TCP 140 connections stuck in the same scenario on the server would cause 141 resource depletion resulting in a DoS situation on the server. 143 Applications on the sender can transfer all the data to the TCP 144 socket and subsequently close the socket leaving the connection with 145 no controlling process, hereby referred to as orphaned connection. 146 If the application on the receiver refuses to read the data, the 147 orphaned connection will be left holding the data indefinitely in its 148 send queue. 150 If the above scenario persists for an extended period of time, it 151 will lead to TCP buffers and connection blocks starvation causing 152 legitimate existing connections and new connection attempts to fail. 154 CERT has released an advisory in this regard[VU723308] and is making 155 vendors aware of this DoS scenario. 157 4. Clarification Regarding RFC 1122 Requirements 159 A consequence of adhering to the above requirement mandated by RFC 160 1122 is that multiple TCP receivers advertising a zero window to a 161 server could exhaust the connection and buffer resources of the 162 sender. In such cases, and specially when the receiver is reliably 163 acknowledging zero window probe, to achieve robustness, the system 164 should be able to take appropriate action on those TCP connections 165 and reclaim resources. A possible action could be to terminate the 166 connection and such an action is in the spirit of RFC 1122. 168 In order to accomplish this action, TCP MAY provide a feedback 169 regarding the persist condition to the application if requested to do 170 so or the application or the resource manager can query the health of 171 the TCP connection which would allow it to take the desired action. 172 All such actions are in complete compliance of RFC 793 and RFC 1122. 174 5. Conclusion 176 The document addresses the fact that terminating TCP connections 177 stuck in the persist condition does not violate RFC 1122 or RFC 793. 178 It also suggests that TCP must not abort any connection until 179 explicitly requested by the application or the operating system to do 180 so. The potential implementation guidelines of the request and the 181 action are documented in Section 7, and the details of mitigating the 182 DoS attack are left to the implementer. 184 6. Acknowledgments 186 This document was inspired by the recent discussions that took place 187 regarding the TCP persist condition issue in the TCPM WG mailing list 188 [TCPM]. The outcome of those discussions was to come up with a draft 189 that would clarify the intentions of the ZWP referred by RFC 1122. 190 We would like to thank Mark Allman and David Borman for clarifying 191 the objective behind this draft. To Dan Wing, Mark Allman and 192 Fernando Gont on providing feedback on the document. 194 7. Programming Considerations 196 As a potential implementation guideline, the authors are documenting 197 some of the programming considerations. This should not be in any 198 way construed as the only way that the mitigation against the DoS 199 condition can be achieved. Applications can choose their own 200 implementations on how to deal with this DoS sceanrio. 202 The key consideration in putting a solution together is to be able to 203 detect a connection that is in persist condition. The application 204 through the socket interface can inform TCP or kernel of how long 205 they are willing to wait in persist condition. When the connection 206 reaches that particular timeout value a EPERSISTTIMEOUT notification 207 will be sent to the application. The application on receiving the 208 notification can turn around and issue a close. In the case, the 209 application has terminated, TCP or kernel will go ahead and clear the 210 connection and reclaim the resoruces. Note, this persist condition 211 is mutually exclusive from a persist condition where we are not 212 getting zero windows acknowledgement for the probes. 214 PERSIST_TIMEOUT 216 Format: 218 int setsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO, 219 persist_timeout_value, length) 221 int getsockopt (sockfd, SOL_TCP, SO_PERSISTTIMEO, 222 persist_timeout_value, length) 224 where persist_timeout_value recorded in seconds is of type int and 225 the length is four. 227 The above interface allows applications to inform TCP that when the 228 local connection stays in persist condition it can be aborted after a 229 set time. Note that the default value of this option is infinite. 231 TCP sender will save the current time in the connection block when it 232 receives a zero window ACK. This time is referred to as the persist 233 entry time. Thereafter every time the probe timer expires and before 234 it sends another probe or an ACK carrying zero window is received a 235 check will be done to see how long the connection has been in persist 236 condition by comparing the current time to the persist entry time. 237 If the timeout has been exceeded, the connection will be aborted. 239 Any time a ACK is received that advertises a non-zero window, the 240 persist entry time is cleared to take the connection out of persist 241 condition. 243 8. Informative References 245 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 246 RFC 793, September 1981. 248 [RFC1122] Braden, R., "Requirements for Internet Hosts - 249 Communication Layers", STD 3, RFC 1122, October 1989. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 255 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 256 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 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 Systems 278 170 Tasman Drive 279 San Jose, CA 95134 280 USA 282 Phone: +1 (408) 527-8230 283 Email: mahesh@cisco.com 285 Anantha Ramaiah 286 Cisco Systems 287 170 Tasman Drive 288 San Jose, CA 95134 289 USA 291 Phone: +1 (408) 525-6486 292 Email: ananth@cisco.com