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


Network Working Group                                         A. Azcorra
Internet-Draft                                              C. Bernardos
Expires: August 3, 2004                                          I. Soto
                                                        February 3, 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 August 3, 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 (maybe even not sent).

   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 August 3, 2004                 [Page 1]
Internet-Draft             TCP ACK DoS attack              February 2004

   more dificult to perform.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2. Expeditious Blind ACK  . . . . . . . . . . . . . . . . . . . .   4
   3. Implementation experimental results  . . . . . . . . . . . . .   6
   4. Proposed solution  . . . . . . . . . . . . . . . . . . . . . .   7
   5. Security Considerations  . . . . . . . . . . . . . . . . . . .   9
      References . . . . . . . . . . . . . . . . . . . . . . . . . .  10
      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  10
      Intellectual Property and Copyright Statements . . . . . . . .  12

Azcorra, et al.          Expires August 3, 2004                 [Page 2]
Internet-Draft             TCP ACK DoS attack              February 2004

1. Introduction

   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 is 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 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 August 3, 2004                 [Page 3]
Internet-Draft             TCP ACK DoS attack              February 2004

2. Expeditious Blind ACK

   Due to the nature of the TCP congestion control, a 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.

      TCP "normal" sender              TCP "malicious" receiver
              |                                    |
              |------                              |
              |      ------                        |
              |            ------ Data 1:537       |
              |                  ------            |
              |                        ------      |
              |                              ----->|
              |                              ------|
              |               ACK 537  ------      |
              |                  ------            |
              |            ------                  |
              |      ------                  ------|
              |<-----         ACK 1073 ------      |
              |                  ------            |
              |------      ------                  |
              |      ======                        |
              |<-----      ------ Data 537:1073    |
              |                  ------            |
              |------                  ------      |
              |      ------                  ----->|
              |            ------ Data 1073:1609   |
              |                  ------            |
              |------                  ------      |
              |      ------                  ----->|
              |            ------ Data 1609:2145   |
              |                  ------            |
              |------                  ------      |
              |      ------                  ----->|
              |            ------ Data 2145:2681   |
              |                  ------            |
              |                        ------      |
              |                              ----->|
              |                                    |
              |                                    |

              Figure 1: Expeditious Blind ACK sample flow

   The attack is graphically shown in Figure 1. The "malicious" receiver
   sends ACK segments that acknowledges data yet not received. There are

Azcorra, et al.          Expires August 3, 2004                 [Page 4]
Internet-Draft             TCP ACK DoS attack              February 2004

   some points that make this attack feasible:

   o  It is easy to anticipate the sequence numbers to use in each ACK
      because senders generally send full-sized segments.

   o  Most TCP implementations ignore received ACKs for segments that
      have not been sent yet. Therefore, it is easy to deploy some
      arbitrarily aggressive attacks (e.g. linear and exponential
      sequence number growths), even simultaneously.

Azcorra, et al.          Expires August 3, 2004                 [Page 5]
Internet-Draft             TCP ACK DoS attack              February 2004

3. Implementation experimental results

   In order to prove that the attack described in this document is
   possible and very harmful, a small attacker tool (TermiNETor) has
   been developed under a GNU/Linux system. This tool basically
   establishes a configurable number of simultaneous TCP connections
   (HTTP) to a server, and after the connection establishment, it starts
   a blind ACK generation, with configurable both linear and exponential
   growth. More parameters are also configurable, like the Receiver
   Maximum Segment Size (RMSS) specified by the sender during the
   connection establishment, the initial number of bytes acknowledged
   (usually the RMSS), the number of ACKs sent, and some more.

   With a very preliminar version of this tool, we are able to, with a
   56kbps client connection, make the sender generate about 25Mbps of
   outbound traffic. If this tool is used in a distributed way, a far
   more harmful DoS is possible.

   More attacks and to different server architectures (O.S. and server
   implementations) should be performed in order to check if there is
   any O.S. that fixes this problem. Based on the results presented in
   [SAVAGE] and on the fact that the problem is not related to
   implementation bugs but to the TCP specification, we think that the
   problem is present in all TCP/IP stacks and that a solution should be
   provided and standardized.

   Although this attack is well known today, it seems that there is a
   lack of proposed solutions to solve this problem without changing the
   client's TCP/IP stack. We have shown, by developing an attacker tool
   that the attack is possible and very harmful. Therefore, a solution
   involving only changes on the server side should be proposed,
   discussed and deployed.

