TCP Maintenance and Minor F. Gont Extensions (tcpm) UK CPNI Internet-Draft August 19, 2009 Intended status: BCP Expires: February 20, 2010 Security Assessment of the Transmission Control Protocol (TCP) draft-ietf-tcpm-tcp-security-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document contains a security assessment of the specifications of the Transmission Control Protocol (TCP), and of a number of Gont Expires February 20, 2010 [Page 1] Internet-Draft TCP Security Assessment August 2009 mechanisms and policies in use by popular TCP implementations. Additionally, it contains best current practices for hardening a TCP implementation. Table of Contents 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6 1.3. Organization of this document . . . . . . . . . . . . . . 7 2. The Transmission Control Protocol . . . . . . . . . . . . . . 7 3. TCP header fields . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Source Port . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. Problems that may arise as a result of collisions of connection-id's . . . . . . . . . . . . . . . . . . 11 3.1.2. Port randomization algorithms . . . . . . . . . . . . 12 3.1.3. TCP ephemeral port range . . . . . . . . . . . . . . . 12 3.2. Destination port . . . . . . . . . . . . . . . . . . . . . 12 3.3. Sequence number . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. Generation of Initial Sequence Numbers . . . . . . . . 13 3.4. Acknowledgement Number . . . . . . . . . . . . . . . . . . 13 3.5. Data Offset . . . . . . . . . . . . . . . . . . . . . . . 13 3.6. Control bits . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.1. Reserved (four bits) . . . . . . . . . . . . . . . . . 13 3.6.2. CWR (Congestion Window Reduced) . . . . . . . . . . . 13 3.6.3. ECE (ECN-Echo) . . . . . . . . . . . . . . . . . . . . 13 3.6.4. URG . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.5. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.6. PSH . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.7. RST . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.8. SYN . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6.9. FIN . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Window . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7.1. Security implications of the maximum TCP window size . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7.2. Security implications arising from closed windows . . 13 3.8. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.9. Urgent pointer . . . . . . . . . . . . . . . . . . . . . . 13 3.9.1. Security implications arising from ambiguities in the processing of urgent indications . . . . . . . . . 14 3.9.2. Security implications arising from the implementation of the urgent mechanism as "out of band" data . . . . . . . . . . . . . . . . . . . . . . 14 3.10. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.11. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.12. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Common TCP Options . . . . . . . . . . . . . . . . . . . . . . 14 Gont Expires February 20, 2010 [Page 2] Internet-Draft TCP Security Assessment August 2009 4.1. End of Option List (Kind = 0) . . . . . . . . . . . . . . 14 4.2. No Operation (Kind = 1) . . . . . . . . . . . . . . . . . 14 4.3. Maximum Segment Size (Kind = 2) . . . . . . . . . . . . . 14 4.4. Selective Acknowledgement Option . . . . . . . . . . . . . 14 4.4.1. SACK-permitted Option (Kind = 4) . . . . . . . . . . . 14 4.4.2. SACK Option (Kind = 5) . . . . . . . . . . . . . . . . 14 4.5. MD5 Option (Kind=19) . . . . . . . . . . . . . . . . . . . 14 4.6. Window scale option (Kind = 3) . . . . . . . . . . . . . . 14 4.7. Timestamps option (Kind = 8) . . . . . . . . . . . . . . . 14 4.7.1. Generation of timestamps . . . . . . . . . . . . . . . 14 4.7.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . 14 5. Connection-establishment mechanism . . . . . . . . . . . . . . 14 5.1. SYN flood . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Connection forgery . . . . . . . . . . . . . . . . . . . . 14 5.3. Connection-flooding attack . . . . . . . . . . . . . . . . 14 5.3.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 14 5.3.2. Countermeasures . . . . . . . . . . . . . . . . . . . 14 5.4. Firewall-bypassing techniques . . . . . . . . . . . . . . 15 6. Connection-termination mechanism . . . . . . . . . . . . . . . 15 6.1. FIN-WAIT-2 flooding attack . . . . . . . . . . . . . . . . 15 6.1.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15 6.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 7. Buffer management . . . . . . . . . . . . . . . . . . . . . . 15 7.1. TCP retransmission buffer . . . . . . . . . . . . . . . . 15 7.1.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15 7.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 7.2. TCP segment reassembly buffer . . . . . . . . . . . . . . 15 7.3. Automatic buffer tuning mechanisms . . . . . . . . . . . . 15 7.3.1. Automatic send-buffer tuning mechanisms . . . . . . . 15 7.3.2. Automatic receive-buffer tuning mechanism . . . . . . 15 8. TCP segment reassembly algorithm . . . . . . . . . . . . . . . 15 8.1. Problems that arise from ambiguity in the reassembly process . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 15 9.1. Congestion control with misbehaving receivers . . . . . . 15 9.1.1. ACK division . . . . . . . . . . . . . . . . . . . . . 15 9.1.2. DupACK forgery . . . . . . . . . . . . . . . . . . . . 15 9.1.3. Optimistic ACKing . . . . . . . . . . . . . . . . . . 15 9.2. Blind DupACK triggering attacks against TCP . . . . . . . 15 9.2.1. Blind throughput-reduction attack . . . . . . . . . . 15 9.2.2. Blind flooding attack . . . . . . . . . . . . . . . . 16 9.2.3. Difficulty in performing the attacks . . . . . . . . . 16 9.2.4. Modifications to TCP's loss recovery algorithms . . . 16 9.2.5. Countermeasures . . . . . . . . . . . . . . . . . . . 16 9.3. TCP Explicit Congestion Notification (ECN) . . . . . . . . 16 9.3.1. Possible attacks by a compromised router . . . . . . . 16 9.3.2. Possible attacks by a malicious TCP endpoint . . . . . 16 10. TCP API . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Gont Expires February 20, 2010 [Page 3] Internet-Draft TCP Security Assessment August 2009 10.1. Passive opens and binding sockets . . . . . . . . . . . . 16 10.2. Active opens and binding sockets . . . . . . . . . . . . . 16 11. Blind in-window attacks . . . . . . . . . . . . . . . . . . . 16 11.1. Blind TCP-based connection-reset attacks . . . . . . . . . 16 11.1.1. RST flag . . . . . . . . . . . . . . . . . . . . . . . 16 11.1.2. SYN flag . . . . . . . . . . . . . . . . . . . . . . . 16 11.1.3. Security/Compartment . . . . . . . . . . . . . . . . . 16 11.1.4. Precedence . . . . . . . . . . . . . . . . . . . . . . 16 11.1.5. Illegal options . . . . . . . . . . . . . . . . . . . 16 11.2. Blind data-injection attacks . . . . . . . . . . . . . . . 16 12. Information leaking . . . . . . . . . . . . . . . . . . . . . 16 12.1. Remote Operating System detection via TCP/IP stack fingerprinting . . . . . . . . . . . . . . . . . . . . . . 16 12.1.1. FIN probe . . . . . . . . . . . . . . . . . . . . . . 16 12.1.2. Bogus flag test . . . . . . . . . . . . . . . . . . . 16 12.1.3. TCP ISN sampling . . . . . . . . . . . . . . . . . . . 17 12.1.4. TCP initial window . . . . . . . . . . . . . . . . . . 17 12.1.5. RST sampling . . . . . . . . . . . . . . . . . . . . . 17 12.1.6. TCP options . . . . . . . . . . . . . . . . . . . . . 17 12.1.7. Retransmission Timeout (RTO) sampling . . . . . . . . 17 12.2. System uptime detection . . . . . . . . . . . . . . . . . 17 13. Covert channels . . . . . . . . . . . . . . . . . . . . . . . 17 14. TCP Port scanning . . . . . . . . . . . . . . . . . . . . . . 17 14.1. Traditional connect() scan . . . . . . . . . . . . . . . . 17 14.2. SYN scan . . . . . . . . . . . . . . . . . . . . . . . . . 17 14.3. FIN, NULL, and XMAS scans . . . . . . . . . . . . . . . . 17 14.4. Maimon scan . . . . . . . . . . . . . . . . . . . . . . . 17 14.5. Window scan . . . . . . . . . . . . . . . . . . . . . . . 17 14.6. ACK scan . . . . . . . . . . . . . . . . . . . . . . . . . 17 15. Processing of ICMP error messages by TCP . . . . . . . . . . . 17 16. TCP interaction with the Internet Protocol (IP) . . . . . . . 17 16.1. TCP-based traceroute . . . . . . . . . . . . . . . . . . . 17 16.2. Blind TCP data injection through fragmented IP traffic . . 17 16.3. Broadcast and multicast IP addresses . . . . . . . . . . . 17 17. Security Considerations . . . . . . . . . . . . . . . . . . . 17 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Changes from previous versions of the draft (to be removed by the RFC Editor before publishing this document as an RFC) . . . . . . . . . . . . . . 28 A.1. Changes from draft-gont-tcp-security-00 . . . . . . . . . 28 Appendix B. Advice and guidance to vendors . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 Gont Expires February 20, 2010 [Page 4] Internet-Draft TCP Security Assessment August 2009 1. Preface 1.1. Introduction The TCP/IP protocol suite was conceived in an environment that was quite different from the hostile environment they currently operate in. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that, to some extent, the current world's economy depends on them. While many textbooks and articles have created the myth that the Internet protocols were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET [Clark, 1988]. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify, and overlook their security implications. While the Internet technology evolved since it early inception, the Internet's building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in some protocol implementations, affecting only a reduced number of systems, while others were based in flaws in the protocols themselves, affecting virtually every existing implementation [Bellovin, 1989]. Even in the last couple of years, researchers were still working on security problems in the core protocols [NISCC, 2004] [NISCC, 2005]. The discovery of vulnerabilities in the TCP/IP protocol suite usually led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats and the best mitigations known at the time the reports were published. Unfortunately, this also led to the documentation of the discovered protocol vulnerabilities being spread among a large number of documents, which are sometimes difficult to identify. For some reason, much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force). This basically led to a situation in which "known" security problems have not always been addressed by all vendors. In addition, in many cases vendors have implemented quick "fixes" to the identified vulnerabilities without a careful analysis of their effectiveness and their impact on interoperability [Silbersack, 2005]. Producing a secure TCP/IP implementation nowadays is a very difficult Gont Expires February 20, 2010 [Page 5] Internet-Draft TCP Security Assessment August 2009 task, in part because of the lack of a single document that serves as a security roadmap for the protocols. Implementers are faced with the hard task of identifying relevant documentation and differentiating between that which provides correct advice, and that which provides misleading advice based on inaccurate or wrong assumptions. This document is the result of a security assessment of the IETF specifications of the Transmission Control Protocol (TCP), from a security point of view. Possible threats are identified and, where possible, countermeasures are proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document is heavily based on the "Security Assessment of the Transmission Control Protocol (TCP)" released by the UK Centre for the Protection of National Infrastructure (CPNI), available at: http: //www.cpni.gov.uk/Products/technicalnotes/ Feb-09-security-assessment-TCP.aspx . 1.2. Scope of this document While there are a number of protocols that may affect the way TCP operates, this document focuses only on the specifications of the Transmission Control Protocol (TCP) itself. The following IETF RFCs were selected for assessment as part of this work: o RFC 793, "Transmission Control Protocol. DARPA Internet Program. Protocol Specification" (91 pages) o RFC 1122, "Requirements for Internet Hosts -- Communication Layers" (116 pages) o RFC 1191, "Path MTU Discovery" (19 pages) o RFC 1323, "TCP Extensions for High Performance" (37 pages) o RFC 1948, "Defending Against Sequence Number Attacks" (6 pages) o RFC 1981, "Path MTU Discovery for IP version 6" (15 pages) o RFC 2018, "TCP Selective Acknowledgment Options" (12 pages) o RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option" (6 pages) Gont Expires February 20, 2010 [Page 6] Internet-Draft TCP Security Assessment August 2009 o RFC 2581, "TCP Congestion Control" (14 pages) o RFC 2675, "IPv6 Jumbograms" (9 pages) o RFC 2883, "An Extension to the Selective Acknowledgement (SACK) Option for TCP" (17 pages) o RFC 2884, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks" (18 pages) o RFC 2988, "Computing TCP's Retransmission Timer" (8 pages) o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP" (63 pages) o RFC 3465, "TCP Congestion Control with Appropriate Byte Counting (ABC)" (10 pages) o RFC 3517, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP" (13 pages) o RFC 3540, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" (13 pages) o RFC 3782, "The NewReno Modification to TCP's Fast Recovery Algorithm" (19 pages) 1.3. Organization of this document This document is basically organized in two parts. The first part contains a discussion of each of the TCP header fields, identifies their security implications, and discusses the possible countermeasures. The second part contains an analysis of the security implications of the mechanisms and policies implemented by TCP, and of a number of implementation strategies in use by a number of popular TCP implementations. 2. The Transmission Control Protocol The Transmission Control Protocol (TCP) is a connection-oriented transport protocol that provides a reliable byte-stream data transfer service. Very few assumptions are made about the reliability of underlying data transfer services below the TCP layer. Basically, TCP assumes it can obtain a simple, potentially unreliable datagram service from the lower level protocols. Figure 1 illustrates where TCP fits in Gont Expires February 20, 2010 [Page 7] Internet-Draft TCP Security Assessment August 2009 the DARPA reference model. +---------------+ | Application | +---------------+ | TCP | +---------------+ | IP | +---------------+ | Network | +---------------+ Figure 1: TCP in the DARPA reference model TCP provides facilities in the following areas: o Basic Data Transfer o Reliability o Flow Control o Multiplexing o Connections o Precedence and Security o Congestion Control The core TCP specification, RFC 793 [Postel, 1981c], dates back to 1981 and standardizes the basic mechanisms and policies of TCP. RFC 1122 [Braden, 1989] provides clarifications and errata for the original specification. RFC 2581 [Allman et al, 1999] specifies TCP congestion control and avoidance mechanisms, not present in the original specification. Other documents specify extensions and improvements for TCP. The large amount of documents that specify extensions, improvements, or modifications to existing TCP mechanisms has led the IETF to publish a roadmap for TCP, RFC 4614 [Duke et al, 2006], that clarifies the relevance of each of those documents. 3. TCP header fields RFC 793 [Postel, 1981c] defines the syntax of a TCP segment, along with the semantics of each of the header fields. Figure 2 Gont Expires February 20, 2010 [Page 8] Internet-Draft TCP Security Assessment August 2009 illustrates the syntax of a TCP segment. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |C|E|U|A|P|R|S|F| | | Offset|Resrved|W|C|R|C|S|S|Y|I| Window | | | |R|E|G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that one tick mark represents one bit position Figure 2: Transmission Control Protocol header format The minimum TCP header size is 20 bytes, and corresponds to a TCP segment with no options and no data. However, a TCP module might be handed an (illegitimate) "TCP segment" of less than 20 bytes. Therefore, before doing any processing of the TCP header fields, the following check should be performed by TCP on the segments handed by the internet layer: Segment.Size >= 20 If a segment does not pass this check, it should be dropped. The following subsections contain further sanity checks that should be performed on TCP segments. 3.1. Source Port This field contains a 16-bit number that identifies the TCP end-point that originated this TCP segment. Being a 16-bit field, it can contain any value in the range 0-65535. The Internet Assigned Numbers Authority (IANA) has traditionally Gont Expires February 20, 2010 [Page 9] Internet-Draft TCP Security Assessment August 2009 reserved the following use of the 16-bit port range of TCP [IANA, 2008]: o The Well Known Ports, 0 through 1023 o The Registered Ports, 1024 through 49151 o The Dynamic and/or Private Ports, 49152 through 65535 The range of assigned ports managed by the IANA is 0-1023, with the remainder being registered by IANA but not assigned [IANA, 2008]. It is also worth noting that, while some systems restrict use of the port numbers in the range 0-1024 to privileged users, no trust should be granted based on the port numbers used for a TCP connection. Servers usually bind specific ports on which specific services are usually provided, while clients usually make use of the so-called "ephemeral ports" for the source port of their outgoing connections with the only requirement that the resulting four-tuple must be unique (not currently in use by any other transport protocol instance). While the only requirement for a selected ephemeral port is that the resulting four-tuple (connection-id) is unique, in practice it may be necessary to not allow the allocation of port numbers that are in use by a TCP that is in the LISTEN or CLOSED states for use as ephemeral ports, as this might allow an attacker to "steal" incoming connections from a local server application. Section 10.2 of this document provides a detailed discussion of this issue. It should also be noted that some clients, such as DNS resolvers, are known to use port numbers from the "Well Known Ports" range. Therefore, middle-boxes such as packet filters should not assume that clients use port number from only the Dynamic or Registered port ranges. While port 0 is a legitimate port number, it has a special meaning in the UNIX Sockets API. For example, when a TCP port number of 0 is passed as an argument to the bind() function, rather than binding port 0, an ephemeral port is selected for the corresponding TCP end- point. As a result, the TCP port number 0 is never actually used in TCP segments. Different implementations have been found to respond differently to TCP segments that have a port number of 0 as the Source Port and/or the Destination Port. As a result, TCP segments with a port number of 0 are usually employed for remote OS detection via TCP/IP stack fingerprinting [Jones, 2003]. Gont Expires February 20, 2010 [Page 10] Internet-Draft TCP Security Assessment August 2009 Since in practice TCP port 0 is not used by any legitimate application and is only used for fingerprinting purposes, a number of host implementations already reject TCP segments that use 0 as the Source Port and/or the Destination Port. Also, a number firewalls filter (by default) any TCP segments that contain a port number of zero for the Source Port and/or the Destination Port. We therefore recommend that TCP implementations respond to incoming TCP segments that have a Source Port of 0 with an RST (provided these incoming segments do not have the RST bit set). Responding with an RST segment to incoming segments that have the RST bit would open the door to RST-war attacks. As discussed in Section 3.2, we also recommend TCP implementations to respond with an RST to incoming packets that have a Destination Port of 0 (provided these incoming segments do not have the RST bit set). 3.1.1. Problems that may arise as a result of collisions of connection- id's A number of implementations will not allow the creation of a new connection if there exists a previous incarnation of the same connection in any state other than the fictional state CLOSED. This can be problematic in scenarios in which a client establishes connections with a specific service at a particular server at a high rate: even if the connections are also closed at a high rate, one of the systems (the one performing the active close) will keep each of the closed connections in the TIME-WAIT state for 2*MSL. MSL (Maximum Segment Lifetime) is the maximum amount of time that a TCP segment can exist in an internet. It is defined to be 2 minutes by RFC 793 [Postel, 1981c]. If the connection rate is high enough, at some point all the ephemeral ports at the client will be in use by some connection in the TIME-WAIT state, thus preventing the establishment of new connections. In order to overcome this problem, a number of TCP implementations include some heuristics to allow the creation of a new incarnation of a connection that is in the TIME-WAIT state. In such implementations a new incarnation of a previous connection is allowed if: o The incoming SYN segment contains a timestamp option, and the timestamp is greater than the last timestamp seen in the previous incarnation of the connection (for that direction of the data transfer), or, Gont Expires February 20, 2010 [Page 11] Internet-Draft TCP Security Assessment August 2009 o The incoming SYN segment does not contain a timestamp option, but its Initial Sequence Number (ISN) is greater than the last sequence number seen in the previous incarnation of the connection (for that direction of the data transfer) Unfortunately, these heuristics are optional, and thus cannot be relied upon. Additionally, as indicated by [Silbersack, 2005], if the Timestamp or the ISN are trivially randomized, these heuristics might fail. Section 3.3.1 and Section 4.7.1 of this document recommend algorithms for the generation of TCP Initial Sequence Numbers and TCP timestamps, respectively, that provide randomization, while still allowing the aforementioned heuristics to work. Therefore, the only strategy that can be relied upon to avoid this interoperability problem is to minimize the rate of collisions of connection-id's. A good algorithm to minimize rate of collisions of connection-id's would consider the time a given four-tuple {Source Address, Source Port, Destination Address, Destination Port} was last used, and would try avoid reusing it for 2*MSL. However, an efficient implementation approach for this algorithm has not yet been devised. A simple approach to minimize the rate collisions of connection-id's in most scenarios is to maximize the port reuse cycle, such that a port number is not reused before all the other port numbers in the ephemeral port range have been used for outgoing connections. This is the traditional ephemeral port selection algorithm in 4.4BSD implementations. However, if a single global variable is used to keep track of the last ephemeral port selected, ephemeral port numbers become trivially predictable. Section 3.1.2 of this document analyzes a number of approaches for obfuscating the TCP ephemeral ports, such that the chances of an attacker of guessing the ephemeral ports used for future connections are reduced, while still reducing the probability of collisions of connection-id's. Finally, Section 3.1.3 makes recommendations about the port range that should be used for the ephemeral ports. 3.1.2. Port randomization algorithms 3.1.3. TCP ephemeral port range 3.2. Destination port Gont Expires February 20, 2010 [Page 12] Internet-Draft TCP Security Assessment August 2009 3.3. Sequence number 3.3.1. Generation of Initial Sequence Numbers 3.4. Acknowledgement Number 3.5. Data Offset 3.6. Control bits 3.6.1. Reserved (four bits) 3.6.2. CWR (Congestion Window Reduced) 3.6.3. ECE (ECN-Echo) 3.6.4. URG 3.6.5. ACK 3.6.6. PSH 3.6.7. RST [Ramaiah et al, 2008] suggests that implementations should rate-limit the challenge ACK segments sent as a result of implementation of this mechanism. Section 11.1 of this document describes TCP-based connection-reset attacks, along with a number of countermeasures to mitigate their impact. 3.6.8. SYN 3.6.9. FIN 3.7. Window 3.7.1. Security implications of the maximum TCP window size 3.7.2. Security implications arising from closed windows 3.8. Checksum 3.9. Urgent pointer 3.9.1. Security implications arising from ambiguities in the processing of urgent indications Gont Expires February 20, 2010 [Page 13] Internet-Draft TCP Security Assessment August 2009 3.9.2. Security implications arising from the implementation of the urgent mechanism as "out of band" data 3.10. Options 3.11. Padding 3.12. Data 4. Common TCP Options 4.1. End of Option List (Kind = 0) 4.2. No Operation (Kind = 1) 4.3. Maximum Segment Size (Kind = 2) 4.4. Selective Acknowledgement Option 4.4.1. SACK-permitted Option (Kind = 4) 4.4.2. SACK Option (Kind = 5) 4.5. MD5 Option (Kind=19) 4.6. Window scale option (Kind = 3) 4.7. Timestamps option (Kind = 8) 4.7.1. Generation of timestamps 4.7.2. Vulnerabilities 5. Connection-establishment mechanism 5.1. SYN flood 5.2. Connection forgery 5.3. Connection-flooding attack 5.3.1. Vulnerability 5.3.2. Countermeasures Gont Expires February 20, 2010 [Page 14] Internet-Draft TCP Security Assessment August 2009 5.4. Firewall-bypassing techniques 6. Connection-termination mechanism 6.1. FIN-WAIT-2 flooding attack 6.1.1. Vulnerability 6.1.2. Countermeasures 7. Buffer management 7.1. TCP retransmission buffer 7.1.1. Vulnerability 7.1.2. Countermeasures 7.2. TCP segment reassembly buffer 7.3. Automatic buffer tuning mechanisms 7.3.1. Automatic send-buffer tuning mechanisms 7.3.2. Automatic receive-buffer tuning mechanism 8. TCP segment reassembly algorithm 8.1. Problems that arise from ambiguity in the reassembly process 9. TCP Congestion Control 9.1. Congestion control with misbehaving receivers 9.1.1. ACK division 9.1.2. DupACK forgery 9.1.3. Optimistic ACKing 9.2. Blind DupACK triggering attacks against TCP 9.2.1. Blind throughput-reduction attack Gont Expires February 20, 2010 [Page 15] Internet-Draft TCP Security Assessment August 2009 9.2.2. Blind flooding attack 9.2.3. Difficulty in performing the attacks 9.2.4. Modifications to TCP's loss recovery algorithms 9.2.5. Countermeasures 9.3. TCP Explicit Congestion Notification (ECN) 9.3.1. Possible attacks by a compromised router 9.3.2. Possible attacks by a malicious TCP endpoint 10. TCP API 10.1. Passive opens and binding sockets 10.2. Active opens and binding sockets 11. Blind in-window attacks 11.1. Blind TCP-based connection-reset attacks 11.1.1. RST flag 11.1.2. SYN flag 11.1.3. Security/Compartment 11.1.4. Precedence 11.1.5. Illegal options 11.2. Blind data-injection attacks 12. Information leaking 12.1. Remote Operating System detection via TCP/IP stack fingerprinting 12.1.1. FIN probe 12.1.2. Bogus flag test Gont Expires February 20, 2010 [Page 16] Internet-Draft TCP Security Assessment August 2009 12.1.3. TCP ISN sampling 12.1.4. TCP initial window 12.1.5. RST sampling 12.1.6. TCP options 12.1.7. Retransmission Timeout (RTO) sampling 12.2. System uptime detection 13. Covert channels 14. TCP Port scanning 14.1. Traditional connect() scan 14.2. SYN scan 14.3. FIN, NULL, and XMAS scans 14.4. Maimon scan 14.5. Window scan 14.6. ACK scan 15. Processing of ICMP error messages by TCP 16. TCP interaction with the Internet Protocol (IP) 16.1. TCP-based traceroute 16.2. Blind TCP data injection through fragmented IP traffic 16.3. Broadcast and multicast IP addresses 17. Security Considerations Gont Expires February 20, 2010 [Page 17] Internet-Draft TCP Security Assessment August 2009 18. Acknowledgements This document is based on the document "Security Assessment of the Transmission Control Protocol (TCP)" [CPNI, 2009] written by Fernando Gont on behalf of CPNI (Centre for the Protection of National Infrastructure). The author would like to thank (in alphabetical order) Randall Atkinson, Guillermo Gont, Alfred Hoenes, Jamshid Mahdavi, Stanislav Shalunov, Michael Welzl, Dan Wing, Andrew Yourtchenko, Michael Zalewski, and Christos Zoulas, for providing valuable feedback on earlier versions of the UK CPNI document. Additionally, the author would like to thank (in alphabetical order) Mark Allman, David Black, Ethan Blanton, David Borman, James Chacon, John Heffner, Jerrold Leichter, Jamshid Mahdavi, Keith Scott, Bill Squier, and David White, who generously answered a number of questions that araised while the aforementioned document was being written. Finally, the author would like to thank CPNI (formely NISCC) for their continued support. 19. References Abley, J., Savola, P., Neville-Neil, G. 2007. Deprecation of Type 0 Routing Headers in IPv6. RFC 5095. Allman, M. 2003. TCP Congestion Control with Appropriate Byte Counting (ABC). RFC 3465. Allman, M. 2008. Comments On Selecting Ephemeral Ports. Available at: http://www.icir.org/mallman/share/ports-dec08.pdf Allman, M., Paxson, V., Stevens, W. 1999. TCP Congestion Control. RFC 2581. Allman, M., Balakrishnan, H., Floyd, S. 2001. Enhancing TCP's Loss Recovery Using Limited Transmit. RFC 3042. Allman, M., Floyd, S., and C. Partridge. 2002. Increasing TCP's Initial Window. RFC 3390. Baker, F. 1995. Requirements for IP Version 4 Routers. RFC 1812. Baker, F., Savola, P. 2004. Ingress Filtering for Multihomed Networks. RFC 3704. Gont Expires February 20, 2010 [Page 18] Internet-Draft TCP Security Assessment August 2009 Barisani, A. 2006. FTester - Firewall and IDS testing tool. Available at: http://dev.inversepath.com/trac/ftester Beck, R. 2001. Passive-Aggressive Resistance: OS Fingerprint Evasion. Linux Journal. Bellovin, S. M. 1989. Security Problems in the TCP/IP Protocol Suite. Computer Communication Review, Vol. 19, No. 2, pp. 32-48. Bellovin, S. M. 1996. Defending Against Sequence Number Attacks. RFC 1948. Bellovin, S. M. 2006. Towards a TCP Security Option. IETF Internet- Draft (draft-bellovin-tcpsec-00.txt), work in progress. Bernstein, D. J. 1996. SYN cookies. Available at: http://cr.yp.to/syncookies.html Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and Weiss, W., 1998. An Architecture for Differentiated Services. RFC 2475. Blanton, E., Allman, M., Fall, K., Wang, L. 2003. A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP. RFC 3517. Borman, D. 1997. Post to the tcp-impl mailing-list. Message-Id: <199706061526.KAA01535@frantic.BSDI.COM>. Available at: http://www.kohala.com/start/borman.97jun06.txt Borman, D., Deering, S., Hinden, R. 1999. IPv6 Jumbograms. RFC 2675. Braden, R. 1989. Requirements for Internet Hosts -- Communication Layers. RFC 1122. Braden, R. 1992. Extending TCP for Transactions -- Concepts. RFC 1379. Braden, R. 1994. T/TCP -- TCP Extensions for Transactions Functional Specification. RFC 1644. CCSDS. 2006. Consultative Committee for Space Data Systems (CCSDS) Recommendation Communications Protocol Specification (SCPS) -- Transport Protocol (SCPS-TP). Blue Book. Issue 2. Available at: http://public.ccsds.org/publications/archive/714x0b2.pdf CERT. 1996. CERT Advisory CA-1996-21: TCP SYN Flooding and IP Spoofing Attacks. Available at: Gont Expires February 20, 2010 [Page 19] Internet-Draft TCP Security Assessment August 2009 http://www.cert.org/advisories/CA-1996-21.html CERT. 1997. CERT Advisory CA-1997-28 IP Denial-of-Service Attacks. Available at: http://www.cert.org/advisories/CA-1997-28.html CERT. 2000. CERT Advisory CA-2000-21: Denial-of-Service Vulnerabilities in TCP/IP Stacks. Available at: http://www.cert.org/advisories/CA-2000-21.html CERT. 2001. CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence Numbers. Available at: http://www.cert.org/advisories/CA-2001-09.html CERT. 2003. CERT Advisory CA-2003-13 Multiple Vulnerabilities in Snort Preprocessors. Available at: http://www.cert.org/advisories/CA-2003-13.html Cisco. 2008a. Cisco Security Appliance Command Reference, Version 7.0. Available at: http://www.cisco.com/en/US/docs/security/asa/ asa70/command/reference/tz.html#wp1288756 Cisco. 2008b. Cisco Security Appliance System Log Messages, Version 8.0. Available at: http://www.cisco.com/en/US/docs/security/asa/ asa80/system/message/logmsgs.html#wp4773952 Clark, D.D. 1982. Fault isolation and recovery. RFC 816. Clark, D.D. 1988. The Design Philosophy of the DARPA Internet Protocols, Computer Communication Review, Vol. 18, No.4, pp. 106-114. Connolly, T., Amer, P., Conrad, P. 1994. An Extension to TCP : Partial Order Service. RFC 1693. Conta, A., Deering, S., Gupta, M. 2006. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 4443. CORE. 2003. Core Secure Technologies Advisory CORE-2003-0307: Snort TCP Stream Reassembly Integer Overflow Vulnerability. Available at: http://www.coresecurity.com/common/showdoc.php?idx=313&idxseccion=10 CPNI, 2008. Security Assessment of the Internet Protocol. Available at: http://www.cpni.gov.uk/Docs/InternetProtocol.pdf CPNI, 2009. Security Assessment of the Transmission Control Protocol (TCP). Available at: http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf Gont Expires February 20, 2010 [Page 20] Internet-Draft TCP Security Assessment August 2009 daemon9, route, and infinity. 1996. IP-spoofing Demystified (Trust- Relationship Exploitation), Phrack Magazine, Volume Seven, Issue Forty-Eight, File 14 of 18. Available at: http://www.phrack.org/archives/48/P48-14 Deering, S., Hinden, R. 1998. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460. Dharmapurikar, S., Paxson, V. 2005. Robust TCP Stream Reassembly In the Presence of Adversaries. Proceedings of the USENIX Security Symposium 2005. Duke, M., Braden, R., Eddy, W., Blanton, E. 2006. A Roadmap for Transmission Control Protocol (TCP) Specification Documents. RFC 4614. Ed3f. 2002. Firewall spotting and networks analisys with a broken CRC. Phrack Magazine, Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10. Available at: http://www.phrack.org/phrack/60/p60-0x0c.txt Eddy, W. 2007. TCP SYN Flooding Attacks and Common Mitigations. RFC 4987. Fenner, B. 2006. Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. RFC 4727. Ferguson, P., and Senie, D. 2000. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. RFC 2827. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-Lee, T. 1999. Hypertext Transfer Protocol -- HTTP/1.1. RFC 2616. Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. 2000. An Extension to the Selective Acknowledgement (SACK) Option for TCP. RFC 2883. Floyd, S., Henderson, T., Gurtov, A. 2004. The NewReno Modification to TCP's Fast Recovery Algorithm. RFC 3782. Floyd, S., Allman, M., Jain, A., Sarolahti, P. 2007. Quick-Start for TCP and IP. RFC 4782. Fyodor. 1998. Remote OS Detection via TCP/IP Stack Fingerprinting. Phrack Magazine, Volume 8, Issue, 54. Fyodor. 2006a. Remote OS Detection via TCP/IP Fingerprinting (2nd Generation). Available at: http://insecure.org/nmap/osdetect/. Gont Expires February 20, 2010 [Page 21] Internet-Draft TCP Security Assessment August 2009 Fyodor. 2006b. Nmap - Free Security Scanner For Network Exploration and Audit. Available at: http://www.insecure.org/nmap. Fyodor. 2008. Nmap Reference Guide: Port Scanning Techniques. Available at: http://nmap.org/book/man-port-scanning-techniques.html GIAC. 2000. Egress Filtering v 0.2. Available at: http://www.sans.org/y2k/egress.htm Giffin, J., Greenstadt, R., Litwack, P., Tibbetts, R. 2002. Covert Messaging through TCP Timestamps. PET2002 (Workshop on Privacy Enhancing Technologies), San Francisco, CA, USA, April 2002. Available at: http://web.mit.edu/greenie/Public/CovertMessaginginTCP.ps Gill, V., Heasley, J., Meyer, D., Savola, P, Pignataro, C. 2007. The Generalized TTL Security Mechanism (GTSM). RFC 5082. Gont, F. 2006. Advanced ICMP packet filtering. Available at: http://www.gont.com.ar/papers/icmp-filtering.html Gont, F. 2008a. ICMP attacks against TCP. IETF Internet-Draft (draft-ietf-tcpm-icmp-attacks-04.txt), work in progress. Gont, F.. 2008b. TCP's Reaction to Soft Errors. IETF Internet-Draft (draft-ietf-tcpm-tcp-soft-errors-09.txt), work in progress. Gont, F. 2009. On the generation of TCP timestamps. IETF Internet- Draft (draft-gont-tcpm-tcp-timestamps-01.txt), work in progress. Gont, F., Srisuresh, P. 2008. Security Implications of Network Address Translators (NATs). IETF Internet-Draft (draft-gont-behave-nat-security-01.txt), work in progress. Gont, F., Yourtchenko, A. 2009. On the implementation of TCP urgent data. IETF Internet-Draft (draft-gont-tcpm-urgent-data-01.txt), work in progress. Heffernan, A. 1998. Protection of BGP Sessions via the TCP MD5 Signature Option. RFC 2385. Heffner, J. 2002. High Bandwidth TCP Queuing. Senior Thesis. Hoenes, A. 2007. TCP options - tcp-parameters IANA registry. Post to the tcpm wg mailing-list. Available at: http://www.ietf.org/mail-archive/web/tcpm/current/msg03199.html IANA. 2007. Transmission Control Protocol (TCP) Option Numbers. Gont Expires February 20, 2010 [Page 22] Internet-Draft TCP Security Assessment August 2009 Avialable at: http://www.iana.org/assignments/tcp-parameters/ IANA. 2008. Port Numbers. Available at: http://www.iana.org/assignments/port-numbers Jacobson, V. 1988. Congestion Avoidance and Control. Computer Communication Review, vol. 18, no. 4, pp. 314-329. Available at: ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z Jacobson, V., Braden, R. 1988. TCP Extensions for Long-Delay Paths. RFC 1072. Jacobson, V., Braden, R., Borman, D. 1992. TCP Extensions for High Performance. RFC 1323. Jones, S. 2003. Port 0 OS Fingerprinting. Available at: http://www.gont.com.ar/docs/port-0-os-fingerprinting.txt Kent, S. and Seo, K. 2005. Security Architecture for the Internet Protocol. RFC 4301. Klensin, J. 2008. Simple Mail Transfer Protocol. RFC 5321. Ko, Y., Ko, S., and Ko, M. 2001. NIDS Evasion Method named SeolMa. Phrack Magazine, Volume 0x0b, Issue 0x39, phile #0x03 of 0x12. Available at: http://www.phrack.org/issues.html?issue=57&id=3#article Lahey, K. 2000. TCP Problems with Path MTU Discovery. RFC 2923. Larsen, M., Gont, F. 2008. Port Randomization. IETF Internet-Draft (draft-ietf-tsvwg-port-randomization-02), work in progress. Lemon, 2002. Resisting SYN flood DoS attacks with a SYN cache. Proceedings of the BSDCon 2002 Conference, pp 89-98. Maimon, U. 1996. Port Scanning without the SYN flag. Phrack Magazine, Volume Seven, Issue Fourty-Nine, phile #0x0f of 0x10. Available at: http://www.phrack.org/issues.html?issue=49&id=15#article Mathis, M., Mahdavi, J., Floyd, S. Romanow, A. 1996. TCP Selective Acknowledgment Options. RFC 2018. Mathis, M., and Heffner, J. 2007. Packetization Layer Path MTU Discovery. RFC 4821. McCann, J., Deering, S., Mogul, J. 1996. Path MTU Discovery for IP version 6. RFC 1981. Gont Expires February 20, 2010 [Page 23] Internet-Draft TCP Security Assessment August 2009 McKusick, M., Bostic, K., Karels, M., and J. Quarterman. 1996. The Design and Implementation of the 4.4BSD Operating System. Addison- Wesley. Meltman. 1997. new TCP/IP bug in win95. Post to the bugtraq mailing- list. Available at: http://insecure.org/sploits/land.ip.DOS.html Miller, T. 2006. Passive OS Fingerprinting: Details and Techniques. Available at: http://www.ouah.org/incosfingerp.htm . Mogul, J., and Deering, S. 1990. Path MTU Discovery. RFC 1191. Morris, R. 1985. A Weakness in the 4.2BSD Unix TCP/IP Software. Technical Report CSTR-117, AT&T Bell Laboratories. Available at: http://pdos.csail.mit.edu/~rtm/papers/117.pdf . Myst. 1997. Windows 95/NT DoS. Post to the bugtraq mailing-list. Available at: http://seclists.org/bugtraq/1997/May/0039.html Nichols, K., Blake, S., Baker, F., and Black, D. 1998. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474. NISCC. 2004. NISCC Vulnerability Advisory 236929: Vulnerability Issues in TCP. Available at: http://www.uniras.gov.uk/niscc/docs/re-20040420-00391.pdf NISCC. 2005. NISCC Vulnerability Advisory 532967/NISCC/ICMP: Vulnerability Issues in ICMP packets with TCP payloads. Available at: http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf NISCC. 2006. NISCC Technical Note 01/2006: Egress and Ingress Filtering. Available at: http://www.niscc.gov.uk/niscc/docs/re-20060420-00294.pdf?lang=en Ostermann, S. 2008. tcptrace tool. Tool and documentation available at: http://www.tcptrace.org. Paxson, V., Allman, M. 2000. Computing TCP's Retransmission Timer. RFC 2988. PCNWG. 2009. Congestion and Pre-Congestion Notification (pcn) charter. Available at: http://www.ietf.org/html.charters/pcn-charter.html PMTUDWG. 2007. Path MTU Discovery (pmtud) charter. Available at: http://www.ietf.org/html.charters/OLD/pmtud-charter.html Gont Expires February 20, 2010 [Page 24] Internet-Draft TCP Security Assessment August 2009 Postel, J. 1981a. Internet Protocol. DARPA Internet Program. Protocol Specification. RFC 791. Postel, J. 1981b. Internet Control Message Protocol. RFC 792. Postel, J. 1981c. Transmission Control Protocol. DARPA Internet Program. Protocol Specification. RFC 793. Postel, J. 1987. TCP AND IP BAKE OFF. RFC 1025. Ptacek, T. H., and Newsham, T. N. 1998. Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection. Secure Networks, Inc. Available at: http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps Ramaiah, A., Stewart, R., and Dalal, M. 2008. Improving TCP's Robustness to Blind In-Window Attacks. IETF Internet-Draft (draft-ietf-tcpm-tcpsecure-10.txt), work in progress. Ramakrishnan, K., Floyd, S., and Black, D. 2001. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168. Rekhter, Y., Li, T., Hares, S. 2006. A Border Gateway Protocol 4 (BGP-4). RFC 4271. Rivest, R. 1992. The MD5 Message-Digest Algorithm. RFC 1321. Rowland, C. 1997. Covert Channels in the TCP/IP Protocol Suite. First Monday Journal, Volume 2, Number 5. Available at: http://www.firstmonday.org/issues/issue2_5/rowland/ Savage, S., Cardwell, N., Wetherall, D., Anderson, T. 1999. TCP Congestion Control with a Misbehaving Receiver. ACM Computer Communication Review, 29(5), October 1999. Semke, J., Mahdavi, J., Mathis, M. 1998. Automatic TCP Buffer Tuning. ACM Computer Communication Review, Vol. 28, No. 4. Shalunov, S. 2000. Netkill. Available at: http://www.internet2.edu/~shalunov/netkill/netkill.html Shimomura, T. 1995. Technical details of the attack described by Markoff in NYT. Message posted in USENET's comp.security.misc newsgroup, Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>. Available at: http://www.gont.com.ar/docs/post-shimomura-usenet.txt. Silbersack, M. 2005. Improving TCP/IP security through randomization without sacrificing interoperability. EuroBSDCon 2005 Conference. Gont Expires February 20, 2010 [Page 25] Internet-Draft TCP Security Assessment August 2009 SinFP. 2006. Net::SinFP - a Perl module to do OS fingerprinting. Available at: http://www.gomor.org/cgi-bin/index.pl?mode=view;page=sinfp Smart, M., Malan, G., Jahanian, F. 2000. Defeating TCP/IP Stack Fingerprinting. Proceedings of the 9th USENIX Security Symposium, pp. 229-240. Available at: http://www.usenix.org/publications/ library/proceedings/sec2000/full_papers/smart/smart_html/index.html Smith, C., Grundl, P. 2002. Know Your Enemy: Passive Fingerprinting. The Honeynet Project. Spring, N., Wetherall, D., Ely, D. 2003. Robust Explicit Congestion Notification (ECN) Signaling with Nonces. RFC 3540. Srisuresh, P., Egevang, K. 2001. Traditional IP Network Address Translator (Traditional NAT). RFC 3022. Stevens, W. R. 1994. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley Professional Computing Series. TBIT. 2001. TBIT, the TCP Behavior Inference Tool. Available at: http://www.icir.org/tbit/ Touch, J. 2007. Defending TCP Against Spoofing Attacks. RFC 4953. US-CERT. 2001. US-CERT Vulnerability Note VU#498440: Multiple TCP/IP implementations may use statistically predictable initial sequence numbers. Available at: http://www.kb.cert.org/vuls/id/498440 US-CERT. 2003a. US-CERT Vulnerability Note VU#26825: Cisco Secure PIX Firewall TCP Reset Vulnerability. Available at: http://www.kb.cert.org/vuls/id/26825 US-CERT. 2003b. US-CERT Vulnerability Note VU#464113: TCP/IP implementations handle unusual flag combinations inconsistently. Available at: http://www.kb.cert.org/vuls/id/464113 US-CERT. 2004a. US-CERT Vulnerability Note VU#395670: FreeBSD fails to limit number of TCP segments held in reassembly queue. Available at: http://www.kb.cert.org/vuls/id/395670 US-CERT. 2005a. US-CERT Vulnerability Note VU#102014: Optimistic TCP acknowledgements can cause denial of service. Available at: http://www.kb.cert.org/vuls/id/102014 US-CERT. 2005b. US-CERT Vulnerability Note VU#396645: Microsoft Windows vulnerable to DoS via LAND attack. Available at: Gont Expires February 20, 2010 [Page 26] Internet-Draft TCP Security Assessment August 2009 http://www.kb.cert.org/vuls/id/396645 US-CERT. 2005c. US-CERT Vulnerability Note VU#637934: TCP does not adequately validate segments before updating timestamp value. Available at: http://www.kb.cert.org/vuls/id/637934 US-CERT. 2005d. US-CERT Vulnerability Note VU#853540: Cisco PIX fails to verify TCP checksum. Available at: http://www.kb.cert.org/vuls/id/853540. Veysset, F., Courtay, O., Heen, O. 2002. New Tool And Technique For Remote Operating System Fingerprinting. Intranode Research Team. Watson, P. 2004. Slipping in the Window: TCP Reset Attacks, CanSecWest 2004 Conference. Welzl, M. 2008. Internet congestion control: evolution and current open issues. CAIA guest talk, Swinburne University, Melbourne, Australia. Available at: http://www.welzl.at/research/publications/caia-jan08.pdf Wright, G. and W. Stevens. 1994. TCP/IP Illustrated, Volume 2: The Implementation. Addison-Wesley. Zalewski, M. 2001a. Strange Attractors and TCP/IP Sequence Number Analysis. Available at: http://lcamtuf.coredump.cx/oldtcp/tcpseq.html Zalewski, M. 2001b. Delivering Signals for Fun and Profit. Available at: http://lcamtuf.coredump.cx/signals.txt Zalewski, M. 2002. Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later. Available at: http://lcamtuf.coredump.cx/newtcp/ Zalewski, M. 2003a. Windows URG mystery solved! Post to the bugtraq mailing-list. Available at: http://lcamtuf.coredump.cx/p0f-help/p0f/doc/win-memleak.txt Zalewski, M. 2003b. A new TCP/IP blind data injection technique? Post to the bugtraq mailing-list. Available at: http://lcamtuf.coredump.cx/ipfrag.txt Zalewski, M. 2006a. p0f passive fingerprinting tool. Available at: http://lcamtuf.coredump.cx/p0f.shtml Zalewski, M. 2006b. p0f - RST+ signatures. Available at: http://lcamtuf.coredump.cx/p0f-help/p0f/p0fr.fp Gont Expires February 20, 2010 [Page 27] Internet-Draft TCP Security Assessment August 2009 Zalewski, M. 2007. 0trace - traceroute on established connections. Post to the bugtraq mailing-list. Available at: http://seclists.org/bugtraq/2007/Jan/0176.html Zalewski, M. 2008. Museum of broken packets. Available at: http://lcamtuf.coredump.cx/mobp/ Zander, S. 2008. Covert Channels in Computer Networks. Available at: http://caia.swin.edu.au/cv/szander/cc/index.html Zuquete, A. 2002. Improving the functionality of SYN cookies. 6th IFIP Communications and Multimedia Security Conference (CMS 2002). Available at: http://www.ieeta.pt/~avz/pubs/CMS02.html Zweig, J., Partridge, C. 1990. TCP Alternate Checksum Options. RFC 1146. Appendix A. Changes from previous versions of the draft (to be removed by the RFC Editor before publishing this document as an RFC) A.1. Changes from draft-gont-tcp-security-00 o Draft resubmitted as draft-ietf (boilerplate updated as required). Appendix B. Advice and guidance to vendors Vendors are urged to contact CSIRTUK (csirt@cpni.gsi.gov.uk) if they think they may be affected by the issues described in this document. As the lead coordination center for these issues, CPNI is well placed to give advice and guidance as required. CPNI works extensively with government departments and agencies, commercial organizations and the academic community to research vulnerabilities and potential threats to IT systems especially where they may have an impact on Critical National Infrastructure's (CNI). Other ways to contact CPNI, plus CPNI's PGP public key, are available at http://www.cpni.gov.uk/ . Gont Expires February 20, 2010 [Page 28] Internet-Draft TCP Security Assessment August 2009 Author's Address Fernando Gont UK Centre for the Protection of National Infrastructure Email: fernando@gont.com.ar URI: http://www.cpni.gov.uk Gont Expires February 20, 2010 [Page 29]