Network Working Group A. Azcorra Internet-Draft C. Bernardos Expires: November 22, 2004 I. Soto UC3M May 24, 2004 DoS vulnerability of TCP by acknowledging not received segments draft-azcorra-tcpm-tcp-blind-ack-dos-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 22, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract TCP relies in communication peers to implement congestion control by hosts voluntary limiting their own data rate. Nevertheless this assumption introduces unsolved DoS attack opportunities. A DoS attack can be easily performed by a host that acknowledges TCP segments not yet received. This document presents and briefly describes the problem, already identified and pointed before, but also shows than it can be easily performed (with very interesting results) and proposes some server-side modifications to TCP stack in order to make this attack Azcorra, et al. Expires November 22, 2004 [Page 1] Internet-Draft TCP ACK DoS attack May 2004 more difficult to perform. These modifications do not cause interoperability issues. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Expeditious Blind ACK DoS . . . . . . . . . . . . . . . . . . 4 2.1 Description of the attack . . . . . . . . . . . . . . . . 4 2.2 Proposed Solutions . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Starting a slow start procedure . . . . . . . . . . . 7 2.2.2 Matching SEG.ACK and (SEG.SEQ + SEG.LEN) . . . . . . . 8 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 14 Azcorra, et al. Expires November 22, 2004 [Page 2] Internet-Draft TCP ACK DoS attack May 2004 1. Introduction TCP [RFC793] is widely deployed and one of the most often used reliable end to end protocols for data communication. Nevertheless, as described in a recent draft [draft-ietf-tcpm-tcpsecure-00], there are some dangerous threats to the protocol. Besides the attacks described in [draft-ietf-tcpm-tcpsecure-00], there are other threats, like the one described in this document. TCP Congestion Control, described in RFC 2581 [RFC2581], relies in the peers involved in a communication. Therefore, hosts should voluntary limit their own sending data rate. The problem is that TCP does not provide a mechanism to ensure that this bandwidth sharing on the Internet works. As stated in RFC 2581 [RFC2581], the Internet to a considerable degree relies on the correct implementation of the congestion control algorithms in order to preserve network stability and avoid network collapse. It is also pointed that an attacker could cause TCP endpoints to response more aggressively in the face of congestion by forging excessive duplicates acknowledgements or excessive acknowledgements for new data, driving a portion of the network into congestion collapse. [SAVAGE] describes some of the these possible vulnerabilities of the TCP Congestion Control, not originated from bad implementations but for the TCP Congestion Control specification itself. These vulnerabilities can be exploited in order to obtain faster data incoming rate, but also to perform massive DoS attacks. One of these attacks, which is well known and it is pointed also in other documents (i.e. [draft-nordmark-multi6-threats]) is a especially dangerous attack. In this document we review this attack and prove that it could be performed (by presenting results from some tests of a first implementation of an attacker), and we also provide a not very complex solution proposal, involving only changes on the server-side (attacked side) TCP stack. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Azcorra, et al. Expires November 22, 2004 [Page 3] Internet-Draft TCP ACK DoS attack May 2004 2. Expeditious Blind ACK DoS 2.1 Description of the attack Due to the nature of the TCP congestion control, a malicious misbehaving receiver could acknowledge TCP segments not yet received, emulating this way a shorter round-trip time between sender and receiver. Because of the TCP's congestion window nature (linear growth with round-trip time), the sender will send data faster. Notice that the malicious receiver will acknowledge the segments even if they are lost in transit, because its objective is to saturate the network interface of the server. This is, the objective is not to increase its receiving data rate. TCP "normal" sender TCP "malicious" receiver | | Data 1:537 |------ | | ------ | | ------ | | ------ | | ------ | | ----->| | ······|ACK 538 | ······ | | ······ | | ······ ······|ACK 1610 | ······ ······ | |<····· ······ | Data 538:1073 |------ ······ ······|ACK 2682 Data 1074:1609|******------ ······ | |<·····******--X ······ | Data 1610:2145|------ ****** ······|ACK 4826 Data 2146:2681|******------ ******······ | Data 2682:3217|<+++++******------······****** | Data 3218:3753|------++++++***X ------ *****>|ACK 9114 | ------++++++ ------ | |<····· ----X ++++++ ----->| | ······ ++++++ | | ······ +++++>| Figure 1: Expeditious Blind ACK sample flow This attack is intended for information servers. The reason for this is that at an information server the attacker will be able to find a sufficiently large downloadable file. This is necessary to be able to scale the sending rate to achieve a sufficiently large one. In the tests we have been performing, a file size of 1 Mbyte with a MSS of Azcorra, et al. Expires November 22, 2004 [Page 4] Internet-Draft TCP ACK DoS attack May 2004 1,440 bytes and normal window size was enough to induce the server to a sending rate of 20 Mbps (with only 48kbps of upstream bandwidth available for the attacker). The attack is graphically shown in Figure 1. The "malicious" receiver sends ACK segments that acknowledges data yet not received (we call it a blind ACK attack in this sense). There are some points that make this attack feasible: o The malicious receiver needs to send ACKs that are between the lowest and highest sequence number of unacknowledged data sent: SND.UNA <= SEG.ACK <= SND.NXT o Most TCP implementations ignore incoming ACKs that are out of the range stated in the previous point, even for data that has not yet been sent. Because of these two facts, it is easy to perform arbitrarily aggressive attacks (e.g. linear and exponential sequence number growths), even simultaneously. This is so because if the malicious receiver overestimates the sending rate, and sends an ACK for data not yet sent, it will just be ignored by the server. Besides, for the attack that we have identified and tested, which is to induce the servers to send data at massive rates, there is no problem in loosing segments, because the receiver has no interest in getting the information. It is therefore a dangerous Denial-of-Service attack that can be performed through a low-speed link, and causing a high and useless throughput in the information server. ________ ( ) ---------- ----------\ ( ) 56kbps ------------ | SERVER | Ethernet >( INTERNET >========| Attacker | ---------- ----------/ ( ) modem ------------ -> ~20Mbps (________) (injected traffic) Figure 2: DoS Attack Real trials that we have performed with a very simple prototype of an attacker program shows that the attack is not only possible, but also very harmful. The configuration of one of the trials performed is shown in Figure 2. An attacker program installed in a PC connected through a 56 kpbs modem (48 kbps upstream) is capable of tricking an information server to inject 20 Mbps of useless traffic, i.e. to waist a considerable amount of the physical bandwidth of the interface. If the attacker program implementation is improved to Azcorra, et al. Expires November 22, 2004 [Page 5] Internet-Draft TCP ACK DoS attack May 2004 allow it to self-adapt to the sending rate, even more harmful results would be obtained. The upper limit on the effectiveness of this attack depends on the relative size of an ACK and the sending window. In the best case (for the attacker) the attacker needs to send only one ACK for each full window sent by the information server. One ACK, including data link overhead, is around 360 bits. This would cause the information server to deliver around 541 Kbits, including data link overhead. As an example, implies that with a 48 Kbps ACK sending rate, and a window size of 64 Kbytes, it would be theoretically possible to induce a sending rate of 72.1 Mbps on the information server. It should be also noted that using large window sizes (SND.WND) the upper limit of the attack is higher, and the attack becomes more dangerous, because a single ACK would acknowledge a larger amount of data sent by the information server. Finally, we want to remark that to actually achieve the maximum sending rate it is required a sustained flow of information to be sent by the information server, implying the existence of a downloadable file above a certain size. Based on our trials, a file size around 1 Mbyte is enough in practice to achieve a high sending rate with the normal window size. 2.2 Proposed Solutions A current TCP sender has no means to be sure that the receiver has really received the packets it has acknowledged, so the sender increases its sending data rate based on the small RTTs calculated due to the fake ACKs received. One approach would be to design a mechanism that guarantees that receivers have in fact received the data they acknowledge. This is the approach followed in [SAVAGE], but this introduces considerable complexity and requires changes in the TCP/IP stack of both the clients and the servers, which is a clear drawback, because it introduced the problem of backwards compatibility with the current TCP/IP versions. We follow another approach to avoid the attack, with the advantage of implying a low implementation complexity, and requiring only changes in the TCP/IP stack of the server side. Moreover, this approach is interoperable with current implementations, avoiding the problem of migration and backward compatibility. We propose here a few changes as possible solutions but we acknowledge that more thinking is needed in order to decide the best set of solutions to apply. In other words, the solution space is yet open to more discussion. Azcorra, et al. Expires November 22, 2004 [Page 6] Internet-Draft TCP ACK DoS attack May 2004 2.2.1 Starting a slow start procedure The first proposed change is the following: 1. A server MUST start the slow start procedure if it receives an ACK for data that is within the interval SND.NXT < SEG.ACK <= SND.UNA+SND.WND This modification is intended to penalize an attacker (detected when receiving ACKs that acknowledge data not yet sent, but close to the data pending to be acknowledged) when it is excessively aggressive in the sending rate of ACKs, by penalizing the performance of the TCP connection and, also in this way, desynchronising the attacker. The attacker generally will be loosing many of the packets sent by the information server, so it would loose the synchronisation if the sender starts a slow start procedure. It is very important to avoid that this modification could be used by a malicious third party to attack a legitimate TCP connection. To get advantage of this modification, a malicious third party would need to: o Know the source IP address, the destination IP address, the source TCP port number and the destination TCP port number. o Fake the source IP address of the packets it generates. o Guess a sequence number and an acknowledge sequence number, both for the same packet sent, that fulfil conditions a) and b): a) The sequence number must be within the receive window of the peer that receives the ACK segment, i.e.: RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND b) The sequence number to be acknowledged has to be within the transmitter window of the peer that receives the ACK segment, i.e.: SND.NXT < SEG.ACK <= SND.UNA+SND.WND As the initial sequence number of a connection are cryptographically random, the chance of guessing them is negligible. A brute force attack on the sequence numbers would require, for the normal window size, sending at least 2^32 packets to fulfil conditions a) and b). We therefore conclude that this modification does not introduce a security risk for the case of the default maximum window size. For the window scale option [RFC1323], the risk of penalizing a connection sending an ACK based on this modification would be proportional to the selected window scale factor. With all of these the attacking party would only achieve a decrease in the performance on the legitimate TCP connection. We think that the feasibility of this kind of attack and the damage created are so low that the first modification is a very reasonable solution. Azcorra, et al. Expires November 22, 2004 [Page 7] Internet-Draft TCP ACK DoS attack May 2004 One question may arise at this point: if the probability of using this modification to perform an attack by a third party is so low, why do not take a more drastic measure, like resetting the connection? We have considered this option, but there are some points that make more useful to start a slow start procedure: o While trying to make an information server to flood its link, an attacker is wasting its outbound link sending ACK segments. If the information server sends an RST segment when it thinks that a possible attack is being performed, the attacker will be aware also of this, and it could restart the process, without continuing wasting its outbound bandwidth. On the other hand, if the slow start procedure is done, the attacker would not be aware of that (or at least not so early), and it will continue wasting its outbound bandwidth sending ACK segments that would be out of the window, and therefore not making the server to send data faster. o Although for a third party trying to gain advantage to this modification to reset a legitimate connection would be very difficult, if the window scale option is used, the probability may not be negligible. On the other hand, when the slow start procedure is used, a third party attacker would only get a penalty in the performance of a legitimate TCP connection. Besides, if needed, the server could be even less aggressive starting the slow start procedure with CWND = N MSS (N=2,4). 2.2.2 Matching SEG.ACK and (SEG.SEQ + SEG.LEN) There is second modification that could be introduced, instead of, or in addition to, the previous one. This modification makes the system more robust to this attack, but, has the cost of increasing the complexity of the implementation. The second modification that could be introduced is the following: 2.a) A server SHOULD randomize segment boundaries in the range [MS, a*MS] 2.b) A server should accept an ACK with a SEG.ACK value which, being in the range [SND.UNA, SND.NXT], does not match exactly the (SEG.SEQ + SEG.LEN) value of one of the unacknowledged segments that have been sent, but, would not increase its CWND variable in this case. Parameter MS is the current maximum segment size, i.e., the minimum between SMSS and SND.WND. Parameter "a" is a number in the range [0,1]. Its optimal value would have to be determined to reach a compromise between transmission efficiency (maximize segment size) and robustness under this attack (maximize the randomness). This modification intends to allow the sender to distinguish between incoming "real" acknowledgements from "fake" ones. Real acknowledgements usually match segment boundaries, while fake ones Azcorra, et al. Expires November 22, 2004 [Page 8] Internet-Draft TCP ACK DoS attack May 2004 will not. The first part of this modification (2.a) is needed to make it difficult for an attacker to anticipate the sequence numbers to use in the ACKs. Currently, it is trivial for the attacker to anticipate the segment boundaries, as the information server will fill the segments up to SMSS as long as it has data to transmit, which is the case in a file download. With this modification, a standard correct receiver implementation would know the sequence number to acknowledge, while an attacker implementation would not. The second part of this modification (2.b) is considered a compromise between the two extreme cases of either ignoring the ACK or fully accepting it: Fully accepting the ACK is the current situation, that ignores the dangers brought by the attack described in this document. Ignoring the ACK would penalize the infrequent, but existing, case of valid ACKs that do not match a boundary. It penalizes this case because the receiver ignores the ACKs and would therefore retransmit based on time out. This would slow the communication, and even completely stop it, unless the receiver gets an ACK that matches a boundary. The proposed solution allows the communication to continue, but not to increase rate, while the ACKs do not match a boundary. Azcorra, et al. Expires November 22, 2004 [Page 9] Internet-Draft TCP ACK DoS attack May 2004 3. Conclusions The DOS attack described in this document has been tested in real networks, and has been proven to be very effective against information servers. The proposed solution described here affects only the TCP stack of the server side, and it does not create an interoperability problem because it is compatible with current implementations of the TCP stack at the client side. The proposed solution is composed of two possible modifications that can be introduced separately or together. Modification 1) is simple to code, and implies a negligible increase on the computational load of the protocol, yet, it would reduce very much the effects of the attack. Modification 2) is also simple to code, but, it introduces a slight increase in computational load (the server has to maintain a list of the border sequence numbers sent, while currently is enough with a variable storing the sequence number). Modification 2) also has the drawback of somehow penalizing the performance in the cases of a valid client that does not send ACKs matching the boundaries. Azcorra, et al. Expires November 22, 2004 [Page 10] Internet-Draft TCP ACK DoS attack May 2004 4. Security Considerations This document presents some changes in order to improve security on the Internet, difficulting some DoS attacks that are possible now, without introducing any new attack opportunities. Azcorra, et al. Expires November 22, 2004 [Page 11] Internet-Draft TCP ACK DoS attack May 2004 5. Acknowledgements The authors wish to thank Randall Stewart (cisco) and Mark Allman (ICIR) for their very valuable comments about the solutions proposed in this draft. Some of the proposed solutions are the result of a fruitful exchange of ideas with them about this draft. We wish also to thank Joe Touch (ISI-USC) for his comments. 6 References [RFC1323] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [SAVAGE] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Communications Review 29(5), October 1999. [draft-ietf-tcpm-tcpsecure-00] Stewart, R., "Transmission Control Protocol security considerations", draft-ietf-tcpm-tcpsecure-00.txt (work in progress), April 2004. [draft-nordmark-multi6-threats] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming solutions", draft-nordmark-multi6-threats-00.txt (work in progress), October 2003. Azcorra, et al. Expires November 22, 2004 [Page 12] Internet-Draft TCP ACK DoS attack May 2004 Authors' Addresses Arturo Azcorra Universidad Carlos III de Madrid Avda. Universidad 30 Leganes, Madrid 28911 Spain Phone: +34 91 6248778 EMail: azcorra@it.uc3m.es URI: http://www.it.uc3m.es/azcorra/ Carlos J. Bernardos Universidad Carlos III de Madrid Avda. Universidad 30 Leganes, Madrid 28911 Spain Phone: +34 91 6248859 EMail: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Ignacio Soto Universidad Carlos III de Madrid Avda. Universidad 30 Leganes, Madrid 28911 Spain Phone: +34 91 6245974 EMail: isoto@it.uc3m.es URI: http://www.it.uc3m.es/isoto/ Azcorra, et al. Expires November 22, 2004 [Page 13] Internet-Draft TCP ACK DoS attack May 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Azcorra, et al. Expires November 22, 2004 [Page 14] Internet-Draft TCP ACK DoS attack May 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Azcorra, et al. Expires November 22, 2004 [Page 15]