idnits 2.17.1 draft-ietf-tcpm-tcp-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 19, 2009) is 5364 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Clark' on line 201 looks like a reference -- Missing reference section? '1988' on line 201 looks like a reference -- Missing reference section? 'Bellovin' on line 213 looks like a reference -- Missing reference section? '1989' on line 364 looks like a reference -- Missing reference section? 'NISCC' on line 215 looks like a reference -- Missing reference section? '2005' on line 529 looks like a reference -- Missing reference section? 'Silbersack' on line 529 looks like a reference -- Missing reference section? 'Postel' on line 507 looks like a reference -- Missing reference section? '1981c' on line 507 looks like a reference -- Missing reference section? 'Braden' on line 364 looks like a reference -- Missing reference section? 'IANA' on line 436 looks like a reference -- Missing reference section? '2008' on line 436 looks like a reference -- Missing reference section? 'Jones' on line 473 looks like a reference -- Missing reference section? '2003' on line 473 looks like a reference -- Missing reference section? 'CPNI' on line 789 looks like a reference -- Missing reference section? '2009' on line 789 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor F. Gont 3 Extensions (tcpm) UK CPNI 4 Internet-Draft August 19, 2009 5 Intended status: BCP 6 Expires: February 20, 2010 8 Security Assessment of the Transmission Control Protocol (TCP) 9 draft-ietf-tcpm-tcp-security-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 20, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document contains a security assessment of the specifications of 48 the Transmission Control Protocol (TCP), and of a number of 49 mechanisms and policies in use by popular TCP implementations. 50 Additionally, it contains best current practices for hardening a TCP 51 implementation. 53 Table of Contents 55 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6 58 1.3. Organization of this document . . . . . . . . . . . . . . 7 59 2. The Transmission Control Protocol . . . . . . . . . . . . . . 7 60 3. TCP header fields . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1. Source Port . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1.1. Problems that may arise as a result of collisions 63 of connection-id's . . . . . . . . . . . . . . . . . . 11 64 3.1.2. Port randomization algorithms . . . . . . . . . . . . 12 65 3.1.3. TCP ephemeral port range . . . . . . . . . . . . . . . 12 66 3.2. Destination port . . . . . . . . . . . . . . . . . . . . . 12 67 3.3. Sequence number . . . . . . . . . . . . . . . . . . . . . 13 68 3.3.1. Generation of Initial Sequence Numbers . . . . . . . . 13 69 3.4. Acknowledgement Number . . . . . . . . . . . . . . . . . . 13 70 3.5. Data Offset . . . . . . . . . . . . . . . . . . . . . . . 13 71 3.6. Control bits . . . . . . . . . . . . . . . . . . . . . . . 13 72 3.6.1. Reserved (four bits) . . . . . . . . . . . . . . . . . 13 73 3.6.2. CWR (Congestion Window Reduced) . . . . . . . . . . . 13 74 3.6.3. ECE (ECN-Echo) . . . . . . . . . . . . . . . . . . . . 13 75 3.6.4. URG . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.6.5. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 3.6.6. PSH . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 3.6.7. RST . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.6.8. SYN . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 3.6.9. FIN . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 3.7. Window . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 3.7.1. Security implications of the maximum TCP window 83 size . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 3.7.2. Security implications arising from closed windows . . 13 85 3.8. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 3.9. Urgent pointer . . . . . . . . . . . . . . . . . . . . . . 13 87 3.9.1. Security implications arising from ambiguities in 88 the processing of urgent indications . . . . . . . . . 14 89 3.9.2. Security implications arising from the 90 implementation of the urgent mechanism as "out of 91 band" data . . . . . . . . . . . . . . . . . . . . . . 14 92 3.10. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 3.11. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 3.12. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 4. Common TCP Options . . . . . . . . . . . . . . . . . . . . . . 14 96 4.1. End of Option List (Kind = 0) . . . . . . . . . . . . . . 14 97 4.2. No Operation (Kind = 1) . . . . . . . . . . . . . . . . . 14 98 4.3. Maximum Segment Size (Kind = 2) . . . . . . . . . . . . . 14 99 4.4. Selective Acknowledgement Option . . . . . . . . . . . . . 14 100 4.4.1. SACK-permitted Option (Kind = 4) . . . . . . . . . . . 14 101 4.4.2. SACK Option (Kind = 5) . . . . . . . . . . . . . . . . 14 102 4.5. MD5 Option (Kind=19) . . . . . . . . . . . . . . . . . . . 14 103 4.6. Window scale option (Kind = 3) . . . . . . . . . . . . . . 14 104 4.7. Timestamps option (Kind = 8) . . . . . . . . . . . . . . . 14 105 4.7.1. Generation of timestamps . . . . . . . . . . . . . . . 14 106 4.7.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . 14 107 5. Connection-establishment mechanism . . . . . . . . . . . . . . 14 108 5.1. SYN flood . . . . . . . . . . . . . . . . . . . . . . . . 14 109 5.2. Connection forgery . . . . . . . . . . . . . . . . . . . . 14 110 5.3. Connection-flooding attack . . . . . . . . . . . . . . . . 14 111 5.3.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 14 112 5.3.2. Countermeasures . . . . . . . . . . . . . . . . . . . 14 113 5.4. Firewall-bypassing techniques . . . . . . . . . . . . . . 15 114 6. Connection-termination mechanism . . . . . . . . . . . . . . . 15 115 6.1. FIN-WAIT-2 flooding attack . . . . . . . . . . . . . . . . 15 116 6.1.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15 117 6.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 118 7. Buffer management . . . . . . . . . . . . . . . . . . . . . . 15 119 7.1. TCP retransmission buffer . . . . . . . . . . . . . . . . 15 120 7.1.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15 121 7.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 122 7.2. TCP segment reassembly buffer . . . . . . . . . . . . . . 15 123 7.3. Automatic buffer tuning mechanisms . . . . . . . . . . . . 15 124 7.3.1. Automatic send-buffer tuning mechanisms . . . . . . . 15 125 7.3.2. Automatic receive-buffer tuning mechanism . . . . . . 15 126 8. TCP segment reassembly algorithm . . . . . . . . . . . . . . . 15 127 8.1. Problems that arise from ambiguity in the reassembly 128 process . . . . . . . . . . . . . . . . . . . . . . . . . 15 129 9. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 15 130 9.1. Congestion control with misbehaving receivers . . . . . . 15 131 9.1.1. ACK division . . . . . . . . . . . . . . . . . . . . . 15 132 9.1.2. DupACK forgery . . . . . . . . . . . . . . . . . . . . 15 133 9.1.3. Optimistic ACKing . . . . . . . . . . . . . . . . . . 15 134 9.2. Blind DupACK triggering attacks against TCP . . . . . . . 15 135 9.2.1. Blind throughput-reduction attack . . . . . . . . . . 15 136 9.2.2. Blind flooding attack . . . . . . . . . . . . . . . . 16 137 9.2.3. Difficulty in performing the attacks . . . . . . . . . 16 138 9.2.4. Modifications to TCP's loss recovery algorithms . . . 16 139 9.2.5. Countermeasures . . . . . . . . . . . . . . . . . . . 16 140 9.3. TCP Explicit Congestion Notification (ECN) . . . . . . . . 16 141 9.3.1. Possible attacks by a compromised router . . . . . . . 16 142 9.3.2. Possible attacks by a malicious TCP endpoint . . . . . 16 143 10. TCP API . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 144 10.1. Passive opens and binding sockets . . . . . . . . . . . . 16 145 10.2. Active opens and binding sockets . . . . . . . . . . . . . 16 146 11. Blind in-window attacks . . . . . . . . . . . . . . . . . . . 16 147 11.1. Blind TCP-based connection-reset attacks . . . . . . . . . 16 148 11.1.1. RST flag . . . . . . . . . . . . . . . . . . . . . . . 16 149 11.1.2. SYN flag . . . . . . . . . . . . . . . . . . . . . . . 16 150 11.1.3. Security/Compartment . . . . . . . . . . . . . . . . . 16 151 11.1.4. Precedence . . . . . . . . . . . . . . . . . . . . . . 16 152 11.1.5. Illegal options . . . . . . . . . . . . . . . . . . . 16 153 11.2. Blind data-injection attacks . . . . . . . . . . . . . . . 16 154 12. Information leaking . . . . . . . . . . . . . . . . . . . . . 16 155 12.1. Remote Operating System detection via TCP/IP stack 156 fingerprinting . . . . . . . . . . . . . . . . . . . . . . 16 157 12.1.1. FIN probe . . . . . . . . . . . . . . . . . . . . . . 16 158 12.1.2. Bogus flag test . . . . . . . . . . . . . . . . . . . 16 159 12.1.3. TCP ISN sampling . . . . . . . . . . . . . . . . . . . 17 160 12.1.4. TCP initial window . . . . . . . . . . . . . . . . . . 17 161 12.1.5. RST sampling . . . . . . . . . . . . . . . . . . . . . 17 162 12.1.6. TCP options . . . . . . . . . . . . . . . . . . . . . 17 163 12.1.7. Retransmission Timeout (RTO) sampling . . . . . . . . 17 164 12.2. System uptime detection . . . . . . . . . . . . . . . . . 17 165 13. Covert channels . . . . . . . . . . . . . . . . . . . . . . . 17 166 14. TCP Port scanning . . . . . . . . . . . . . . . . . . . . . . 17 167 14.1. Traditional connect() scan . . . . . . . . . . . . . . . . 17 168 14.2. SYN scan . . . . . . . . . . . . . . . . . . . . . . . . . 17 169 14.3. FIN, NULL, and XMAS scans . . . . . . . . . . . . . . . . 17 170 14.4. Maimon scan . . . . . . . . . . . . . . . . . . . . . . . 17 171 14.5. Window scan . . . . . . . . . . . . . . . . . . . . . . . 17 172 14.6. ACK scan . . . . . . . . . . . . . . . . . . . . . . . . . 17 173 15. Processing of ICMP error messages by TCP . . . . . . . . . . . 17 174 16. TCP interaction with the Internet Protocol (IP) . . . . . . . 17 175 16.1. TCP-based traceroute . . . . . . . . . . . . . . . . . . . 17 176 16.2. Blind TCP data injection through fragmented IP traffic . . 17 177 16.3. Broadcast and multicast IP addresses . . . . . . . . . . . 17 178 17. Security Considerations . . . . . . . . . . . . . . . . . . . 17 179 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 180 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 181 Appendix A. Changes from previous versions of the draft (to 182 be removed by the RFC Editor before publishing 183 this document as an RFC) . . . . . . . . . . . . . . 28 184 A.1. Changes from draft-gont-tcp-security-00 . . . . . . . . . 28 185 Appendix B. Advice and guidance to vendors . . . . . . . . . . . 28 186 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 188 1. Preface 190 1.1. Introduction 192 The TCP/IP protocol suite was conceived in an environment that was 193 quite different from the hostile environment they currently operate 194 in. However, the effectiveness of the protocols led to their early 195 adoption in production environments, to the point that, to some 196 extent, the current world's economy depends on them. 198 While many textbooks and articles have created the myth that the 199 Internet protocols were designed for warfare environments, the top 200 level goal for the DARPA Internet Program was the sharing of large 201 service machines on the ARPANET [Clark, 1988]. As a result, many 202 protocol specifications focus only on the operational aspects of the 203 protocols they specify, and overlook their security implications. 205 While the Internet technology evolved since it early inception, the 206 Internet's building blocks are basically the same core protocols 207 adopted by the ARPANET more than two decades ago. During the last 208 twenty years, many vulnerabilities have been identified in the TCP/IP 209 stacks of a number of systems. Some of them were based on flaws in 210 some protocol implementations, affecting only a reduced number of 211 systems, while others were based in flaws in the protocols 212 themselves, affecting virtually every existing implementation 213 [Bellovin, 1989]. Even in the last couple of years, researchers were 214 still working on security problems in the core protocols [NISCC, 215 2004] [NISCC, 2005]. 217 The discovery of vulnerabilities in the TCP/IP protocol suite usually 218 led to reports being published by a number of CSIRTs (Computer 219 Security Incident Response Teams) and vendors, which helped to raise 220 awareness about the threats and the best mitigations known at the 221 time the reports were published. Unfortunately, this also led to the 222 documentation of the discovered protocol vulnerabilities being spread 223 among a large number of documents, which are sometimes difficult to 224 identify. 226 For some reason, much of the effort of the security community on the 227 Internet protocols did not result in official documents (RFCs) being 228 issued by the IETF (Internet Engineering Task Force). This basically 229 led to a situation in which "known" security problems have not always 230 been addressed by all vendors. In addition, in many cases vendors 231 have implemented quick "fixes" to the identified vulnerabilities 232 without a careful analysis of their effectiveness and their impact on 233 interoperability [Silbersack, 2005]. 235 Producing a secure TCP/IP implementation nowadays is a very difficult 236 task, in part because of the lack of a single document that serves as 237 a security roadmap for the protocols. Implementers are faced with 238 the hard task of identifying relevant documentation and 239 differentiating between that which provides correct advice, and that 240 which provides misleading advice based on inaccurate or wrong 241 assumptions. 243 This document is the result of a security assessment of the IETF 244 specifications of the Transmission Control Protocol (TCP), from a 245 security point of view. Possible threats are identified and, where 246 possible, countermeasures are proposed. Additionally, many 247 implementation flaws that have led to security vulnerabilities have 248 been referenced in the hope that future implementations will not 249 incur the same problems. 251 This document is heavily based on the "Security Assessment of the 252 Transmission Control Protocol (TCP)" released by the UK Centre for 253 the Protection of National Infrastructure (CPNI), available at: http: 254 //www.cpni.gov.uk/Products/technicalnotes/ 255 Feb-09-security-assessment-TCP.aspx . 257 1.2. Scope of this document 259 While there are a number of protocols that may affect the way TCP 260 operates, this document focuses only on the specifications of the 261 Transmission Control Protocol (TCP) itself. 263 The following IETF RFCs were selected for assessment as part of this 264 work: 266 o RFC 793, "Transmission Control Protocol. DARPA Internet Program. 267 Protocol Specification" (91 pages) 269 o RFC 1122, "Requirements for Internet Hosts -- Communication 270 Layers" (116 pages) 272 o RFC 1191, "Path MTU Discovery" (19 pages) 274 o RFC 1323, "TCP Extensions for High Performance" (37 pages) 276 o RFC 1948, "Defending Against Sequence Number Attacks" (6 pages) 278 o RFC 1981, "Path MTU Discovery for IP version 6" (15 pages) 280 o RFC 2018, "TCP Selective Acknowledgment Options" (12 pages) 282 o RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature 283 Option" (6 pages) 285 o RFC 2581, "TCP Congestion Control" (14 pages) 287 o RFC 2675, "IPv6 Jumbograms" (9 pages) 289 o RFC 2883, "An Extension to the Selective Acknowledgement (SACK) 290 Option for TCP" (17 pages) 292 o RFC 2884, "Performance Evaluation of Explicit Congestion 293 Notification (ECN) in IP Networks" (18 pages) 295 o RFC 2988, "Computing TCP's Retransmission Timer" (8 pages) 297 o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) 298 to IP" (63 pages) 300 o RFC 3465, "TCP Congestion Control with Appropriate Byte Counting 301 (ABC)" (10 pages) 303 o RFC 3517, "A Conservative Selective Acknowledgment (SACK)-based 304 Loss Recovery Algorithm for TCP" (13 pages) 306 o RFC 3540, "Robust Explicit Congestion Notification (ECN) Signaling 307 with Nonces" (13 pages) 309 o RFC 3782, "The NewReno Modification to TCP's Fast Recovery 310 Algorithm" (19 pages) 312 1.3. Organization of this document 314 This document is basically organized in two parts. The first part 315 contains a discussion of each of the TCP header fields, identifies 316 their security implications, and discusses the possible 317 countermeasures. The second part contains an analysis of the 318 security implications of the mechanisms and policies implemented by 319 TCP, and of a number of implementation strategies in use by a number 320 of popular TCP implementations. 322 2. The Transmission Control Protocol 324 The Transmission Control Protocol (TCP) is a connection-oriented 325 transport protocol that provides a reliable byte-stream data transfer 326 service. 328 Very few assumptions are made about the reliability of underlying 329 data transfer services below the TCP layer. Basically, TCP assumes 330 it can obtain a simple, potentially unreliable datagram service from 331 the lower level protocols. Figure 1 illustrates where TCP fits in 332 the DARPA reference model. 334 +---------------+ 335 | Application | 336 +---------------+ 337 | TCP | 338 +---------------+ 339 | IP | 340 +---------------+ 341 | Network | 342 +---------------+ 344 Figure 1: TCP in the DARPA reference model 346 TCP provides facilities in the following areas: 348 o Basic Data Transfer 350 o Reliability 352 o Flow Control 354 o Multiplexing 356 o Connections 358 o Precedence and Security 360 o Congestion Control 362 The core TCP specification, RFC 793 [Postel, 1981c], dates back to 363 1981 and standardizes the basic mechanisms and policies of TCP. RFC 364 1122 [Braden, 1989] provides clarifications and errata for the 365 original specification. RFC 2581 [Allman et al, 1999] specifies TCP 366 congestion control and avoidance mechanisms, not present in the 367 original specification. Other documents specify extensions and 368 improvements for TCP. 370 The large amount of documents that specify extensions, improvements, 371 or modifications to existing TCP mechanisms has led the IETF to 372 publish a roadmap for TCP, RFC 4614 [Duke et al, 2006], that 373 clarifies the relevance of each of those documents. 375 3. TCP header fields 377 RFC 793 [Postel, 1981c] defines the syntax of a TCP segment, along 378 with the semantics of each of the header fields. Figure 2 379 illustrates the syntax of a TCP segment. 381 0 1 2 3 382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Source Port | Destination Port | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Sequence Number | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Acknowledgment Number | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Data | |C|E|U|A|P|R|S|F| | 391 | Offset|Resrved|W|C|R|C|S|S|Y|I| Window | 392 | | |R|E|G|K|H|T|N|N| | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Checksum | Urgent Pointer | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Options | Padding | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | data | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Note that one tick mark represents one bit position 403 Figure 2: Transmission Control Protocol header format 405 The minimum TCP header size is 20 bytes, and corresponds to a TCP 406 segment with no options and no data. However, a TCP module might be 407 handed an (illegitimate) "TCP segment" of less than 20 bytes. 408 Therefore, before doing any processing of the TCP header fields, the 409 following check should be performed by TCP on the segments handed by 410 the internet layer: 412 Segment.Size >= 20 414 If a segment does not pass this check, it should be dropped. 416 The following subsections contain further sanity checks that should 417 be performed on TCP segments. 419 3.1. Source Port 421 This field contains a 16-bit number that identifies the TCP end-point 422 that originated this TCP segment. Being a 16-bit field, it can 423 contain any value in the range 0-65535. 425 The Internet Assigned Numbers Authority (IANA) has traditionally 426 reserved the following use of the 16-bit port range of TCP [IANA, 427 2008]: 429 o The Well Known Ports, 0 through 1023 431 o The Registered Ports, 1024 through 49151 433 o The Dynamic and/or Private Ports, 49152 through 65535 435 The range of assigned ports managed by the IANA is 0-1023, with the 436 remainder being registered by IANA but not assigned [IANA, 2008]. It 437 is also worth noting that, while some systems restrict use of the 438 port numbers in the range 0-1024 to privileged users, no trust should 439 be granted based on the port numbers used for a TCP connection. 441 Servers usually bind specific ports on which specific services are 442 usually provided, while clients usually make use of the so-called 443 "ephemeral ports" for the source port of their outgoing connections 444 with the only requirement that the resulting four-tuple must be 445 unique (not currently in use by any other transport protocol 446 instance). 448 While the only requirement for a selected ephemeral port is that the 449 resulting four-tuple (connection-id) is unique, in practice it may be 450 necessary to not allow the allocation of port numbers that are in use 451 by a TCP that is in the LISTEN or CLOSED states for use as ephemeral 452 ports, as this might allow an attacker to "steal" incoming 453 connections from a local server application. Section 10.2 of this 454 document provides a detailed discussion of this issue. 456 It should also be noted that some clients, such as DNS resolvers, are 457 known to use port numbers from the "Well Known Ports" range. 458 Therefore, middle-boxes such as packet filters should not assume that 459 clients use port number from only the Dynamic or Registered port 460 ranges. 462 While port 0 is a legitimate port number, it has a special meaning in 463 the UNIX Sockets API. For example, when a TCP port number of 0 is 464 passed as an argument to the bind() function, rather than binding 465 port 0, an ephemeral port is selected for the corresponding TCP end- 466 point. As a result, the TCP port number 0 is never actually used in 467 TCP segments. 469 Different implementations have been found to respond differently to 470 TCP segments that have a port number of 0 as the Source Port and/or 471 the Destination Port. As a result, TCP segments with a port number 472 of 0 are usually employed for remote OS detection via TCP/IP stack 473 fingerprinting [Jones, 2003]. 475 Since in practice TCP port 0 is not used by any legitimate 476 application and is only used for fingerprinting purposes, a number of 477 host implementations already reject TCP segments that use 0 as the 478 Source Port and/or the Destination Port. Also, a number firewalls 479 filter (by default) any TCP segments that contain a port number of 480 zero for the Source Port and/or the Destination Port. 482 We therefore recommend that TCP implementations respond to incoming 483 TCP segments that have a Source Port of 0 with an RST (provided these 484 incoming segments do not have the RST bit set). 486 Responding with an RST segment to incoming segments that have the RST 487 bit would open the door to RST-war attacks. 489 As discussed in Section 3.2, we also recommend TCP implementations to 490 respond with an RST to incoming packets that have a Destination Port 491 of 0 (provided these incoming segments do not have the RST bit set). 493 3.1.1. Problems that may arise as a result of collisions of connection- 494 id's 496 A number of implementations will not allow the creation of a new 497 connection if there exists a previous incarnation of the same 498 connection in any state other than the fictional state CLOSED. This 499 can be problematic in scenarios in which a client establishes 500 connections with a specific service at a particular server at a high 501 rate: even if the connections are also closed at a high rate, one of 502 the systems (the one performing the active close) will keep each of 503 the closed connections in the TIME-WAIT state for 2*MSL. 505 MSL (Maximum Segment Lifetime) is the maximum amount of time that a 506 TCP segment can exist in an internet. It is defined to be 2 minutes 507 by RFC 793 [Postel, 1981c]. 509 If the connection rate is high enough, at some point all the 510 ephemeral ports at the client will be in use by some connection in 511 the TIME-WAIT state, thus preventing the establishment of new 512 connections. In order to overcome this problem, a number of TCP 513 implementations include some heuristics to allow the creation of a 514 new incarnation of a connection that is in the TIME-WAIT state. In 515 such implementations a new incarnation of a previous connection is 516 allowed if: 518 o The incoming SYN segment contains a timestamp option, and the 519 timestamp is greater than the last timestamp seen in the previous 520 incarnation of the connection (for that direction of the data 521 transfer), or, 523 o The incoming SYN segment does not contain a timestamp option, but 524 its Initial Sequence Number (ISN) is greater than the last 525 sequence number seen in the previous incarnation of the connection 526 (for that direction of the data transfer) 528 Unfortunately, these heuristics are optional, and thus cannot be 529 relied upon. Additionally, as indicated by [Silbersack, 2005], if 530 the Timestamp or the ISN are trivially randomized, these heuristics 531 might fail. 533 Section 3.3.1 and Section 4.7.1 of this document recommend algorithms 534 for the generation of TCP Initial Sequence Numbers and TCP 535 timestamps, respectively, that provide randomization, while still 536 allowing the aforementioned heuristics to work. 538 Therefore, the only strategy that can be relied upon to avoid this 539 interoperability problem is to minimize the rate of collisions of 540 connection-id's. A good algorithm to minimize rate of collisions of 541 connection-id's would consider the time a given four-tuple {Source 542 Address, Source Port, Destination Address, Destination Port} was last 543 used, and would try avoid reusing it for 2*MSL. However, an 544 efficient implementation approach for this algorithm has not yet been 545 devised. A simple approach to minimize the rate collisions of 546 connection-id's in most scenarios is to maximize the port reuse 547 cycle, such that a port number is not reused before all the other 548 port numbers in the ephemeral port range have been used for outgoing 549 connections. This is the traditional ephemeral port selection 550 algorithm in 4.4BSD implementations. 552 However, if a single global variable is used to keep track of the 553 last ephemeral port selected, ephemeral port numbers become trivially 554 predictable. 556 Section 3.1.2 of this document analyzes a number of approaches for 557 obfuscating the TCP ephemeral ports, such that the chances of an 558 attacker of guessing the ephemeral ports used for future connections 559 are reduced, while still reducing the probability of collisions of 560 connection-id's. Finally, Section 3.1.3 makes recommendations about 561 the port range that should be used for the ephemeral ports. 563 3.1.2. Port randomization algorithms 565 3.1.3. TCP ephemeral port range 567 3.2. Destination port 568 3.3. Sequence number 570 3.3.1. Generation of Initial Sequence Numbers 572 3.4. Acknowledgement Number 574 3.5. Data Offset 576 3.6. Control bits 578 3.6.1. Reserved (four bits) 580 3.6.2. CWR (Congestion Window Reduced) 582 3.6.3. ECE (ECN-Echo) 584 3.6.4. URG 586 3.6.5. ACK 588 3.6.6. PSH 590 3.6.7. RST 592 [Ramaiah et al, 2008] suggests that implementations should rate-limit 593 the challenge ACK segments sent as a result of implementation of this 594 mechanism. 596 Section 11.1 of this document describes TCP-based connection-reset 597 attacks, along with a number of countermeasures to mitigate their 598 impact. 600 3.6.8. SYN 602 3.6.9. FIN 604 3.7. Window 606 3.7.1. Security implications of the maximum TCP window size 608 3.7.2. Security implications arising from closed windows 610 3.8. Checksum 612 3.9. Urgent pointer 614 3.9.1. Security implications arising from ambiguities in the processing 615 of urgent indications 617 3.9.2. Security implications arising from the implementation of the 618 urgent mechanism as "out of band" data 620 3.10. Options 622 3.11. Padding 624 3.12. Data 626 4. Common TCP Options 628 4.1. End of Option List (Kind = 0) 630 4.2. No Operation (Kind = 1) 632 4.3. Maximum Segment Size (Kind = 2) 634 4.4. Selective Acknowledgement Option 636 4.4.1. SACK-permitted Option (Kind = 4) 638 4.4.2. SACK Option (Kind = 5) 640 4.5. MD5 Option (Kind=19) 642 4.6. Window scale option (Kind = 3) 644 4.7. Timestamps option (Kind = 8) 646 4.7.1. Generation of timestamps 648 4.7.2. Vulnerabilities 650 5. Connection-establishment mechanism 652 5.1. SYN flood 654 5.2. Connection forgery 656 5.3. Connection-flooding attack 658 5.3.1. Vulnerability 660 5.3.2. Countermeasures 661 5.4. Firewall-bypassing techniques 663 6. Connection-termination mechanism 665 6.1. FIN-WAIT-2 flooding attack 667 6.1.1. Vulnerability 669 6.1.2. Countermeasures 671 7. Buffer management 673 7.1. TCP retransmission buffer 675 7.1.1. Vulnerability 677 7.1.2. Countermeasures 679 7.2. TCP segment reassembly buffer 681 7.3. Automatic buffer tuning mechanisms 683 7.3.1. Automatic send-buffer tuning mechanisms 685 7.3.2. Automatic receive-buffer tuning mechanism 687 8. TCP segment reassembly algorithm 689 8.1. Problems that arise from ambiguity in the reassembly process 691 9. TCP Congestion Control 693 9.1. Congestion control with misbehaving receivers 695 9.1.1. ACK division 697 9.1.2. DupACK forgery 699 9.1.3. Optimistic ACKing 701 9.2. Blind DupACK triggering attacks against TCP 703 9.2.1. Blind throughput-reduction attack 704 9.2.2. Blind flooding attack 706 9.2.3. Difficulty in performing the attacks 708 9.2.4. Modifications to TCP's loss recovery algorithms 710 9.2.5. Countermeasures 712 9.3. TCP Explicit Congestion Notification (ECN) 714 9.3.1. Possible attacks by a compromised router 716 9.3.2. Possible attacks by a malicious TCP endpoint 718 10. TCP API 720 10.1. Passive opens and binding sockets 722 10.2. Active opens and binding sockets 724 11. Blind in-window attacks 726 11.1. Blind TCP-based connection-reset attacks 728 11.1.1. RST flag 730 11.1.2. SYN flag 732 11.1.3. Security/Compartment 734 11.1.4. Precedence 736 11.1.5. Illegal options 738 11.2. Blind data-injection attacks 740 12. Information leaking 742 12.1. Remote Operating System detection via TCP/IP stack fingerprinting 744 12.1.1. FIN probe 746 12.1.2. Bogus flag test 747 12.1.3. TCP ISN sampling 749 12.1.4. TCP initial window 751 12.1.5. RST sampling 753 12.1.6. TCP options 755 12.1.7. Retransmission Timeout (RTO) sampling 757 12.2. System uptime detection 759 13. Covert channels 761 14. TCP Port scanning 763 14.1. Traditional connect() scan 765 14.2. SYN scan 767 14.3. FIN, NULL, and XMAS scans 769 14.4. Maimon scan 771 14.5. Window scan 773 14.6. ACK scan 775 15. Processing of ICMP error messages by TCP 777 16. TCP interaction with the Internet Protocol (IP) 779 16.1. TCP-based traceroute 781 16.2. Blind TCP data injection through fragmented IP traffic 783 16.3. Broadcast and multicast IP addresses 785 17. Security Considerations 786 18. Acknowledgements 788 This document is based on the document "Security Assessment of the 789 Transmission Control Protocol (TCP)" [CPNI, 2009] written by Fernando 790 Gont on behalf of CPNI (Centre for the Protection of National 791 Infrastructure). 793 The author would like to thank (in alphabetical order) Randall 794 Atkinson, Guillermo Gont, Alfred Hoenes, Jamshid Mahdavi, Stanislav 795 Shalunov, Michael Welzl, Dan Wing, Andrew Yourtchenko, Michael 796 Zalewski, and Christos Zoulas, for providing valuable feedback on 797 earlier versions of the UK CPNI document. 799 Additionally, the author would like to thank (in alphabetical order) 800 Mark Allman, David Black, Ethan Blanton, David Borman, James Chacon, 801 John Heffner, Jerrold Leichter, Jamshid Mahdavi, Keith Scott, Bill 802 Squier, and David White, who generously answered a number of 803 questions that araised while the aforementioned document was being 804 written. 806 Finally, the author would like to thank CPNI (formely NISCC) for 807 their continued support. 809 19. References 811 Abley, J., Savola, P., Neville-Neil, G. 2007. Deprecation of Type 0 812 Routing Headers in IPv6. RFC 5095. 814 Allman, M. 2003. TCP Congestion Control with Appropriate Byte 815 Counting (ABC). RFC 3465. 817 Allman, M. 2008. Comments On Selecting Ephemeral Ports. Available 818 at: http://www.icir.org/mallman/share/ports-dec08.pdf 820 Allman, M., Paxson, V., Stevens, W. 1999. TCP Congestion Control. 821 RFC 2581. 823 Allman, M., Balakrishnan, H., Floyd, S. 2001. Enhancing TCP's Loss 824 Recovery Using Limited Transmit. RFC 3042. 826 Allman, M., Floyd, S., and C. Partridge. 2002. Increasing TCP's 827 Initial Window. RFC 3390. 829 Baker, F. 1995. Requirements for IP Version 4 Routers. RFC 1812. 831 Baker, F., Savola, P. 2004. Ingress Filtering for Multihomed 832 Networks. RFC 3704. 834 Barisani, A. 2006. FTester - Firewall and IDS testing tool. 835 Available at: http://dev.inversepath.com/trac/ftester 837 Beck, R. 2001. Passive-Aggressive Resistance: OS Fingerprint 838 Evasion. Linux Journal. 840 Bellovin, S. M. 1989. Security Problems in the TCP/IP Protocol 841 Suite. Computer Communication Review, Vol. 19, No. 2, pp. 32-48. 843 Bellovin, S. M. 1996. Defending Against Sequence Number Attacks. 844 RFC 1948. 846 Bellovin, S. M. 2006. Towards a TCP Security Option. IETF Internet- 847 Draft (draft-bellovin-tcpsec-00.txt), work in progress. 849 Bernstein, D. J. 1996. SYN cookies. Available at: 850 http://cr.yp.to/syncookies.html 852 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and Weiss, 853 W., 1998. An Architecture for Differentiated Services. RFC 2475. 855 Blanton, E., Allman, M., Fall, K., Wang, L. 2003. A Conservative 856 Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for 857 TCP. RFC 3517. 859 Borman, D. 1997. Post to the tcp-impl mailing-list. Message-Id: 860 <199706061526.KAA01535@frantic.BSDI.COM>. Available at: 861 http://www.kohala.com/start/borman.97jun06.txt 863 Borman, D., Deering, S., Hinden, R. 1999. IPv6 Jumbograms. RFC 864 2675. 866 Braden, R. 1989. Requirements for Internet Hosts -- Communication 867 Layers. RFC 1122. 869 Braden, R. 1992. Extending TCP for Transactions -- Concepts. RFC 870 1379. 872 Braden, R. 1994. T/TCP -- TCP Extensions for Transactions Functional 873 Specification. RFC 1644. 875 CCSDS. 2006. Consultative Committee for Space Data Systems (CCSDS) 876 Recommendation Communications Protocol Specification (SCPS) -- 877 Transport Protocol (SCPS-TP). Blue Book. Issue 2. Available at: 878 http://public.ccsds.org/publications/archive/714x0b2.pdf 880 CERT. 1996. CERT Advisory CA-1996-21: TCP SYN Flooding and IP 881 Spoofing Attacks. Available at: 883 http://www.cert.org/advisories/CA-1996-21.html 885 CERT. 1997. CERT Advisory CA-1997-28 IP Denial-of-Service Attacks. 886 Available at: http://www.cert.org/advisories/CA-1997-28.html 888 CERT. 2000. CERT Advisory CA-2000-21: Denial-of-Service 889 Vulnerabilities in TCP/IP Stacks. Available at: 890 http://www.cert.org/advisories/CA-2000-21.html 892 CERT. 2001. CERT Advisory CA-2001-09: Statistical Weaknesses in 893 TCP/IP Initial Sequence Numbers. Available at: 894 http://www.cert.org/advisories/CA-2001-09.html 896 CERT. 2003. CERT Advisory CA-2003-13 Multiple Vulnerabilities in 897 Snort Preprocessors. Available at: 898 http://www.cert.org/advisories/CA-2003-13.html 900 Cisco. 2008a. Cisco Security Appliance Command Reference, Version 901 7.0. Available at: http://www.cisco.com/en/US/docs/security/asa/ 902 asa70/command/reference/tz.html#wp1288756 904 Cisco. 2008b. Cisco Security Appliance System Log Messages, Version 905 8.0. Available at: http://www.cisco.com/en/US/docs/security/asa/ 906 asa80/system/message/logmsgs.html#wp4773952 908 Clark, D.D. 1982. Fault isolation and recovery. RFC 816. 910 Clark, D.D. 1988. The Design Philosophy of the DARPA Internet 911 Protocols, Computer Communication Review, Vol. 18, No.4, pp. 106-114. 913 Connolly, T., Amer, P., Conrad, P. 1994. An Extension to TCP : 914 Partial Order Service. RFC 1693. 916 Conta, A., Deering, S., Gupta, M. 2006. Internet Control Message 917 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 918 Specification. RFC 4443. 920 CORE. 2003. Core Secure Technologies Advisory CORE-2003-0307: Snort 921 TCP Stream Reassembly Integer Overflow Vulnerability. Available at: 922 http://www.coresecurity.com/common/showdoc.php?idx=313&idxseccion=10 924 CPNI, 2008. Security Assessment of the Internet Protocol. Available 925 at: http://www.cpni.gov.uk/Docs/InternetProtocol.pdf 927 CPNI, 2009. Security Assessment of the Transmission Control Protocol 928 (TCP). Available at: 929 http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf 930 daemon9, route, and infinity. 1996. IP-spoofing Demystified (Trust- 931 Relationship Exploitation), Phrack Magazine, Volume Seven, Issue 932 Forty-Eight, File 14 of 18. Available at: 933 http://www.phrack.org/archives/48/P48-14 935 Deering, S., Hinden, R. 1998. Internet Protocol, Version 6 (IPv6) 936 Specification. RFC 2460. 938 Dharmapurikar, S., Paxson, V. 2005. Robust TCP Stream Reassembly In 939 the Presence of Adversaries. Proceedings of the USENIX Security 940 Symposium 2005. 942 Duke, M., Braden, R., Eddy, W., Blanton, E. 2006. A Roadmap for 943 Transmission Control Protocol (TCP) Specification Documents. RFC 944 4614. 946 Ed3f. 2002. Firewall spotting and networks analisys with a broken 947 CRC. Phrack Magazine, Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10. 948 Available at: http://www.phrack.org/phrack/60/p60-0x0c.txt 950 Eddy, W. 2007. TCP SYN Flooding Attacks and Common Mitigations. RFC 951 4987. 953 Fenner, B. 2006. Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, 954 UDP, and TCP Headers. RFC 4727. 956 Ferguson, P., and Senie, D. 2000. Network Ingress Filtering: 957 Defeating Denial of Service Attacks which employ IP Source Address 958 Spoofing. RFC 2827. 960 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 961 Leach, P., and Berners-Lee, T. 1999. Hypertext Transfer Protocol -- 962 HTTP/1.1. RFC 2616. 964 Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. 2000. An Extension 965 to the Selective Acknowledgement (SACK) Option for TCP. RFC 2883. 967 Floyd, S., Henderson, T., Gurtov, A. 2004. The NewReno Modification 968 to TCP's Fast Recovery Algorithm. RFC 3782. 970 Floyd, S., Allman, M., Jain, A., Sarolahti, P. 2007. Quick-Start for 971 TCP and IP. RFC 4782. 973 Fyodor. 1998. Remote OS Detection via TCP/IP Stack Fingerprinting. 974 Phrack Magazine, Volume 8, Issue, 54. 976 Fyodor. 2006a. Remote OS Detection via TCP/IP Fingerprinting (2nd 977 Generation). Available at: http://insecure.org/nmap/osdetect/. 979 Fyodor. 2006b. Nmap - Free Security Scanner For Network Exploration 980 and Audit. Available at: http://www.insecure.org/nmap. 982 Fyodor. 2008. Nmap Reference Guide: Port Scanning Techniques. 983 Available at: http://nmap.org/book/man-port-scanning-techniques.html 985 GIAC. 2000. Egress Filtering v 0.2. Available at: 986 http://www.sans.org/y2k/egress.htm 988 Giffin, J., Greenstadt, R., Litwack, P., Tibbetts, R. 2002. Covert 989 Messaging through TCP Timestamps. PET2002 (Workshop on Privacy 990 Enhancing Technologies), San Francisco, CA, USA, April 2002. 991 Available at: 992 http://web.mit.edu/greenie/Public/CovertMessaginginTCP.ps 994 Gill, V., Heasley, J., Meyer, D., Savola, P, Pignataro, C. 2007. The 995 Generalized TTL Security Mechanism (GTSM). RFC 5082. 997 Gont, F. 2006. Advanced ICMP packet filtering. Available at: 998 http://www.gont.com.ar/papers/icmp-filtering.html 1000 Gont, F. 2008a. ICMP attacks against TCP. IETF Internet-Draft 1001 (draft-ietf-tcpm-icmp-attacks-04.txt), work in progress. 1003 Gont, F.. 2008b. TCP's Reaction to Soft Errors. IETF Internet-Draft 1004 (draft-ietf-tcpm-tcp-soft-errors-09.txt), work in progress. 1006 Gont, F. 2009. On the generation of TCP timestamps. IETF Internet- 1007 Draft (draft-gont-tcpm-tcp-timestamps-01.txt), work in progress. 1009 Gont, F., Srisuresh, P. 2008. Security Implications of Network 1010 Address Translators (NATs). IETF Internet-Draft 1011 (draft-gont-behave-nat-security-01.txt), work in progress. 1013 Gont, F., Yourtchenko, A. 2009. On the implementation of TCP urgent 1014 data. IETF Internet-Draft (draft-gont-tcpm-urgent-data-01.txt), work 1015 in progress. 1017 Heffernan, A. 1998. Protection of BGP Sessions via the TCP MD5 1018 Signature Option. RFC 2385. 1020 Heffner, J. 2002. High Bandwidth TCP Queuing. Senior Thesis. 1022 Hoenes, A. 2007. TCP options - tcp-parameters IANA registry. Post 1023 to the tcpm wg mailing-list. Available at: 1024 http://www.ietf.org/mail-archive/web/tcpm/current/msg03199.html 1026 IANA. 2007. Transmission Control Protocol (TCP) Option Numbers. 1028 Avialable at: http://www.iana.org/assignments/tcp-parameters/ 1030 IANA. 2008. Port Numbers. Available at: 1031 http://www.iana.org/assignments/port-numbers 1033 Jacobson, V. 1988. Congestion Avoidance and Control. Computer 1034 Communication Review, vol. 18, no. 4, pp. 314-329. Available at: 1035 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z 1037 Jacobson, V., Braden, R. 1988. TCP Extensions for Long-Delay Paths. 1038 RFC 1072. 1040 Jacobson, V., Braden, R., Borman, D. 1992. TCP Extensions for High 1041 Performance. RFC 1323. 1043 Jones, S. 2003. Port 0 OS Fingerprinting. Available at: 1044 http://www.gont.com.ar/docs/port-0-os-fingerprinting.txt 1046 Kent, S. and Seo, K. 2005. Security Architecture for the Internet 1047 Protocol. RFC 4301. 1049 Klensin, J. 2008. Simple Mail Transfer Protocol. RFC 5321. 1051 Ko, Y., Ko, S., and Ko, M. 2001. NIDS Evasion Method named SeolMa. 1052 Phrack Magazine, Volume 0x0b, Issue 0x39, phile #0x03 of 0x12. 1053 Available at: http://www.phrack.org/issues.html?issue=57&id=3#article 1055 Lahey, K. 2000. TCP Problems with Path MTU Discovery. RFC 2923. 1057 Larsen, M., Gont, F. 2008. Port Randomization. IETF Internet-Draft 1058 (draft-ietf-tsvwg-port-randomization-02), work in progress. 1060 Lemon, 2002. Resisting SYN flood DoS attacks with a SYN cache. 1061 Proceedings of the BSDCon 2002 Conference, pp 89-98. 1063 Maimon, U. 1996. Port Scanning without the SYN flag. Phrack 1064 Magazine, Volume Seven, Issue Fourty-Nine, phile #0x0f of 0x10. 1065 Available at: 1066 http://www.phrack.org/issues.html?issue=49&id=15#article 1068 Mathis, M., Mahdavi, J., Floyd, S. Romanow, A. 1996. TCP Selective 1069 Acknowledgment Options. RFC 2018. 1071 Mathis, M., and Heffner, J. 2007. Packetization Layer Path MTU 1072 Discovery. RFC 4821. 1074 McCann, J., Deering, S., Mogul, J. 1996. Path MTU Discovery for IP 1075 version 6. RFC 1981. 1077 McKusick, M., Bostic, K., Karels, M., and J. Quarterman. 1996. The 1078 Design and Implementation of the 4.4BSD Operating System. Addison- 1079 Wesley. 1081 Meltman. 1997. new TCP/IP bug in win95. Post to the bugtraq mailing- 1082 list. Available at: http://insecure.org/sploits/land.ip.DOS.html 1084 Miller, T. 2006. Passive OS Fingerprinting: Details and Techniques. 1085 Available at: http://www.ouah.org/incosfingerp.htm . 1087 Mogul, J., and Deering, S. 1990. Path MTU Discovery. RFC 1191. 1089 Morris, R. 1985. A Weakness in the 4.2BSD Unix TCP/IP Software. 1090 Technical Report CSTR-117, AT&T Bell Laboratories. Available at: 1091 http://pdos.csail.mit.edu/~rtm/papers/117.pdf . 1093 Myst. 1997. Windows 95/NT DoS. Post to the bugtraq mailing-list. 1094 Available at: http://seclists.org/bugtraq/1997/May/0039.html 1096 Nichols, K., Blake, S., Baker, F., and Black, D. 1998. Definition of 1097 the Differentiated Services Field (DS Field) in the IPv4 and IPv6 1098 Headers. RFC 2474. 1100 NISCC. 2004. NISCC Vulnerability Advisory 236929: Vulnerability 1101 Issues in TCP. Available at: 1102 http://www.uniras.gov.uk/niscc/docs/re-20040420-00391.pdf 1104 NISCC. 2005. NISCC Vulnerability Advisory 532967/NISCC/ICMP: 1105 Vulnerability Issues in ICMP packets with TCP payloads. Available 1106 at: http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf 1108 NISCC. 2006. NISCC Technical Note 01/2006: Egress and Ingress 1109 Filtering. Available at: 1110 http://www.niscc.gov.uk/niscc/docs/re-20060420-00294.pdf?lang=en 1112 Ostermann, S. 2008. tcptrace tool. Tool and documentation available 1113 at: http://www.tcptrace.org. 1115 Paxson, V., Allman, M. 2000. Computing TCP's Retransmission Timer. 1116 RFC 2988. 1118 PCNWG. 2009. Congestion and Pre-Congestion Notification (pcn) 1119 charter. Available at: 1120 http://www.ietf.org/html.charters/pcn-charter.html 1122 PMTUDWG. 2007. Path MTU Discovery (pmtud) charter. Available at: 1123 http://www.ietf.org/html.charters/OLD/pmtud-charter.html 1124 Postel, J. 1981a. Internet Protocol. DARPA Internet Program. 1125 Protocol Specification. RFC 791. 1127 Postel, J. 1981b. Internet Control Message Protocol. RFC 792. 1129 Postel, J. 1981c. Transmission Control Protocol. DARPA Internet 1130 Program. Protocol Specification. RFC 793. 1132 Postel, J. 1987. TCP AND IP BAKE OFF. RFC 1025. 1134 Ptacek, T. H., and Newsham, T. N. 1998. Insertion, Evasion and 1135 Denial of Service: Eluding Network Intrusion Detection. Secure 1136 Networks, Inc. Available at: 1137 http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps 1139 Ramaiah, A., Stewart, R., and Dalal, M. 2008. Improving TCP's 1140 Robustness to Blind In-Window Attacks. IETF Internet-Draft 1141 (draft-ietf-tcpm-tcpsecure-10.txt), work in progress. 1143 Ramakrishnan, K., Floyd, S., and Black, D. 2001. The Addition of 1144 Explicit Congestion Notification (ECN) to IP. RFC 3168. 1146 Rekhter, Y., Li, T., Hares, S. 2006. A Border Gateway Protocol 4 1147 (BGP-4). RFC 4271. 1149 Rivest, R. 1992. The MD5 Message-Digest Algorithm. RFC 1321. 1151 Rowland, C. 1997. Covert Channels in the TCP/IP Protocol Suite. 1152 First Monday Journal, Volume 2, Number 5. Available at: 1153 http://www.firstmonday.org/issues/issue2_5/rowland/ 1155 Savage, S., Cardwell, N., Wetherall, D., Anderson, T. 1999. TCP 1156 Congestion Control with a Misbehaving Receiver. ACM Computer 1157 Communication Review, 29(5), October 1999. 1159 Semke, J., Mahdavi, J., Mathis, M. 1998. Automatic TCP Buffer 1160 Tuning. ACM Computer Communication Review, Vol. 28, No. 4. 1162 Shalunov, S. 2000. Netkill. Available at: 1163 http://www.internet2.edu/~shalunov/netkill/netkill.html 1165 Shimomura, T. 1995. Technical details of the attack described by 1166 Markoff in NYT. Message posted in USENET's comp.security.misc 1167 newsgroup, Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>. Available at: 1168 http://www.gont.com.ar/docs/post-shimomura-usenet.txt. 1170 Silbersack, M. 2005. Improving TCP/IP security through randomization 1171 without sacrificing interoperability. EuroBSDCon 2005 Conference. 1173 SinFP. 2006. Net::SinFP - a Perl module to do OS fingerprinting. 1174 Available at: 1175 http://www.gomor.org/cgi-bin/index.pl?mode=view;page=sinfp 1177 Smart, M., Malan, G., Jahanian, F. 2000. Defeating TCP/IP Stack 1178 Fingerprinting. Proceedings of the 9th USENIX Security Symposium, 1179 pp. 229-240. Available at: http://www.usenix.org/publications/ 1180 library/proceedings/sec2000/full_papers/smart/smart_html/index.html 1182 Smith, C., Grundl, P. 2002. Know Your Enemy: Passive Fingerprinting. 1183 The Honeynet Project. 1185 Spring, N., Wetherall, D., Ely, D. 2003. Robust Explicit Congestion 1186 Notification (ECN) Signaling with Nonces. RFC 3540. 1188 Srisuresh, P., Egevang, K. 2001. Traditional IP Network Address 1189 Translator (Traditional NAT). RFC 3022. 1191 Stevens, W. R. 1994. TCP/IP Illustrated, Volume 1: The Protocols. 1192 Addison-Wesley Professional Computing Series. 1194 TBIT. 2001. TBIT, the TCP Behavior Inference Tool. Available at: 1195 http://www.icir.org/tbit/ 1197 Touch, J. 2007. Defending TCP Against Spoofing Attacks. RFC 4953. 1199 US-CERT. 2001. US-CERT Vulnerability Note VU#498440: Multiple TCP/IP 1200 implementations may use statistically predictable initial sequence 1201 numbers. Available at: http://www.kb.cert.org/vuls/id/498440 1203 US-CERT. 2003a. US-CERT Vulnerability Note VU#26825: Cisco Secure 1204 PIX Firewall TCP Reset Vulnerability. Available at: 1205 http://www.kb.cert.org/vuls/id/26825 1207 US-CERT. 2003b. US-CERT Vulnerability Note VU#464113: TCP/IP 1208 implementations handle unusual flag combinations inconsistently. 1209 Available at: http://www.kb.cert.org/vuls/id/464113 1211 US-CERT. 2004a. US-CERT Vulnerability Note VU#395670: FreeBSD fails 1212 to limit number of TCP segments held in reassembly queue. Available 1213 at: http://www.kb.cert.org/vuls/id/395670 1215 US-CERT. 2005a. US-CERT Vulnerability Note VU#102014: Optimistic TCP 1216 acknowledgements can cause denial of service. Available at: 1217 http://www.kb.cert.org/vuls/id/102014 1219 US-CERT. 2005b. US-CERT Vulnerability Note VU#396645: Microsoft 1220 Windows vulnerable to DoS via LAND attack. Available at: 1222 http://www.kb.cert.org/vuls/id/396645 1224 US-CERT. 2005c. US-CERT Vulnerability Note VU#637934: TCP does not 1225 adequately validate segments before updating timestamp value. 1226 Available at: http://www.kb.cert.org/vuls/id/637934 1228 US-CERT. 2005d. US-CERT Vulnerability Note VU#853540: Cisco PIX 1229 fails to verify TCP checksum. Available at: 1230 http://www.kb.cert.org/vuls/id/853540. 1232 Veysset, F., Courtay, O., Heen, O. 2002. New Tool And Technique For 1233 Remote Operating System Fingerprinting. Intranode Research Team. 1235 Watson, P. 2004. Slipping in the Window: TCP Reset Attacks, 1236 CanSecWest 2004 Conference. 1238 Welzl, M. 2008. Internet congestion control: evolution and current 1239 open issues. CAIA guest talk, Swinburne University, Melbourne, 1240 Australia. Available at: 1241 http://www.welzl.at/research/publications/caia-jan08.pdf 1243 Wright, G. and W. Stevens. 1994. TCP/IP Illustrated, Volume 2: The 1244 Implementation. Addison-Wesley. 1246 Zalewski, M. 2001a. Strange Attractors and TCP/IP Sequence Number 1247 Analysis. Available at: 1248 http://lcamtuf.coredump.cx/oldtcp/tcpseq.html 1250 Zalewski, M. 2001b. Delivering Signals for Fun and Profit. 1251 Available at: http://lcamtuf.coredump.cx/signals.txt 1253 Zalewski, M. 2002. Strange Attractors and TCP/IP Sequence Number 1254 Analysis - One Year Later. Available at: 1255 http://lcamtuf.coredump.cx/newtcp/ 1257 Zalewski, M. 2003a. Windows URG mystery solved! Post to the bugtraq 1258 mailing-list. Available at: 1259 http://lcamtuf.coredump.cx/p0f-help/p0f/doc/win-memleak.txt 1261 Zalewski, M. 2003b. A new TCP/IP blind data injection technique? 1262 Post to the bugtraq mailing-list. Available at: 1263 http://lcamtuf.coredump.cx/ipfrag.txt 1265 Zalewski, M. 2006a. p0f passive fingerprinting tool. Available at: 1266 http://lcamtuf.coredump.cx/p0f.shtml 1268 Zalewski, M. 2006b. p0f - RST+ signatures. Available at: 1269 http://lcamtuf.coredump.cx/p0f-help/p0f/p0fr.fp 1270 Zalewski, M. 2007. 0trace - traceroute on established connections. 1271 Post to the bugtraq mailing-list. Available at: 1272 http://seclists.org/bugtraq/2007/Jan/0176.html 1274 Zalewski, M. 2008. Museum of broken packets. Available at: 1275 http://lcamtuf.coredump.cx/mobp/ 1277 Zander, S. 2008. Covert Channels in Computer Networks. Available 1278 at: http://caia.swin.edu.au/cv/szander/cc/index.html 1280 Zuquete, A. 2002. Improving the functionality of SYN cookies. 6th 1281 IFIP Communications and Multimedia Security Conference (CMS 2002). 1282 Available at: http://www.ieeta.pt/~avz/pubs/CMS02.html 1284 Zweig, J., Partridge, C. 1990. TCP Alternate Checksum Options. RFC 1285 1146. 1287 Appendix A. Changes from previous versions of the draft (to be removed 1288 by the RFC Editor before publishing this document as an 1289 RFC) 1291 A.1. Changes from draft-gont-tcp-security-00 1293 o Draft resubmitted as draft-ietf (boilerplate updated as required). 1295 Appendix B. Advice and guidance to vendors 1297 Vendors are urged to contact CSIRTUK (csirt@cpni.gsi.gov.uk) if they 1298 think they may be affected by the issues described in this document. 1299 As the lead coordination center for these issues, CPNI is well placed 1300 to give advice and guidance as required. 1302 CPNI works extensively with government departments and agencies, 1303 commercial organizations and the academic community to research 1304 vulnerabilities and potential threats to IT systems especially where 1305 they may have an impact on Critical National Infrastructure's (CNI). 1307 Other ways to contact CPNI, plus CPNI's PGP public key, are available 1308 at http://www.cpni.gov.uk/ . 1310 Author's Address 1312 Fernando Gont 1313 UK Centre for the Protection of National Infrastructure 1315 Email: fernando@gont.com.ar 1316 URI: http://www.cpni.gov.uk