TCP Congestion Control with a
Misbehaving Receiver (1999)
Stefan Savage, Neal Cardwell, David Wetherall, Tom Anderson
ACM Computer Communications Review
Presented by: ilker Basaran
Roadmap







Introduction
Quick Review of TCP congestion control
Vulnerabilities – Types of Attack
Implementation Results
Proposed Solutions
Current Situation
Conclusion
Introduction & Previous Work

TCP end-to-end congestion control mechanism implicitly rely on
decent endpoints to decide proper data rate.

But misbehaving senders can send data more quickly, forcing
competing traffic to be delayed or discarded. Interestingly,
receivers can do the same, too!

This problem mentioned before [APS99, PAD+99] but not fully
appreciated.

Note that # of receivers is extremely large (all Internet users)
and has both the incentive (faster download) and opportunity
(open source OSes) to exploit this vulnerability.
Introduction (cont’d)

Previously, the trust between sender and receiver hasn’t been studied in
context of congestion control.

Traditional cryptographic security mechanisms, such as IPSEC [KA98],
can provide authentication and confidentiality but, can not prevent a
receiver from violating TCP’s congestion control specification.

Since the interests of sender and receiver may differ considerably, they
may exploit this vulnerability and undermine the fairness and stability
provided by TCP congestion control.

The potential congestion resulting from aggressive senders has received
significant attention [She94, FF99, RHE99, VRC98].

But it’s unlikely that such mechanisms will be widely deployed in the
near term, so it’s still necessary to consider the potential impact of
misbehaving receivers.
Introduction (cont’d)

What authors propose:

Identify several vulnerabilities of TCP congestion
control that can be exploited by a malicious receiver

Modify the design of TCP to eliminate this behavior
so that a malicious receiver can at most cause a
sender to transmit data at a slower rate.
Quick Review of TCP Congestion Control
Connection-oriented, reliable, ordered,
byte-stream protocol with explicit flow control
 Divides data into SMSS (Sender Maximum Segment
Size), and labels with sequence #s to guarantee ordering
and reliability
 When a host receives in-sequence segment, it sends an
ACK, if an out-of-sequence segment is received, it
sends next expected sequence #
 If no ACK received within a timeout, sender transmits
again

TCP Congestion Control Algorithms


Both Slow Start and Congestion Avoidance controls sending rate
by manipulating a congestion window (cwnd)
Slow Start:


Quickly increase and decrease cwnd to roughly approximate the
bottleneck capacity (exponential)
Congestion Avoidance:

Fine tuning. Increase cwnd more slowly to probe additional bandwidth
that may become available. (linear)
Vulnerabilities

Three types of attack:
ACK division
 DupACK spoofing
 Optimistic ACKing


In addition to DoS attacks, these techniques can
be used to enhance attacker’s throughput at the
expense of behaving clients.
Attack #1: ACK Division

RFC 2581 (most recent TCP congestion control specification at the
time of this paper) states
During slow start, TCP increments cwnd by at most SMSS
bytes for each ACK received that acknowledges new data
…
During congestion avoidance, cwnd is incremented by one
full-sized segment per RTT (round trip time)

The discord between the byte granularity of
error control and the segment granularity of
congestion control leads to vulnerability.
Attack #1: ACK Division

The Attack:
When you receive a data segment with N bytes
 Divide corresponding ACK into M pieces, where
MN
 Each separate ACK covers one of M distinct
pieces of received data

Attack #1: ACK Division
•Each ACK is valid since it covers data
that was sent and previously
unacknowledged
•This leads the sender to grow cwnd M
times faster than usual
•Receiver can control this rate of
growth, maximum M = N
Sample time line for ACK division attack.
•As seen in the example, after one RTT,
cwnd = 4, instead of the expected value
of 2
Implementation Results of ACK Division

24 lines of code added to original
code

HTTP request for index.html from
cnn.com

This attack can convince a TCP
sender to send all of its data in
send buffer in a single burst.
Single burst of data
TCP handshake starts and ends
First HTTP data from server and
many small ACKs from receiver
Attack #2: DupACK Spoofing


TCP uses two algorithms, fast retransmit and fast recovery, to
decrease the effects of packet loss
Quoted from RFC 2581
Set cwnd to ssthresh plus 3*SMSS. This artificially “inflates” the congestion
window by the number of segments (3) that have left the network and
which the receiver has buffered.
…
For each additional duplicate ACK received, increment cwnd by SMSS. This
artificially inflates the cwnd in order to reflect the additional segment that
has left the network.
Attack #2: DupACK Spoofing

Two problems with this approach

Byte vs. segment granularity problem

TCP requires exact duplicate ACKs, therefore it’s
impossible to understand which data segment they
correspond to.

There’s no way to differentiate a valid duplicate ACK with
a spoofed one
Attack #2: DupACK Spoofing

The Attack

When you receive a data segment, send lots of
ACKs for the last sequence # received (at a start of
a connection, this would be for the SYN segment)
Attack #2: DupACK Spoofing

The first four ACKs for the same
sequence # cause the sender to
retransmit the first segment.

