TCP Congestion Control with a Misbehaving Receiver Review

TCP Congestion Control with a Misbehaving Receiver Review
Review by Troy Ronda

Congestion control is a primary means for sharing scarce bandwidth
resources in the Internet. Protocols, such as TCP – the primary means
for Internet congestion control -, were designed in a cooperative
atmosphere. They were also designed at a time when ambiguities could
“float” into the protocol specs. The authors of this paper argue that
TCP should be reviewed with three principles that I will not repeat in
this review. The authors demonstrate three vulnerabilities in the TCP
congestion control protocol that arise from not following these
principles. 1) Ack division – the receiver sends multiple distinct acks
(at the byte level) for a single received segment. The sender could then
multiply the congestion window. This arises because congestion control
is implicitly at the segment granularity but TCP uses a byte-granularity
protocol. 2) DupACK spoofing – the receiver sends forged multiple
duplicate ACKS. Again the sender could increase its congestion window.
3) Optimistic Acking – the receiver sends acks before the sender has
even sent the data. This again can cause the sender to increase its
congestion window. The authors also show that all servers are vulnerable
to at least one of these attacks (in fact most O/S tested are vulnerable
to all attacks, and do increase their congestion windows). If many hosts
on the Internet were to adopt these attack strategies then congestion
control can potentially collapse. The paper goes on to describe
strategies to reduce the impact of these attacks without modifying TCP.
They also show how to eliminate these attacks with a small modification
to the protocol (adding “Nonce fields”).

This is another well written paper from Savage et al. The problems are
clearly described, shown to exist on all servers (empirically), and
solutions presented. The paper is best-effort in the sense that it fixes
what the authors can do without protocol modifications but also shows
the best case when modifications are allowed. This is a good style. The
“Nonce” modifications do appear to eliminate the vulnerabilities by
introducing “signatures” -- random numbers -- to packets and their acks.
It is unfortunate that timestamp is optional in the protocol. The
presentation of design principles for future Internet protocols, ones
that do not assume cooperative behavior, is also an insightful part of
this paper (even if not written by the authors). It was also good to see
the authors suggest that these design principles be applied to other
protocols. I would like to know if this has happened and also if hosts
are still vulnerable to these attacks. It would be somewhat amazing if
they are still vulnerable and no one has exploited them.

The first problem I had in this paper was the lack of definition for
“Nonce.” I haven’t yet had the time to look up the reference and get a
feeling for where this term came from. The authors describe TCP and yet
leave this out. I suppose it is not important but it was irritating. I
was also curious about the fact that TCP will reduce the congestion
window during packet loss. It is mentioned in the paper but I missed it
during the first read; optimistic acks destroy the senders ability to
reduce the window. I am not sure that these vulnerabilities could
collapse the Internet. Since kernel modifications are necessary (i.e.
the TCP stack), most hosts (i.e. Windows) will not be able to exploit
them (guessing here though). I should not minimize the problem, however.
It is very serious.
Received on Mon Oct 31 2005 - 10:50:31 EST