Network Working Group A. Azcorra
Internet-Draft C. Bernardos
Expires: August 3, 2004 I. Soto
UC3M
February 3, 2004
DoS vulnerability of TCP by acknowledging not received segments
draft-azcorra-tsvwg-tcp-blind-ack-dos-00
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 August 3, 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 (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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
received.
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
acknowleged.
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
References
[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.
[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.
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 6248756
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
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
Spain
Phone: +34 91 6245974
EMail: isoto@it.uc3m.es
URI: http://www.it.uc3m.es/isoto/
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
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 August 3, 2004 [Page 12]
Internet-Draft TCP ACK DoS attack February 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 August 3, 2004 [Page 13]