Network Working Group M. Allman Internet Draft V. Paxson Expiration Date: September 1998 March 1998 TCP Implementation Problems That Need To Be Documented 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 NASA Lewis Research Center/Sterling Software 21000 Brookpark Road MS 54-2 Cleveland, OH 44135 USA Phone: +1 216/433-6586 Vern Paxson Network Research Group Lawrence Berkeley National Laboratory Berkeley, CA 94720 USA Phone: +1 510/486-7504 Allman/Paxson [Page 5]