Internet DRAFT - draft-azcorra-tcpm-tcp-blind-ack-dos
draft-azcorra-tcpm-tcp-blind-ack-dos
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]