However, cwnd is increased by SMSS
for each additional duplicate, for a total
of 4 segments

Since duplicate ACKs are
indistinguishable, this attack is also
valid.
Sample time line for DupACK attack.
Implementation Results of DupACK

11 lines of code added to original
code

The receiver sends sufficient
duplicate ACKs s.t. the sender
enters fast recovery and fills the
receiver’s flow control window
each RTT.

Like ACK Division, this attack also
can convince a TCP sender to send
all of its data in send buffer in a
single burst
TCP handshake starts and ends
Single burst of data
First HTTP data from server and
many duplicate ACKs from receiver
Attack #3: Optimistic ACKing

Since TCP’s cwnd growth is a function of RTT
(exponential during slow start, linear during congestion
avoidance), sender-receiver pairs with shorter RTT will
transfer data more quickly

Hence, it’s possible for a receiver to emulate a shorter RTT
by sending ACKs optimistically for data it has not received
yet
Attack #3: Optimistic ACKing

The Attack:
 When you receive a data segment, send lots of ACKs
anticipating data that will be sent by the sender

This attack does not preserve end-to-end reliability, e.g. if a packet
is lost, it’s unrecoverable
 However, new features in HTTP-1.1 allows receivers to request
particular byte ranges
 So, data is gathered on one connection and lost segments are
then collected selectively with application layer re-transmissions
Attack #3: Optimistic ACKing

What makes Optimistic ACKing more dangerous
After reaching to bottleneck rate, a receiver sends
ACKs in spite of losses
 By concealing losses, it eliminates the only congestion
signal available to sender
 A malicious attacker can conceal all losses and leads
the sender to increase cwnd indefinitely

Attack #3: Optimistic ACKing

Since senders generally send
full-sized segments, it’s easy for
a receiver to guess the correct
sequence # to use in ACKs, but
this accuracy is not mandatory

If an ACK arrives for the data
that has not yet been sent, this
is generally ignored by sender –
allowing the receiver to be more
aggressive
Sample time line for Optimistic ACKing attack.
Implementation Results of Optimistic
ACKing

45 lines of code added to original
code

Whenever the periodic timer (10
ms) expires, or a new data segment
arrives, receiver sends a new
optimistic ACK

The result is that the data transfer
using optimistic ACKs completes
approximately half the normal
transfer time.
Stream of early ACKs convinces the sender to
send data much earlier than it normally would
Applicability

Vulnerabilities of nine Web
servers running diverse
array of popular server
operating systems
•Linux 2.2 is not vulnerable to ACK Division, because it increases its cwnd only if at least one
whole previously unACKed segment is ACKed
•Linux 2.0 refuses to count duplicate ACKs until cwnd is greater than 3, therefore DupACK
fails if initiated on connection startup. But this attack works if started later, so an N is also put.
•Windows NT is immune to DupACK attacks, because of its apparent bug that causes it to
rarely enter fast recovery.
Roadmap – where are we ?







Introduction
Quick Review of TCP congestion control
Vulnerabilities – Types of Attack
Implementation Results
Proposed Solutions
Current Situation
Conclusion
Solutions

Inspiration from Prudent Engineering Practice for
Cryptographic Protocols [AN96], which we have read earlier.

Since the vulnerabilities arise from unstated assumptions,
obeying principles may solve the problems :



Every message should say what it means: the interpretation of the
message should depend only on its content
The condition for a message to be acted upon should be clearly set
out so that someone reviewing a design may see whether they are
acceptable or not.
If the identity of a principal is essential to the meaning of a
message, it’s convenient to mention the principal’s name explicitly
in the message
Solution to ACK Division

Ambiguity about how ACKs should be interpreted – violation of
2nd principle

Two obvious solutions

Increment cwnd only proportional to the amount of data ACKed


Discussed in [All98, All99]
Increment cwnd by one SMSS only when a valid ACK arrives
covering the entire data segment sent

This technique is being used by Linux 2.2.x
Solution to DupACK Spoofing

Since the meaning of duplicate ACK is implicit and difficult to verify, it
violates 1st principle.

So the traditional method to guarantee association between data segments
and ACKs is using a nonce.




Two new fields into TCP packet format; Nonce and Nonce Reply
Sender fills Nonce field with unique random number
Receiver generates an ACK in response to a particular data segment, and puts the
received nonce into Nonce Reply field
This Singular Nonce approach is similar to Timestamps option, but with two
important differences:


Nonce preserves association for duplicate ACKs, Timestamps does not
Timestamps is an option, so misbehaving clients has the choice not to use it
Problem with this solution


The fix requires the modification of clients and servers and
addition of two TCP fields
The purely backward compatible solutions that are sender
only heuristics can mitigate, but not eliminate, the impact
of this attack.



Maintain a count of outstanding segments sent above the missing
segment, then decrease for each duplicate ACK. After reaching
zero, ignore any additional duplicate ACK.
But, a clever receiver can ACK the missing segment and then
repeat the process indefinitely
Suggestion by [Flo95]: sender may refuse to enter fast retransmit
multiple times in a single window
Solution to Optimistic ACKing


