Network Working Group M. Allman
Internet Draft V. Paxson
Expiration Date: September 1998 March 1998
TCP Implementation Problems That Need To Be Documented
<draft-ietf-tcpimpl-needdoc-00.txt>
1. Status of this Memo
This document is an Internet Draft. 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''.
To learn the current status of any Internet Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet Drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
2. Introduction
The TCP-IMPL working group has documented a number of TCP
implementation problems [PADHV98]. However, a significant number
still have not been fully described and documented in the form used
in [PADHV98]. This memo briefly describes a number of these,
including commentary as to the authors' opinions regarding the
importance of documenting the problem. This memo is *not* intended
to ever see light as an RFC of some form; its sole function is to
facilitate working group discussion of which problems are more
pressing to document than others, and to aid in arriving at a
decision as to when [PADHV98] will be sufficiently complete to merit
its publication as an Informational RFC.
We divide the descriptions into "serious" problems, meaning those we
Allman/Paxson [Page 1]
ID TCP Implementation Problems That Need To Be DocumentedMarch 1998
think should be included in [PADHV98] prior to its publication;
"security" problems, which might not be viewed as implementation
problems per se, but represent significant security problems of which
TCP implementors should be aware; and "less serious" problems, those
that, if the working group fails to find volunteers to document them,
should not hold up [PADHV98].
It might be worthwhile to separate the security problems out into
their own document. We particularly solicit working group input on
this subject.
3. Serious Problems
Initial RTO too low
The retransmission timeout is supposed to be initialized to 3
seconds, per RFC 1122, 4.2.3.1. Some TCPs initialize it to a
much lower value, around 200 msec. For paths with RTTs greater
than this value, the initial data packets will always be
retransmitted, usually unnecessarily. Consequently, (1) the
connection immediately enters into congestion avoidance with the
smallest possible value for ssthresh, and (2) the RTT computed
for it will be discarded due to application of Karn's algorithm,
hence the RTO may fail to adapt to the long RTT, resulting in
further needless retransmissions. Both of these add up to
miserable performance.
We view this problem as quite serious from a performance per-
spective; not so serious from a network stability perspective.
CWND uninitialized
Some TCPs under some circumstances fail to properly initialize
cwnd, setting it instead to a very large value. This leads to
massive bursts upon startup. In particular, this has been
observed in some Reno-derived TCPs when, upon initiating a con-
nection, the remote peer does not include an MSS option in its
SYN ack.
This problem is fairly serious from a network stability perspec-
tive. It would be more serious if the circumstances leading to
it were more common. It will often have a deleterious effect on
performance, too, since large burst often leads to multiple
losses, and, consequently, retransmission timeouts and reduction
of ssthresh to a small value.
Allman/Paxson [Page 2]
ID TCP Implementation Problems That Need To Be DocumentedMarch 1998
Failure of window deflation due to header prediction
As documented in Brakmo/Peterson's CCR paper, some TCPs will
fail to deflate cwnd after fast recovery because the incoming
acks match the header prediction test, which omits the window
deflation code.
This problem is fairly serious from a network stability perspec-
tive it means that during a time of congestion the TCP effec-
tively fails to back off its transmission rate as much as it
should.
Retransmission sends 2 packets
Some TCPs miscompute the amount of data in a segment when using
the per-segment timestamp option, and during retransmission con-
sequently send two packets, one nearly full-sized and one
tinygram.
This problem is somewhat serious because it injects twice the
number of packets into the network as necessary, during a time
when the network is under stress.
4. Security Problems
Predictable initial sequence number
TCPs that generate predictable initial sequence numbers are much
more vulnerable to "IP spoofing" attacks than those that generate
difficult-to-predict ISNs.
Ameliorating SYN flooding
A nasty denial-of-service attack sometimes observed in the Internet
concerns "SYN flooding", in which the attacker sends a high-volume
stream of initial SYN packets to the target machine, often using
bogus IP source addresses. These create large volumes of connec-
tion state on the target, and can completely fill "listen" queues,
depriving legitimate connection attempts from completing. There
are techniques, however, for hardening a TCP to resist this attack.
The Land attack
A "Land" attack consists of sending a bogus SYN packet to a host
that contains the same source and destination addresses and the
same source and destination ports. Some TCPs, upon receiving such
a packet, crash or enter into infinite loops.
Allman/Paxson [Page 3]
ID TCP Implementation Problems That Need To Be DocumentedMarch 1998
5. Less Serious Problems
Failure to set PSH when send buffer drains
If a TCP does not set PSH when it has no more data to send, then
the data receiver may fail to deliver the data to the application
in a timely fashion, because it is waiting for the next PSH flag
before doing so.
Failure of window deflation due to fencepost error
As documented in Brakmo/Peterson's CCR paper, some TCPs fail to
deflate cwnd after fast recovery because the TCP's test for whether
it is in fast recovery contains a fencepost error. The test checks
for whether more than 3 dup acks have been received, rather than
whether 3 or more have been received.
Not so serious because relatively rare - only has any effect if the
fencepost is hit exactly.
Failure to ack above-sequence data
When above-sequence data arrives, the receiving TCP should generate
a duplicate ack. TCPs that fail to do so will often impair perfor-
mance because the connections they participate in will always
suffer timeout retransmissions upon loss, instead of taking advan-
tage of fast retransmit/fast recovery.
6. Security Considerations
Three of the problems discussed above relate directly to addressing
security concerns: "predictable initial sequence number", "ameliorat-
ing SYN flooding", and "the Land attack". All three are considered
to be in the "Serious" category, meriting inclusion in [PADHV98]
prior to its publication, or publication in a separate documented
devoted to security problems.
7. References
[PADHV98]
V. Paxson (editor), M. Allman, S. Dawson, I. Heavens and B. Volz,
"Known TCP Implementation Problems," Feb. 1998.
Allman/Paxson [Page 4]
ID TCP Implementation Problems That Need To Be DocumentedMarch 1998
8. Authors' Addresses
Mark Allman <mallman@lerc.nasa.gov>
NASA Lewis Research Center/Sterling Software
21000 Brookpark Road
MS 54-2
Cleveland, OH 44135
USA
Phone: +1 216/433-6586
Vern Paxson <vern@ee.lbl.gov>
Network Research Group
Lawrence Berkeley National Laboratory
Berkeley, CA 94720
USA
Phone: +1 510/486-7504
Allman/Paxson [Page 5]