Azcorra, et al.          Expires August 3, 2004                 [Page 6]
Internet-Draft             TCP ACK DoS attack              February 2004

4. Proposed solution

   TCP Congestion Control [RFC2581] does not provide any mechanism to
   avoid misbehaving malicious TCP receivers perform DoS attacks. A
   sender has no means to be aware that the receiver has really received
   the packets it has acknowledged, so the sender increase its sending
   data rate based on the small RTTs calculated due to the fake ACKs

   TCP should provide a mechanism in order to assure that receivers have
   in fact received the data they acknowledge. This kind of solutions
   [SAVAGE] require changes in TCP/IP stacks of both clients and
   servers, which is a non realistic approach nowadays.

   We propose a few changes, only on the TCP stack of the server side,
   that can greatly reduce the risk of suffering this kind of DoS
   attack. The proposed changes are the following:

   1.  A server SHOULD reset the TCP connection (i.e. send a RST) if it
       receives an ACK for data that the server has not sent yet.

   2.  A server SHOULD ignore ACKs that do not match the boundary of one
       of the segments it has sent.

   3.  A server SHOULD randomize segment boundaries (e.g. between 0.9
       RMSS and RMSS).

   The first modification is intended to disconnect an attacker that has
   sent acknowledgements in a too aggresive way (too fast), and its
   acknowledgements arrive to the sender before the corresponding data
   has been sent. This modification would force the attacker program to
   be more cautious in its acknowledgement rate, or to perform
   adaptative meassurements to force the rate to the maximum, but
   without exceeding it. However, the attack would still be feasible.

   The second modification intends to allow the sender distinguish
   between incoming "real" acknowlegements from "fake" ones. Real
   acknowledgements usually match segment boundaries, while fake ones
   may not when introducting modification 3. The reason to ignore the
   acknoledgements that do not match a boundary instead of reseting the
   connection, as done in modification 1, is that it is legal for a
   receiver to acknoledge part of a received segment. We have performed
   some experiments, and this appears to be a rare behaviour. Therefore,
   we believe it is an acceptable compromise to ignore the ACKs that do
   not match a boundary: a) For an attacker, this would force it to send
   much more ACKs for one to be accepted, making the attack more costly.
   b) for a correct TCP implementation, this would just cause an
   unnecessary retransmission. The situation would recover after the

Azcorra, et al.          Expires August 3, 2004                 [Page 7]
Internet-Draft             TCP ACK DoS attack              February 2004

   retransmission because the elapsed time would allow the receiver data
   to drain, and the complete retransmitted segment would then be

   The third modification is needed to make the second one effective.
   The objective is 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 sender will
   fill the segments up to SMMS as long as it has data to transmit,
   which is the case in a file download. With this modification, correct
   implementations would know the sequence number to aknowledge, while
   an attacker implementation would not.

   These changes make this attack considerably more difficult without
   requiring changes in the client side (most of the Internet hosts).
   The implemetation of the proposed changes on the server side is
   considered minor, and implies a low increase on the computational
   load of the protocol. The main modifications is that the server has
   to maintain a list of the border sequence numbers sent, while
   currently is enough with a variable storing the sequence number of
   the highest data octet sent. Randomizing the size of the sent segment
   is not considered costly because the random distribution is not
   subject to cryptographical requirements, i.e. a simple pseudo-random
   technique would make the attack difficult enough.

Azcorra, et al.          Expires August 3, 2004                 [Page 8]
Internet-Draft             TCP ACK DoS attack              February 2004

5. 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 August 3, 2004                 [Page 9]
Internet-Draft             TCP ACK DoS attack              February 2004


   [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., "Transmision 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.

              Nordmark, E. and T. Li, "Threats relating to IPv6
              multihoming solutions",
              draft-nordmark-multi6-threats-00.txt (work in progress),
              October 2003.

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 6248756

Azcorra, et al.          Expires August 3, 2004                [Page 10]
Internet-Draft             TCP ACK DoS attack              February 2004

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

   Phone: +34 91 6245974

Azcorra, et al.          Expires August 3, 2004                [Page 11]
Internet-Draft             TCP ACK DoS attack              February 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 August 3, 2004                [Page 12]
Internet-Draft             TCP ACK DoS attack              February 2004



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

Azcorra, et al.          Expires August 3, 2004                [Page 13]