Internet DRAFT - draft-azcorra-tcpm-tcp-blind-ack-dos


Network Working Group                                         A. Azcorra
Internet-Draft                                              C. Bernardos
Expires: November 22, 2004                                       I. Soto
                                                            May 24, 2004

    DoS vulnerability of TCP by acknowledging not received segments

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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 22, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


   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",
   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:
   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

                             (        )
    ---------- ----------\  (          ) 56kbps ------------
    | SERVER |  Ethernet  >(  INTERNET >========| Attacker |
    ---------- ----------/  (          ) modem  ------------
               -> ~20Mbps    (________)

                          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 <=

   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
   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 <=
      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,
   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.

              Stewart, R., "Transmission Control Protocol security
              considerations", draft-ietf-tcpm-tcpsecure-00.txt (work in
              progress), April 2004.

              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

   Phone: +34 91 6248778

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Avda. Universidad 30
   Leganes, Madrid  28911

   Phone: +34 91 6248859

   Ignacio Soto
   Universidad Carlos III de Madrid
   Avda. Universidad 30
   Leganes, Madrid  28911

   Phone: +34 91 6245974

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

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

   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

Azcorra, et al.        Expires November 22, 2004               [Page 14]
Internet-Draft             TCP ACK DoS attack                   May 2004



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Azcorra, et al.        Expires November 22, 2004               [Page 15]