--- 1/draft-ietf-tcpm-tcp-security-00.txt 2010-02-20 01:10:39.000000000 +0100 +++ 2/draft-ietf-tcpm-tcp-security-01.txt 2010-02-20 01:10:39.000000000 +0100 @@ -1,19 +1,27 @@ TCP Maintenance and Minor F. Gont Extensions (tcpm) UK CPNI -Internet-Draft August 19, 2009 +Internet-Draft February 19, 2010 Intended status: BCP -Expires: February 20, 2010 +Expires: August 23, 2010 Security Assessment of the Transmission Control Protocol (TCP) - draft-ietf-tcpm-tcp-security-00.txt + draft-ietf-tcpm-tcp-security-01.txt + +Abstract + + This document contains a security assessment of the specifications of + the Transmission Control Protocol (TCP), and of a number of + mechanisms and policies in use by popular TCP implementations. + Additionally, it contains best current practices for hardening a TCP + implementation. 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. @@ -22,175 +30,174 @@ 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. + This Internet-Draft will expire on August 23, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 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 - mechanisms and policies in use by popular TCP implementations. - Additionally, it contains best current practices for hardening a TCP - implementation. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. 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 + 3.1. Source Port and Destination Port . . . . . . . . . . . . . 9 + 3.1.1. REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . 9 + 3.1.2. DISCUSSION . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1.2.1. Problematic port numbers . . . . . . . . . . . . . 10 + 3.1.2.2. Ephemeral ports . . . . . . . . . . . . . . . . . 11 + 3.1.2.3. Collision of connection-id's . . . . . . . . . . . 12 + 3.2. Sequence number . . . . . . . . . . . . . . . . . . . . . 13 + 3.2.1. Generation of Initial Sequence Numbers . . . . . . . . 13 + 3.3. Acknowledgement Number . . . . . . . . . . . . . . . . . . 13 + 3.4. Data Offset . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.5. Control bits . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.5.1. Reserved (four bits) . . . . . . . . . . . . . . . . . 13 + 3.5.2. CWR (Congestion Window Reduced) . . . . . . . . . . . 13 + 3.5.3. ECE (ECN-Echo) . . . . . . . . . . . . . . . . . . . . 13 + 3.5.4. URG . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.5.5. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.5.6. PSH . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.5.7. RST . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.5.8. SYN . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.5.9. FIN . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.6. Window . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.6.1. Security implications of the maximum TCP window + size . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.6.2. Security implications arising from closed windows . . 14 + 3.7. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.8. Urgent pointer . . . . . . . . . . . . . . . . . . . . . . 14 + 3.8.1. Security implications arising from ambiguities in the processing of urgent indications . . . . . . . . . 14 - 3.9.2. Security implications arising from the + 3.8.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 + + 3.9. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.10. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.11. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Common TCP Options . . . . . . . . . . . . . . . . . . . . . . 14 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 + 4.4. Selective Acknowledgement Option . . . . . . . . . . . . . 15 + 4.4.1. SACK-permitted Option (Kind = 4) . . . . . . . . . . . 15 + 4.4.2. SACK Option (Kind = 5) . . . . . . . . . . . . . . . . 15 + 4.5. MD5 Option (Kind=19) . . . . . . . . . . . . . . . . . . . 15 + 4.6. Window scale option (Kind = 3) . . . . . . . . . . . . . . 15 + 4.7. Timestamps option (Kind = 8) . . . . . . . . . . . . . . . 15 + 4.7.1. Generation of timestamps . . . . . . . . . . . . . . . 15 + 4.7.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . 15 + 5. Connection-establishment mechanism . . . . . . . . . . . . . . 15 + 5.1. SYN flood . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.2. Connection forgery . . . . . . . . . . . . . . . . . . . . 15 + 5.3. Connection-flooding attack . . . . . . . . . . . . . . . . 15 + 5.3.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15 + 5.3.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 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 + 7.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 16 + 7.2. TCP segment reassembly buffer . . . . . . . . . . . . . . 16 + 7.3. Automatic buffer tuning mechanisms . . . . . . . . . . . . 16 + 7.3.1. Automatic send-buffer tuning mechanisms . . . . . . . 16 + 7.3.2. Automatic receive-buffer tuning mechanism . . . . . . 16 + 8. TCP segment reassembly algorithm . . . . . . . . . . . . . . . 16 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 + process . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Congestion control with misbehaving receivers . . . . . . 16 + 9.1.1. ACK division . . . . . . . . . . . . . . . . . . . . . 16 + 9.1.2. DupACK forgery . . . . . . . . . . . . . . . . . . . . 16 + 9.1.3. Optimistic ACKing . . . . . . . . . . . . . . . . . . 16 + 9.2. Blind DupACK triggering attacks against TCP . . . . . . . 16 + 9.2.1. Blind throughput-reduction attack . . . . . . . . . . 16 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 - 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 + 10.1. Passive opens and binding sockets . . . . . . . . . . . . 17 + 10.2. Active opens and binding sockets . . . . . . . . . . . . . 17 + 11. Blind in-window attacks . . . . . . . . . . . . . . . . . . . 17 + 11.1. Blind TCP-based connection-reset attacks . . . . . . . . . 17 + 11.1.1. RST flag . . . . . . . . . . . . . . . . . . . . . . . 17 + 11.1.2. SYN flag . . . . . . . . . . . . . . . . . . . . . . . 17 + 11.1.3. Security/Compartment . . . . . . . . . . . . . . . . . 17 + 11.1.4. Precedence . . . . . . . . . . . . . . . . . . . . . . 17 + 11.1.5. Illegal options . . . . . . . . . . . . . . . . . . . 17 + 11.2. Blind data-injection attacks . . . . . . . . . . . . . . . 17 + 12. Information leaking . . . . . . . . . . . . . . . . . . . . . 17 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 + fingerprinting . . . . . . . . . . . . . . . . . . . . . . 17 + 12.1.1. FIN probe . . . . . . . . . . . . . . . . . . . . . . 17 + 12.1.2. Bogus flag test . . . . . . . . . . . . . . . . . . . 17 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 + 14. TCP Port scanning . . . . . . . . . . . . . . . . . . . . . . 18 + 14.1. Traditional connect() scan . . . . . . . . . . . . . . . . 18 + 14.2. SYN scan . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 14.3. FIN, NULL, and XMAS scans . . . . . . . . . . . . . . . . 18 + 14.4. Maimon scan . . . . . . . . . . . . . . . . . . . . . . . 18 + 14.5. Window scan . . . . . . . . . . . . . . . . . . . . . . . 18 + 14.6. ACK scan . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 15. Processing of ICMP error messages by TCP . . . . . . . . . . . 18 + 16. TCP interaction with the Internet Protocol (IP) . . . . . . . 18 + 16.1. TCP-based traceroute . . . . . . . . . . . . . . . . . . . 18 + 16.2. Blind TCP data injection through fragmented IP traffic . . 18 + 16.3. Broadcast and multicast IP addresses . . . . . . . . . . . 18 + 17. Security Considerations . . . . . . . . . . . . . . . . . . . 18 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 19. References-old . . . . . . . . . . . . . . . . . . . . . . . . 19 + 20. Normative References . . . . . . . . . . . . . . . . . . . . . 29 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 + this document as an RFC) . . . . . . . . . . . . . . 29 + A.1. Changes from draft-gont-tcp-security-00 . . . . . . . . . 29 + Appendix B. Advice and guidance to vendors . . . . . . . . . . . 29 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 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. @@ -404,67 +411,75 @@ 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. + If a segment does not pass this check, it MUST be dropped. The following subsections contain further sanity checks that should be performed on TCP segments. -3.1. Source Port +3.1. Source Port and Destination 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. +3.1.1. REQUIREMENTS - The Internet Assigned Numbers Authority (IANA) has traditionally - reserved the following use of the 16-bit port range of TCP [IANA, - 2008]: + TCP SHOULD randomize its ephemeral (client-side) ports, to improve + its resistance to off-path attacks. For the purpose of ephemeral + port selection, the largest posible port range SHOULD be used + (ideally 1024-65535) [I-D.ietf-tsvwg-port-randomization]. - o The Well Known Ports, 0 through 1023 + TCP MUST NOT allocate port number 0, as its use could lead to + interoperability problems. If a segment is received with port 0 as + the Source Port or the Destination Port, a RST segment SHOULD be sent + in response (provided that the incomming segment does not have the + RST flag set). - o The Registered Ports, 1024 through 49151 + TCP MUST be able to grecefully handle the case where the source end- + point (IP Source Address, TCP Source Port) is the same as the + destination end-point (IP Destination Address, TCP Destination Port). - o The Dynamic and/or Private Ports, 49152 through 65535 + TCP SHOULD NOT allocate 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 + could allow attackers on the local system to "steal" incomming TCP + connections. - 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. + While some systems restrict use of the port numbers in the range + 0-1024 to privileged users, applications SHOULD NOT grant any trust + based on the port numbers used for a TCP connection. + + Middle-boxes such as packet filters MUST NOT assume that clients use + port numbers from only the Dynamic or Registered port ranges. + +3.1.2. DISCUSSION + + The Source Port field contains a 16-bit number that identifies the + TCP end-point that originated this TCP segment. The TCP Destination + Port contains a 16-bit number that identifies the destination TCP + end-point of this segment. 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. + In most of the discussion we refer to client-side (or "ephemeral") + port-numbers and server-side port numbers, since that distinction is + what usually affects the interpretation of a port number. - 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. +3.1.2.1. Problematic port numbers 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 @@ -473,45 +488,92 @@ fingerprinting [Jones, 2003]. 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). + TCP segments that have a Source Port or a Destination 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). + Some systems have been found to be unable to process TCP segments in + which the source endpoint {Source Address, Source Port} is the same + than the destination end-point {Destination Address, Destination + Port}. Such TCP segments have been reported to cause malfunction of + a number of implementations [CERT, 1996], and have been exploited in + the past to perform Denial of Service (DoS) attacks [Meltman, 1997]. + While these packets are very very unlikely to exist in real and + legitimate scenarios, TCP should nevertheless be able to process them + without the need of any "extra" code. -3.1.1. Problems that may arise as a result of collisions of connection- - id's + A SYN segment in which the source end-point {Source Address, Source + Port} is the same as the destination end-point {Destination Address, + Destination Port} will result in a "simultaneous open" scenario, such + as the one described in page 32 of RFC 793 [Postel, 1981c]. + Therefore, those TCP implementations that correctly handle + simultaneous opens should already be prepared to handle these unusual + TCP segments. + +3.1.2.2. Ephemeral ports + + Since most "blind" attacks against TCP require the attacker to guess + or know the four-tuple that identifies the TCP connection to be + attacked [Gont, 2008a] [Touch, 2007] [Watson, 2004], obfuscation of + this four-tuple to an off-path attacker requires, in a number of + scenarios, much more work on the side of the attacker to successfully + perform any of these attacks against a TCP connection. Therefore, we + RECOMMEND that TCP implementations randomize their ephemeral ports. + For the purpose of ephemeral port selection, the largest posible port + range SHOULD be used (ideally 1024-65535) + [I-D.ietf-tsvwg-port-randomization], since this increases the + obfuscation. [I-D.ietf-tsvwg-port-randomization] provides advice on + ephemeral port randomization. + + While the only requirement for a selected ephemeral port is that + the resulting four-tuple (connection-id) is unique (i.e., not + currently in use by any other TCP connection), 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. Therefore, + TCP SHOULD NOT allocate port numbers that are in use by a TCP in + the LISTEN or CLOSED states for use as ephemeral ports. 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 MUST NOT assume + that clients use port number from only the Dynamic or Registered + port ranges. + +3.1.2.3. Collision 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]. + 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: @@ -523,121 +585,93 @@ 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 + Section 3.2.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 -3.3. Sequence number + connection-id's. -3.3.1. Generation of Initial Sequence Numbers +3.2. Sequence number -3.4. Acknowledgement Number +3.2.1. Generation of Initial Sequence Numbers -3.5. Data Offset +3.3. Acknowledgement Number -3.6. Control bits +3.4. Data Offset -3.6.1. Reserved (four bits) +3.5. Control bits -3.6.2. CWR (Congestion Window Reduced) +3.5.1. Reserved (four bits) -3.6.3. ECE (ECN-Echo) +3.5.2. CWR (Congestion Window Reduced) -3.6.4. URG +3.5.3. ECE (ECN-Echo) -3.6.5. ACK +3.5.4. URG -3.6.6. PSH +3.5.5. ACK +3.5.6. PSH -3.6.7. RST +3.5.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.5.8. SYN -3.6.9. FIN +3.5.9. FIN -3.7. Window +3.6. Window -3.7.1. Security implications of the maximum TCP window size +3.6.1. Security implications of the maximum TCP window size -3.7.2. Security implications arising from closed windows +3.6.2. Security implications arising from closed windows -3.8. Checksum +3.7. Checksum -3.9. Urgent pointer +3.8. Urgent pointer -3.9.1. Security implications arising from ambiguities in the processing +3.8.1. Security implications arising from ambiguities in the processing of urgent indications -3.9.2. Security implications arising from the implementation of the +3.8.2. Security implications arising from the implementation of the urgent mechanism as "out of band" data -3.10. Options +3.9. Options -3.11. Padding +3.10. Padding -3.12. Data +3.11. 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) @@ -799,21 +834,21 @@ 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 +19. References-old 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 @@ -1277,20 +1312,31 @@ 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. +20. Normative References + + [I-D.ietf-tsvwg-port-randomization] + Larsen, M. and F. Gont, "Transport Protocol Port + Randomization Recommendations", + draft-ietf-tsvwg-port-randomization-06 (work in progress), + February 2010. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + 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