ACKs do not contain any proof regarding the identity of the
data segment(s) that caused them to be sent, so the violation of
3rd principle.
The cumulative property of TCP’s sequence #s ensures that the
most recent ACK can cover all previously sent data. In order to
use this property, Cumulative Nonce is described as follows:



Sender fills Nonce field with unique random number
Each side maintains a nonce sum representing the cumulative sum of all
in-sequence ACKed nonces.
A receiver either echoes the current value of the nonce sum for
in-sequence data, or echoes the nonce value sent by the sender for
out-of-sequence data
Example to this solution

The fourth data segment is lost
and a third ACK attempts to
conceal this loss by ACKing a
later segment

But the ACK will be refused
since it cannot provide the
correct nonce sum (149)
Sample time line for a transfer using a cumulative nonce
A potential problem

Segment boundaries may differ between initial transmission
and subsequent retransmissions, such as in dynamic path
MTU (maximum transmission unit) change

A solution is randomly subdivide the original nonce in such
a way that the sum of new nonce values is still consistent
with original one.

If initially 1460 bytes is sent with nonce 14, then subsequent
retransmissions limited to 536 bytes by a path MTU change, data
may be sent in three packets with nonces 7, 3 and 4.
Alternative Solutions


Instead of major modifications, sender-side modifications that can
approximate a singular nonce may limit the impact of optimistic ACK attacks.

If sender randomly varies the size of outgoing segments by a small amount, a
misbehaving receiver will not be able to guess correct segment boundaries.

So the exact segment boundaries form a nonce and the sender can filter out
optimistic ACKs as those do not fall on the appropriate sequence #s
A sender may discourage malicious receivers by sending a RST for any ACK
that acknowledges data not yet sent. This does not prevent loss concealment
but can mitigate impacts of optimistic ACKs, which may be a more attractive
attack for the average user
Current Situation




RFC 3390 – Increasing TCP's Initial Window
Update to RFC 2581 - Proposed Standard,
October 2002
“This document specifies a small change to TCP
that will likely be beneficial to short-lived TCP
connections” [RFC 3390]
Not so much related to misbehaving receivers
Current Situation

RFC 3465



TCP Congestion Control with Appropriate Byte Counting (ABC)
Experimental Standard, February 2003
Directly related to the problem stated in this paper

“This document proposes a modification to the algorithm for
increasing TCP's congestion window (cwnd) that improves both
performance and security. Rather than increasing a TCP's
congestion window based on the number of acknowledgments
(ACKs) that arrive at the data sender, the congestion window is
increased based on the number of bytes acknowledged by the
arriving ACKs. ” [RFC 3465]
Conclusion

TCP has designed for cooperative environments and thus contains
several vulnerabilities.

Authors’ described three types of attack (ACK Division, DupACK
Spoofing, Optimistic ACKing) that exploit these vulnerabilities.

The design of TCP can be modified, without changing the nature of
congestion control function, to eliminate these vulnerabilities. Authors’
approach is Cumulative Nonce, which requires modification of TCP
all senders and receivers.

Authors also identified and described sender-only modifications that
can be used immediately and mitigate the affect of possible attacks
References












[All98] Mark Allman. On the generation and use of TCP acknowledgments.
Computer Communications Review,28(5), October 1998.
[All99] Mark Allman. TCP byte counting refinements.
Computer Communications Review, 29(3), July 1999.
[AN96] Martin Abadi and Roger Needham. Prudent engineering
practice for cryptographic protocols. IEEE Transactions on Software Engineering, 22(1), January 1996.
[APS99] M. Allman, V. Paxson, and W. Stevens. TCP congestion control. RFC 2581, April 1999.
[FF99] Sally Floyd and Kevin Fall. Promoting the use of end-to-end congestion control in the
Internet. IEEE/ACM Transactions on Networking, August 1999.
[Flo95] Sally Floyd. TCP and successive fast retransmits.
http://www.aciri.org/floyd/papers/fastretrans.ps, May 1995.
[KA98] S. Kent and R. Atkinson. Security architecture for the internet protocol. RFC 2401,
November 1998.
[PAD+99] V. Paxson, M. Allman, S. Dawson, W. Fenner,J. Griner, I. Heavens, K. Lahey,
J. Semke, and B. Volz.Known TCP implementation problems. RFC 2525, March 1999.
[RHE99] Reza Rejaie, Mark Handley, and Deborah Estrin. RAP: An end-to-end rate-based
congestion control mechanism for real-time streams in the Internet. In INFOCOM '99
[She94] Scott Shenker. Making greed work in networks: A game-theoretic analysis of switch
service disciplines. In SIGCOMM '94, pages 47–57, August 1994.
[VRC98] L. Vivisano, L. Rizzo, and J. Crowcroft. TCP-like congestion control for layered
multicast data transfer. In INFOCOM '98, April 1998.
http://www.zvon.org – for RFC documents
End Of Presentation
Thanks for your time…
Questions | Comments?