This paper shows us several vulnerabilities of TCP in case of a
misbehaving or malicious receiver. These flaws are partly due to the
original assumption of a cooperative environment and partly due to some
less careful design and implementation. The authors further propose
several ways to change TCP implementation so that the attacks to these
vulnerabilities can be avoided.
I do agree that the new implementations of TCP should consider their
suggestion. However, singular nonce and cumulative nonce seem not
practical since both sender and receiver of TCP must change to add these
mechanisms. It is almost impossible to force all receivers change their
TCP to the new version in years.
Even if changes are only related with TCP sender, new versions are also
not easily to distribute quickly since TCP is such an important protocol
that every change and its side effect must be considered thoroughly before
it is applied into industry.
On the other hand, I argue the impact of these vulnerabilities is not so
fatal for today's Internet. If the misbehaving receiver is motivated by
achieving high throughput, the transmission throughput is mainly limited
by the last mile instead of the server side. Another possibility is that
the misbehaving receiver wants to waste the server's network bandwidth and
disturb the Internet. However, servers could set bandwidth limit for each
user so that they will not occupy too much network resources. In my
opinion, limitation and detection are two good approaches to limit or
block the connection of misbehaving receivers without the change of low
level protocols.
Not only misbehaving receivers, but also some user-designed transport
protocols based on UDP can disobey the congestion control principle of
Internet. If the bottlenecks move from last mile and peering points to
the core Internet some day, the Internet may be ruined by misbehaving
receivers or increasing P2P traffic.
Received on Mon Oct 31 2005 - 02:46:03 EST
This archive was generated by hypermail 2.2.0 : Mon Oct 31 2005 - 09:38:51 EST