idnits 2.17.1 draft-azcorra-tsvwg-tcp-blind-ack-dos-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 3, 2004) is 7382 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC793' is defined on line 272, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAVAGE' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Azcorra 2 Internet-Draft C. Bernardos 3 Expires: August 3, 2004 I. Soto 4 UC3M 5 February 3, 2004 7 DoS vulnerability of TCP by acknowledging not received segments 8 draft-azcorra-tsvwg-tcp-blind-ack-dos-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 3, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 TCP relies in communication peers to implement congestion control by 39 hosts voluntary limiting their own data rate. Nevertheless this 40 assumption introduces unsolved DoS attack opportunities. 42 A DoS attack can be easily performed by a host that acknowledges TCP 43 segments not yet received (maybe even not sent). 45 This document presents and briefly describes the problem, already 46 identified and pointed before, but also shows than it can be easily 47 performed (with very interesting results) and proposes some 48 server-side modifications to TCP stack in order to make this attack 49 more dificult to perform. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Expeditious Blind ACK . . . . . . . . . . . . . . . . . . . . 4 55 3. Implementation experimental results . . . . . . . . . . . . . 6 56 4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 60 Intellectual Property and Copyright Statements . . . . . . . . 12 62 1. Introduction 64 TCP Congestion Control, described in RFC 2581 [RFC2581], relies in 65 the peers involved in a communication. Therefore, hosts should 66 voluntary limit their own sending data rate. The problem is that TCP 67 does not provide a mechanism to ensure that this bandwidth sharing on 68 the Internet works. As is stated in RFC 2581 [RFC2581], the Internet 69 to a considerable degree relies on the correct implementation of the 70 congestion control algorithms in order to preserve network stability 71 and avoid network collapse. It is also pointed that an attacker could 72 cause TCP endpoints to response more aggressively in the face of 73 congestion by forging excessive duplicates acknowledgements or 74 excessive acknowledgements for new data, driving a portion of the 75 network into congestion collapse. 77 [SAVAGE] describes some of the these possible vulnerabilities of the 78 TCP Congestion Control, not originated from bad implementations but 79 for the TCP Congestion Control specification itself. These 80 vulnerabilities can be exploited in order to obtain faster data 81 incoming rate, but also to perform massive DoS attacks. One of these 82 attacks, which is well known and it is pointed also in other 83 documents (i.e. [draft-nordmark-multi6-threats]) is a especially 84 dangerous attack. In this document we review this attack and prove it 85 could be performed (by presenting results from some tests of a first 86 implementation of an attacker), and we also provide a not very 87 complex solution proposal, involving only changes on the server-side 88 (attacked side) TCP stack. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2. Expeditious Blind ACK 96 Due to the nature of the TCP congestion control, a misbehaving 97 receiver could acknowledge TCP segments not yet received, emulating 98 this way a shorter round-trip time between sender and receiver. 99 Because of the TCP's congestion window nature (linear growth with 100 round-trip time), the sender will send data faster. 102 TCP "normal" sender TCP "malicious" receiver 103 | | 104 |------ | 105 | ------ | 106 | ------ Data 1:537 | 107 | ------ | 108 | ------ | 109 | ----->| 110 | ------| 111 | ACK 537 ------ | 112 | ------ | 113 | ------ | 114 | ------ ------| 115 |<----- ACK 1073 ------ | 116 | ------ | 117 |------ ------ | 118 | ====== | 119 |<----- ------ Data 537:1073 | 120 | ------ | 121 |------ ------ | 122 | ------ ----->| 123 | ------ Data 1073:1609 | 124 | ------ | 125 |------ ------ | 126 | ------ ----->| 127 | ------ Data 1609:2145 | 128 | ------ | 129 |------ ------ | 130 | ------ ----->| 131 | ------ Data 2145:2681 | 132 | ------ | 133 | ------ | 134 | ----->| 135 | | 136 | | 138 Figure 1: Expeditious Blind ACK sample flow 140 The attack is graphically shown in Figure 1. The "malicious" receiver 141 sends ACK segments that acknowledges data yet not received. There are 142 some points that make this attack feasible: 144 o It is easy to anticipate the sequence numbers to use in each ACK 145 because senders generally send full-sized segments. 147 o Most TCP implementations ignore received ACKs for segments that 148 have not been sent yet. Therefore, it is easy to deploy some 149 arbitrarily aggressive attacks (e.g. linear and exponential 150 sequence number growths), even simultaneously. 152 3. Implementation experimental results 154 In order to prove that the attack described in this document is 155 possible and very harmful, a small attacker tool (TermiNETor) has 156 been developed under a GNU/Linux system. This tool basically 157 establishes a configurable number of simultaneous TCP connections 158 (HTTP) to a server, and after the connection establishment, it starts 159 a blind ACK generation, with configurable both linear and exponential 160 growth. More parameters are also configurable, like the Receiver 161 Maximum Segment Size (RMSS) specified by the sender during the 162 connection establishment, the initial number of bytes acknowledged 163 (usually the RMSS), the number of ACKs sent, and some more. 165 With a very preliminar version of this tool, we are able to, with a 166 56kbps client connection, make the sender generate about 25Mbps of 167 outbound traffic. If this tool is used in a distributed way, a far 168 more harmful DoS is possible. 170 More attacks and to different server architectures (O.S. and server 171 implementations) should be performed in order to check if there is 172 any O.S. that fixes this problem. Based on the results presented in 173 [SAVAGE] and on the fact that the problem is not related to 174 implementation bugs but to the TCP specification, we think that the 175 problem is present in all TCP/IP stacks and that a solution should be 176 provided and standardized. 178 Although this attack is well known today, it seems that there is a 179 lack of proposed solutions to solve this problem without changing the 180 client's TCP/IP stack. We have shown, by developing an attacker tool 181 that the attack is possible and very harmful. Therefore, a solution 182 involving only changes on the server side should be proposed, 183 discussed and deployed. 185 4. Proposed solution 187 TCP Congestion Control [RFC2581] does not provide any mechanism to 188 avoid misbehaving malicious TCP receivers perform DoS attacks. A 189 sender has no means to be aware that the receiver has really received 190 the packets it has acknowledged, so the sender increase its sending 191 data rate based on the small RTTs calculated due to the fake ACKs 192 received. 194 TCP should provide a mechanism in order to assure that receivers have 195 in fact received the data they acknowledge. This kind of solutions 196 [SAVAGE] require changes in TCP/IP stacks of both clients and 197 servers, which is a non realistic approach nowadays. 199 We propose a few changes, only on the TCP stack of the server side, 200 that can greatly reduce the risk of suffering this kind of DoS 201 attack. The proposed changes are the following: 203 1. A server SHOULD reset the TCP connection (i.e. send a RST) if it 204 receives an ACK for data that the server has not sent yet. 206 2. A server SHOULD ignore ACKs that do not match the boundary of one 207 of the segments it has sent. 209 3. A server SHOULD randomize segment boundaries (e.g. between 0.9 210 RMSS and RMSS). 212 The first modification is intended to disconnect an attacker that has 213 sent acknowledgements in a too aggresive way (too fast), and its 214 acknowledgements arrive to the sender before the corresponding data 215 has been sent. This modification would force the attacker program to 216 be more cautious in its acknowledgement rate, or to perform 217 adaptative meassurements to force the rate to the maximum, but 218 without exceeding it. However, the attack would still be feasible. 220 The second modification intends to allow the sender distinguish 221 between incoming "real" acknowlegements from "fake" ones. Real 222 acknowledgements usually match segment boundaries, while fake ones 223 may not when introducting modification 3. The reason to ignore the 224 acknoledgements that do not match a boundary instead of reseting the 225 connection, as done in modification 1, is that it is legal for a 226 receiver to acknoledge part of a received segment. We have performed 227 some experiments, and this appears to be a rare behaviour. Therefore, 228 we believe it is an acceptable compromise to ignore the ACKs that do 229 not match a boundary: a) For an attacker, this would force it to send 230 much more ACKs for one to be accepted, making the attack more costly. 231 b) for a correct TCP implementation, this would just cause an 232 unnecessary retransmission. The situation would recover after the 233 retransmission because the elapsed time would allow the receiver data 234 to drain, and the complete retransmitted segment would then be 235 acknowleged. 237 The third modification is needed to make the second one effective. 238 The objective is to make it difficult for an attacker to anticipate 239 the sequence numbers to use in the ACKs. Currently, it is trivial for 240 the attacker to anticipate the segment boundaries, as the sender will 241 fill the segments up to SMMS as long as it has data to transmit, 242 which is the case in a file download. With this modification, correct 243 implementations would know the sequence number to aknowledge, while 244 an attacker implementation would not. 246 These changes make this attack considerably more difficult without 247 requiring changes in the client side (most of the Internet hosts). 248 The implemetation of the proposed changes on the server side is 249 considered minor, and implies a low increase on the computational 250 load of the protocol. The main modifications is that the server has 251 to maintain a list of the border sequence numbers sent, while 252 currently is enough with a variable storing the sequence number of 253 the highest data octet sent. Randomizing the size of the sent segment 254 is not considered costly because the random distribution is not 255 subject to cryptographical requirements, i.e. a simple pseudo-random 256 technique would make the attack difficult enough. 258 5. Security Considerations 260 This document presents some changes in order to improve security on 261 the Internet, difficulting some DoS attacks that are possible now, 262 without introducing any new attack opportunities. 264 References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 270 Control", RFC 2581, April 1999. 272 [RFC793] Postel, J., "Transmision Control Protocol", STD 7, RFC 273 793, September 1981. 275 [SAVAGE] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson, 276 "TCP Congestion Control with a Misbehaving Receiver", ACM 277 Communications Review 29(5), October 1999. 279 [draft-nordmark-multi6-threats] 280 Nordmark, E. and T. Li, "Threats relating to IPv6 281 multihoming solutions", 282 draft-nordmark-multi6-threats-00.txt (work in progress), 283 October 2003. 285 Authors' Addresses 287 Arturo Azcorra 288 Universidad Carlos III de Madrid 289 Avda. Universidad 30 290 Leganes, Madrid 28911 291 Spain 293 Phone: +34 91 6248778 294 EMail: azcorra@it.uc3m.es 295 URI: http://www.it.uc3m.es/azcorra/ 297 Carlos J. Bernardos 298 Universidad Carlos III de Madrid 299 Avda. Universidad 30 300 Leganes, Madrid 28911 301 Spain 303 Phone: +34 91 6248756 304 EMail: cjbc@it.uc3m.es 305 URI: http://www.it.uc3m.es/cjbc/ 306 Ignacio Soto 307 Universidad Carlos III de Madrid 308 Avda. Universidad 30 309 Leganes, Madrid 28911 310 Spain 312 Phone: +34 91 6245974 313 EMail: isoto@it.uc3m.es 314 URI: http://www.it.uc3m.es/isoto/ 316 Intellectual Property Statement 318 The IETF takes no position regarding the validity or scope of any 319 intellectual property or other rights that might be claimed to 320 pertain to the implementation or use of the technology described in 321 this document or the extent to which any license under such rights 322 might or might not be available; neither does it represent that it 323 has made any effort to identify any such rights. Information on the 324 IETF's procedures with respect to rights in standards-track and 325 standards-related documentation can be found in BCP-11. Copies of 326 claims of rights made available for publication and any assurances of 327 licenses to be made available, or the result of an attempt made to 328 obtain a general license or permission for the use of such 329 proprietary rights by implementors or users of this specification can 330 be obtained from the IETF Secretariat. 332 The IETF invites any interested party to bring to its attention any 333 copyrights, patents or patent applications, or other proprietary 334 rights which may cover technology that may be required to practice 335 this standard. Please address the information to the IETF Executive 336 Director. 338 Full Copyright Statement 340 Copyright (C) The Internet Society (2004). All Rights Reserved. 342 This document and translations of it may be copied and furnished to 343 others, and derivative works that comment on or otherwise explain it 344 or assist in its implementation may be prepared, copied, published 345 and distributed, in whole or in part, without restriction of any 346 kind, provided that the above copyright notice and this paragraph are 347 included on all such copies and derivative works. However, this 348 document itself may not be modified in any way, such as by removing 349 the copyright notice or references to the Internet Society or other 350 Internet organizations, except as needed for the purpose of 351 developing Internet standards in which case the procedures for 352 copyrights defined in the Internet Standards process must be 353 followed, or as required to translate it into languages other than 354 English. 356 The limited permissions granted above are perpetual and will not be 357 revoked by the Internet Society or its successors or assignees. 359 This document and the information contained herein is provided on an 360 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 361 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 362 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 363 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 364 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 366 Acknowledgment 368 Funding for the RFC Editor function is currently provided by the 369 Internet Society.