idnits 2.17.1 draft-ietf-tcpimpl-needdoc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'PADHV98' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Allman 3 Internet Draft V. Paxson 4 Expiration Date: September 1998 March 1998 6 TCP Implementation Problems That Need To Be Documented 7 9 1. Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet Drafts shadow 23 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 This memo provides information for the Internet community. This memo 28 does not specify an Internet standard of any kind. Distribution of 29 this memo is unlimited. 31 2. Introduction 33 The TCP-IMPL working group has documented a number of TCP 34 implementation problems [PADHV98]. However, a significant number 35 still have not been fully described and documented in the form used 36 in [PADHV98]. This memo briefly describes a number of these, 37 including commentary as to the authors' opinions regarding the 38 importance of documenting the problem. This memo is *not* intended 39 to ever see light as an RFC of some form; its sole function is to 40 facilitate working group discussion of which problems are more 41 pressing to document than others, and to aid in arriving at a 42 decision as to when [PADHV98] will be sufficiently complete to merit 43 its publication as an Informational RFC. 45 We divide the descriptions into "serious" problems, meaning those we 47 ID TCP Implementation Problems That Need To Be DocumentedMarch 1998 49 think should be included in [PADHV98] prior to its publication; 50 "security" problems, which might not be viewed as implementation 51 problems per se, but represent significant security problems of which 52 TCP implementors should be aware; and "less serious" problems, those 53 that, if the working group fails to find volunteers to document them, 54 should not hold up [PADHV98]. 56 It might be worthwhile to separate the security problems out into 57 their own document. We particularly solicit working group input on 58 this subject. 60 3. Serious Problems 62 Initial RTO too low 63 The retransmission timeout is supposed to be initialized to 3 64 seconds, per RFC 1122, 4.2.3.1. Some TCPs initialize it to a 65 much lower value, around 200 msec. For paths with RTTs greater 66 than this value, the initial data packets will always be 67 retransmitted, usually unnecessarily. Consequently, (1) the 68 connection immediately enters into congestion avoidance with the 69 smallest possible value for ssthresh, and (2) the RTT computed 70 for it will be discarded due to application of Karn's algorithm, 71 hence the RTO may fail to adapt to the long RTT, resulting in 72 further needless retransmissions. Both of these add up to 73 miserable performance. 75 We view this problem as quite serious from a performance per- 76 spective; not so serious from a network stability perspective. 78 CWND uninitialized 79 Some TCPs under some circumstances fail to properly initialize 80 cwnd, setting it instead to a very large value. This leads to 81 massive bursts upon startup. In particular, this has been 82 observed in some Reno-derived TCPs when, upon initiating a con- 83 nection, the remote peer does not include an MSS option in its 84 SYN ack. 86 This problem is fairly serious from a network stability perspec- 87 tive. It would be more serious if the circumstances leading to 88 it were more common. It will often have a deleterious effect on 89 performance, too, since large burst often leads to multiple 90 losses, and, consequently, retransmission timeouts and reduction 91 of ssthresh to a small value. 93 ID TCP Implementation Problems That Need To Be DocumentedMarch 1998 95 Failure of window deflation due to header prediction 96 As documented in Brakmo/Peterson's CCR paper, some TCPs will 97 fail to deflate cwnd after fast recovery because the incoming 98 acks match the header prediction test, which omits the window 99 deflation code. 101 This problem is fairly serious from a network stability perspec- 102 tive it means that during a time of congestion the TCP effec- 103 tively fails to back off its transmission rate as much as it 104 should. 106 Retransmission sends 2 packets 107 Some TCPs miscompute the amount of data in a segment when using 108 the per-segment timestamp option, and during retransmission con- 109 sequently send two packets, one nearly full-sized and one 110 tinygram. 112 This problem is somewhat serious because it injects twice the 113 number of packets into the network as necessary, during a time 114 when the network is under stress. 116 4. Security Problems 118 Predictable initial sequence number 119 TCPs that generate predictable initial sequence numbers are much 120 more vulnerable to "IP spoofing" attacks than those that generate 121 difficult-to-predict ISNs. 123 Ameliorating SYN flooding 124 A nasty denial-of-service attack sometimes observed in the Internet 125 concerns "SYN flooding", in which the attacker sends a high-volume 126 stream of initial SYN packets to the target machine, often using 127 bogus IP source addresses. These create large volumes of connec- 128 tion state on the target, and can completely fill "listen" queues, 129 depriving legitimate connection attempts from completing. There 130 are techniques, however, for hardening a TCP to resist this attack. 132 The Land attack 133 A "Land" attack consists of sending a bogus SYN packet to a host 134 that contains the same source and destination addresses and the 135 same source and destination ports. Some TCPs, upon receiving such 136 a packet, crash or enter into infinite loops. 138 ID TCP Implementation Problems That Need To Be DocumentedMarch 1998 140 5. Less Serious Problems 142 Failure to set PSH when send buffer drains 143 If a TCP does not set PSH when it has no more data to send, then 144 the data receiver may fail to deliver the data to the application 145 in a timely fashion, because it is waiting for the next PSH flag 146 before doing so. 148 Failure of window deflation due to fencepost error 149 As documented in Brakmo/Peterson's CCR paper, some TCPs fail to 150 deflate cwnd after fast recovery because the TCP's test for whether 151 it is in fast recovery contains a fencepost error. The test checks 152 for whether more than 3 dup acks have been received, rather than 153 whether 3 or more have been received. 155 Not so serious because relatively rare - only has any effect if the 156 fencepost is hit exactly. 158 Failure to ack above-sequence data 159 When above-sequence data arrives, the receiving TCP should generate 160 a duplicate ack. TCPs that fail to do so will often impair perfor- 161 mance because the connections they participate in will always 162 suffer timeout retransmissions upon loss, instead of taking advan- 163 tage of fast retransmit/fast recovery. 165 6. Security Considerations 167 Three of the problems discussed above relate directly to addressing 168 security concerns: "predictable initial sequence number", "ameliorat- 169 ing SYN flooding", and "the Land attack". All three are considered 170 to be in the "Serious" category, meriting inclusion in [PADHV98] 171 prior to its publication, or publication in a separate documented 172 devoted to security problems. 174 7. References 176 [PADHV98] 177 V. Paxson (editor), M. Allman, S. Dawson, I. Heavens and B. Volz, 178 "Known TCP Implementation Problems," Feb. 1998. 180 ID TCP Implementation Problems That Need To Be DocumentedMarch 1998 182 8. Authors' Addresses 184 Mark Allman 185 NASA Lewis Research Center/Sterling Software 186 21000 Brookpark Road 187 MS 54-2 188 Cleveland, OH 44135 189 USA 191 Phone: +1 216/433-6586 192 Vern Paxson 193 Network Research Group 194 Lawrence Berkeley National Laboratory 195 Berkeley, CA 94720 196 USA 197 Phone: +1 510/486-7504