[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/