draft-ietf-tcpm-tcp-security-00.txt   draft-ietf-tcpm-tcp-security-01.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UK CPNI Extensions (tcpm) UK CPNI
Internet-Draft August 19, 2009 Internet-Draft February 19, 2010
Intended status: BCP Intended status: BCP
Expires: February 20, 2010 Expires: August 23, 2010
Security Assessment of the Transmission Control Protocol (TCP) 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document contains a security assessment of the specifications of described in the BSD License.
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.
Table of Contents Table of Contents
1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6
1.3. Organization of this document . . . . . . . . . . . . . . 7 1.3. Organization of this document . . . . . . . . . . . . . . 7
2. The Transmission Control Protocol . . . . . . . . . . . . . . 7 2. The Transmission Control Protocol . . . . . . . . . . . . . . 7
3. TCP header fields . . . . . . . . . . . . . . . . . . . . . . 8 3. TCP header fields . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Source Port . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Source Port and Destination Port . . . . . . . . . . . . . 9
3.1.1. Problems that may arise as a result of collisions 3.1.1. REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . 9
of connection-id's . . . . . . . . . . . . . . . . . . 11 3.1.2. DISCUSSION . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Port randomization algorithms . . . . . . . . . . . . 12 3.1.2.1. Problematic port numbers . . . . . . . . . . . . . 10
3.1.3. TCP ephemeral port range . . . . . . . . . . . . . . . 12 3.1.2.2. Ephemeral ports . . . . . . . . . . . . . . . . . 11
3.2. Destination port . . . . . . . . . . . . . . . . . . . . . 12 3.1.2.3. Collision of connection-id's . . . . . . . . . . . 12
3.3. Sequence number . . . . . . . . . . . . . . . . . . . . . 13 3.2. Sequence number . . . . . . . . . . . . . . . . . . . . . 13
3.3.1. Generation of Initial Sequence Numbers . . . . . . . . 13 3.2.1. Generation of Initial Sequence Numbers . . . . . . . . 13
3.4. Acknowledgement Number . . . . . . . . . . . . . . . . . . 13 3.3. Acknowledgement Number . . . . . . . . . . . . . . . . . . 13
3.5. Data Offset . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Data Offset . . . . . . . . . . . . . . . . . . . . . . . 13
3.6. Control bits . . . . . . . . . . . . . . . . . . . . . . . 13 3.5. Control bits . . . . . . . . . . . . . . . . . . . . . . . 13
3.6.1. Reserved (four bits) . . . . . . . . . . . . . . . . . 13 3.5.1. Reserved (four bits) . . . . . . . . . . . . . . . . . 13
3.6.2. CWR (Congestion Window Reduced) . . . . . . . . . . . 13 3.5.2. CWR (Congestion Window Reduced) . . . . . . . . . . . 13
3.6.3. ECE (ECN-Echo) . . . . . . . . . . . . . . . . . . . . 13 3.5.3. ECE (ECN-Echo) . . . . . . . . . . . . . . . . . . . . 13
3.6.4. URG . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.4. URG . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6.5. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.5. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6.6. PSH . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.6. PSH . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6.7. RST . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.7. RST . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6.8. SYN . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.8. SYN . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6.9. FIN . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.9. FIN . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7. Window . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6. Window . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7.1. Security implications of the maximum TCP window 3.6.1. Security implications of the maximum TCP window
size . . . . . . . . . . . . . . . . . . . . . . . . . 13 size . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7.2. Security implications arising from closed windows . . 13 3.6.2. Security implications arising from closed windows . . 14
3.8. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.9. Urgent pointer . . . . . . . . . . . . . . . . . . . . . . 13 3.8. Urgent pointer . . . . . . . . . . . . . . . . . . . . . . 14
3.9.1. Security implications arising from ambiguities in 3.8.1. Security implications arising from ambiguities in
the processing of urgent indications . . . . . . . . . 14 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 implementation of the urgent mechanism as "out of
band" data . . . . . . . . . . . . . . . . . . . . . . 14 band" data . . . . . . . . . . . . . . . . . . . . . . 14
3.10. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.11. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.9. Options . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.12. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.10. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.11. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Common TCP Options . . . . . . . . . . . . . . . . . . . . . . 14 4. Common TCP Options . . . . . . . . . . . . . . . . . . . . . . 14
4.1. End of Option List (Kind = 0) . . . . . . . . . . . . . . 14 4.1. End of Option List (Kind = 0) . . . . . . . . . . . . . . 14
4.2. No Operation (Kind = 1) . . . . . . . . . . . . . . . . . 14 4.2. No Operation (Kind = 1) . . . . . . . . . . . . . . . . . 14
4.3. Maximum Segment Size (Kind = 2) . . . . . . . . . . . . . 14 4.3. Maximum Segment Size (Kind = 2) . . . . . . . . . . . . . 14
4.4. Selective Acknowledgement Option . . . . . . . . . . . . . 14 4.4. Selective Acknowledgement Option . . . . . . . . . . . . . 15
4.4.1. SACK-permitted Option (Kind = 4) . . . . . . . . . . . 14 4.4.1. SACK-permitted Option (Kind = 4) . . . . . . . . . . . 15
4.4.2. SACK Option (Kind = 5) . . . . . . . . . . . . . . . . 14 4.4.2. SACK Option (Kind = 5) . . . . . . . . . . . . . . . . 15
4.5. MD5 Option (Kind=19) . . . . . . . . . . . . . . . . . . . 14 4.5. MD5 Option (Kind=19) . . . . . . . . . . . . . . . . . . . 15
4.6. Window scale option (Kind = 3) . . . . . . . . . . . . . . 14 4.6. Window scale option (Kind = 3) . . . . . . . . . . . . . . 15
4.7. Timestamps option (Kind = 8) . . . . . . . . . . . . . . . 14 4.7. Timestamps option (Kind = 8) . . . . . . . . . . . . . . . 15
4.7.1. Generation of timestamps . . . . . . . . . . . . . . . 14 4.7.1. Generation of timestamps . . . . . . . . . . . . . . . 15
4.7.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . 14 4.7.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . 15
5. Connection-establishment mechanism . . . . . . . . . . . . . . 14 5. Connection-establishment mechanism . . . . . . . . . . . . . . 15
5.1. SYN flood . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. SYN flood . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Connection forgery . . . . . . . . . . . . . . . . . . . . 14 5.2. Connection forgery . . . . . . . . . . . . . . . . . . . . 15
5.3. Connection-flooding attack . . . . . . . . . . . . . . . . 14 5.3. Connection-flooding attack . . . . . . . . . . . . . . . . 15
5.3.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 14 5.3.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15
5.3.2. Countermeasures . . . . . . . . . . . . . . . . . . . 14 5.3.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15
5.4. Firewall-bypassing techniques . . . . . . . . . . . . . . 15 5.4. Firewall-bypassing techniques . . . . . . . . . . . . . . 15
6. Connection-termination mechanism . . . . . . . . . . . . . . . 15 6. Connection-termination mechanism . . . . . . . . . . . . . . . 15
6.1. FIN-WAIT-2 flooding attack . . . . . . . . . . . . . . . . 15 6.1. FIN-WAIT-2 flooding attack . . . . . . . . . . . . . . . . 15
6.1.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15 6.1.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15
6.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 6.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15
7. Buffer management . . . . . . . . . . . . . . . . . . . . . . 15 7. Buffer management . . . . . . . . . . . . . . . . . . . . . . 15
7.1. TCP retransmission buffer . . . . . . . . . . . . . . . . 15 7.1. TCP retransmission buffer . . . . . . . . . . . . . . . . 15
7.1.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15 7.1.1. Vulnerability . . . . . . . . . . . . . . . . . . . . 15
7.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 7.1.2. Countermeasures . . . . . . . . . . . . . . . . . . . 16
7.2. TCP segment reassembly buffer . . . . . . . . . . . . . . 15 7.2. TCP segment reassembly buffer . . . . . . . . . . . . . . 16
7.3. Automatic buffer tuning mechanisms . . . . . . . . . . . . 15 7.3. Automatic buffer tuning mechanisms . . . . . . . . . . . . 16
7.3.1. Automatic send-buffer tuning mechanisms . . . . . . . 15 7.3.1. Automatic send-buffer tuning mechanisms . . . . . . . 16
7.3.2. Automatic receive-buffer tuning mechanism . . . . . . 15 7.3.2. Automatic receive-buffer tuning mechanism . . . . . . 16
8. TCP segment reassembly algorithm . . . . . . . . . . . . . . . 15 8. TCP segment reassembly algorithm . . . . . . . . . . . . . . . 16
8.1. Problems that arise from ambiguity in the reassembly 8.1. Problems that arise from ambiguity in the reassembly
process . . . . . . . . . . . . . . . . . . . . . . . . . 15 process . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 15 9. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 16
9.1. Congestion control with misbehaving receivers . . . . . . 15 9.1. Congestion control with misbehaving receivers . . . . . . 16
9.1.1. ACK division . . . . . . . . . . . . . . . . . . . . . 15 9.1.1. ACK division . . . . . . . . . . . . . . . . . . . . . 16
9.1.2. DupACK forgery . . . . . . . . . . . . . . . . . . . . 15 9.1.2. DupACK forgery . . . . . . . . . . . . . . . . . . . . 16
9.1.3. Optimistic ACKing . . . . . . . . . . . . . . . . . . 15 9.1.3. Optimistic ACKing . . . . . . . . . . . . . . . . . . 16
9.2. Blind DupACK triggering attacks against TCP . . . . . . . 15 9.2. Blind DupACK triggering attacks against TCP . . . . . . . 16
9.2.1. Blind throughput-reduction attack . . . . . . . . . . 15 9.2.1. Blind throughput-reduction attack . . . . . . . . . . 16
9.2.2. Blind flooding attack . . . . . . . . . . . . . . . . 16 9.2.2. Blind flooding attack . . . . . . . . . . . . . . . . 16
9.2.3. Difficulty in performing the attacks . . . . . . . . . 16 9.2.3. Difficulty in performing the attacks . . . . . . . . . 16
9.2.4. Modifications to TCP's loss recovery algorithms . . . 16 9.2.4. Modifications to TCP's loss recovery algorithms . . . 16
9.2.5. Countermeasures . . . . . . . . . . . . . . . . . . . 16 9.2.5. Countermeasures . . . . . . . . . . . . . . . . . . . 16
9.3. TCP Explicit Congestion Notification (ECN) . . . . . . . . 16 9.3. TCP Explicit Congestion Notification (ECN) . . . . . . . . 16
9.3.1. Possible attacks by a compromised router . . . . . . . 16 9.3.1. Possible attacks by a compromised router . . . . . . . 16
9.3.2. Possible attacks by a malicious TCP endpoint . . . . . 16 9.3.2. Possible attacks by a malicious TCP endpoint . . . . . 16
10. TCP API . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. TCP API . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Passive opens and binding sockets . . . . . . . . . . . . 16 10.1. Passive opens and binding sockets . . . . . . . . . . . . 17
10.2. Active opens and binding sockets . . . . . . . . . . . . . 16 10.2. Active opens and binding sockets . . . . . . . . . . . . . 17
11. Blind in-window attacks . . . . . . . . . . . . . . . . . . . 16 11. Blind in-window attacks . . . . . . . . . . . . . . . . . . . 17
11.1. Blind TCP-based connection-reset attacks . . . . . . . . . 16 11.1. Blind TCP-based connection-reset attacks . . . . . . . . . 17
11.1.1. RST flag . . . . . . . . . . . . . . . . . . . . . . . 16 11.1.1. RST flag . . . . . . . . . . . . . . . . . . . . . . . 17
11.1.2. SYN flag . . . . . . . . . . . . . . . . . . . . . . . 16 11.1.2. SYN flag . . . . . . . . . . . . . . . . . . . . . . . 17
11.1.3. Security/Compartment . . . . . . . . . . . . . . . . . 16 11.1.3. Security/Compartment . . . . . . . . . . . . . . . . . 17
11.1.4. Precedence . . . . . . . . . . . . . . . . . . . . . . 16 11.1.4. Precedence . . . . . . . . . . . . . . . . . . . . . . 17
11.1.5. Illegal options . . . . . . . . . . . . . . . . . . . 16 11.1.5. Illegal options . . . . . . . . . . . . . . . . . . . 17
11.2. Blind data-injection attacks . . . . . . . . . . . . . . . 16 11.2. Blind data-injection attacks . . . . . . . . . . . . . . . 17
12. Information leaking . . . . . . . . . . . . . . . . . . . . . 16 12. Information leaking . . . . . . . . . . . . . . . . . . . . . 17
12.1. Remote Operating System detection via TCP/IP stack 12.1. Remote Operating System detection via TCP/IP stack
fingerprinting . . . . . . . . . . . . . . . . . . . . . . 16 fingerprinting . . . . . . . . . . . . . . . . . . . . . . 17
12.1.1. FIN probe . . . . . . . . . . . . . . . . . . . . . . 16 12.1.1. FIN probe . . . . . . . . . . . . . . . . . . . . . . 17
12.1.2. Bogus flag test . . . . . . . . . . . . . . . . . . . 16 12.1.2. Bogus flag test . . . . . . . . . . . . . . . . . . . 17
12.1.3. TCP ISN sampling . . . . . . . . . . . . . . . . . . . 17 12.1.3. TCP ISN sampling . . . . . . . . . . . . . . . . . . . 17
12.1.4. TCP initial window . . . . . . . . . . . . . . . . . . 17 12.1.4. TCP initial window . . . . . . . . . . . . . . . . . . 17
12.1.5. RST sampling . . . . . . . . . . . . . . . . . . . . . 17 12.1.5. RST sampling . . . . . . . . . . . . . . . . . . . . . 17
12.1.6. TCP options . . . . . . . . . . . . . . . . . . . . . 17 12.1.6. TCP options . . . . . . . . . . . . . . . . . . . . . 17
12.1.7. Retransmission Timeout (RTO) sampling . . . . . . . . 17 12.1.7. Retransmission Timeout (RTO) sampling . . . . . . . . 17
12.2. System uptime detection . . . . . . . . . . . . . . . . . 17 12.2. System uptime detection . . . . . . . . . . . . . . . . . 17
13. Covert channels . . . . . . . . . . . . . . . . . . . . . . . 17 13. Covert channels . . . . . . . . . . . . . . . . . . . . . . . 17
14. TCP Port scanning . . . . . . . . . . . . . . . . . . . . . . 17 14. TCP Port scanning . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Traditional connect() scan . . . . . . . . . . . . . . . . 17 14.1. Traditional connect() scan . . . . . . . . . . . . . . . . 18
14.2. SYN scan . . . . . . . . . . . . . . . . . . . . . . . . . 17 14.2. SYN scan . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.3. FIN, NULL, and XMAS scans . . . . . . . . . . . . . . . . 17 14.3. FIN, NULL, and XMAS scans . . . . . . . . . . . . . . . . 18
14.4. Maimon scan . . . . . . . . . . . . . . . . . . . . . . . 17 14.4. Maimon scan . . . . . . . . . . . . . . . . . . . . . . . 18
14.5. Window scan . . . . . . . . . . . . . . . . . . . . . . . 17 14.5. Window scan . . . . . . . . . . . . . . . . . . . . . . . 18
14.6. ACK scan . . . . . . . . . . . . . . . . . . . . . . . . . 17 14.6. ACK scan . . . . . . . . . . . . . . . . . . . . . . . . . 18
15. Processing of ICMP error messages by TCP . . . . . . . . . . . 17 15. Processing of ICMP error messages by TCP . . . . . . . . . . . 18
16. TCP interaction with the Internet Protocol (IP) . . . . . . . 17 16. TCP interaction with the Internet Protocol (IP) . . . . . . . 18
16.1. TCP-based traceroute . . . . . . . . . . . . . . . . . . . 17 16.1. TCP-based traceroute . . . . . . . . . . . . . . . . . . . 18
16.2. Blind TCP data injection through fragmented IP traffic . . 17 16.2. Blind TCP data injection through fragmented IP traffic . . 18
16.3. Broadcast and multicast IP addresses . . . . . . . . . . . 17 16.3. Broadcast and multicast IP addresses . . . . . . . . . . . 18
17. Security Considerations . . . . . . . . . . . . . . . . . . . 17 17. Security Considerations . . . . . . . . . . . . . . . . . . . 18
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 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 Appendix A. Changes from previous versions of the draft (to
be removed by the RFC Editor before publishing be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . 28 this document as an RFC) . . . . . . . . . . . . . . 29
A.1. Changes from draft-gont-tcp-security-00 . . . . . . . . . 28 A.1. Changes from draft-gont-tcp-security-00 . . . . . . . . . 29
Appendix B. Advice and guidance to vendors . . . . . . . . . . . 28 Appendix B. Advice and guidance to vendors . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Preface 1. Preface
1.1. Introduction 1.1. Introduction
The TCP/IP protocol suite was conceived in an environment that was The TCP/IP protocol suite was conceived in an environment that was
quite different from the hostile environment they currently operate quite different from the hostile environment they currently operate
in. However, the effectiveness of the protocols led to their early in. However, the effectiveness of the protocols led to their early
adoption in production environments, to the point that, to some adoption in production environments, to the point that, to some
extent, the current world's economy depends on them. extent, the current world's economy depends on them.
skipping to change at page 9, line 37 skipping to change at page 9, line 37
Figure 2: Transmission Control Protocol header format Figure 2: Transmission Control Protocol header format
The minimum TCP header size is 20 bytes, and corresponds to a TCP 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 segment with no options and no data. However, a TCP module might be
handed an (illegitimate) "TCP segment" of less than 20 bytes. handed an (illegitimate) "TCP segment" of less than 20 bytes.
Therefore, before doing any processing of the TCP header fields, the Therefore, before doing any processing of the TCP header fields, the
following check should be performed by TCP on the segments handed by following check should be performed by TCP on the segments handed by
the internet layer: the internet layer:
Segment.Size >= 20 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 The following subsections contain further sanity checks that should
be performed on TCP segments. 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 3.1.1. REQUIREMENTS
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 TCP SHOULD randomize its ephemeral (client-side) ports, to improve
reserved the following use of the 16-bit port range of TCP [IANA, its resistance to off-path attacks. For the purpose of ephemeral
2008]: 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 While some systems restrict use of the port numbers in the range
remainder being registered by IANA but not assigned [IANA, 2008]. It 0-1024 to privileged users, applications SHOULD NOT grant any trust
is also worth noting that, while some systems restrict use of the based on the port numbers used for a TCP connection.
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. 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 Servers usually bind specific ports on which specific services are
usually provided, while clients usually make use of the so-called usually provided, while clients usually make use of the so-called
"ephemeral ports" for the source port of their outgoing connections "ephemeral ports" for the source port of their outgoing connections
with the only requirement that the resulting four-tuple must be with the only requirement that the resulting four-tuple must be
unique (not currently in use by any other transport protocol unique (not currently in use by any other transport protocol
instance). instance).
While the only requirement for a selected ephemeral port is that the In most of the discussion we refer to client-side (or "ephemeral")
resulting four-tuple (connection-id) is unique, in practice it may be port-numbers and server-side port numbers, since that distinction is
necessary to not allow the allocation of port numbers that are in use what usually affects the interpretation of a port number.
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 3.1.2.1. Problematic port numbers
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 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 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 passed as an argument to the bind() function, rather than binding
port 0, an ephemeral port is selected for the corresponding TCP end- 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 point. As a result, the TCP port number 0 is never actually used in
TCP segments. TCP segments.
Different implementations have been found to respond differently to Different implementations have been found to respond differently to
TCP segments that have a port number of 0 as the Source Port and/or TCP segments that have a port number of 0 as the Source Port and/or
skipping to change at page 11, line 13 skipping to change at page 11, line 22
fingerprinting [Jones, 2003]. fingerprinting [Jones, 2003].
Since in practice TCP port 0 is not used by any legitimate Since in practice TCP port 0 is not used by any legitimate
application and is only used for fingerprinting purposes, a number of application and is only used for fingerprinting purposes, a number of
host implementations already reject TCP segments that use 0 as the host implementations already reject TCP segments that use 0 as the
Source Port and/or the Destination Port. Also, a number firewalls Source Port and/or the Destination Port. Also, a number firewalls
filter (by default) any TCP segments that contain a port number of filter (by default) any TCP segments that contain a port number of
zero for the Source Port and/or the Destination Port. zero for the Source Port and/or the Destination Port.
We therefore recommend that TCP implementations respond to incoming We therefore recommend that TCP implementations respond to incoming
TCP segments that have a Source Port of 0 with an RST (provided these TCP segments that have a Source Port or a Destination Port of 0 with
incoming segments do not have the RST bit set). 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 Responding with an RST segment to incoming segments that have the RST
bit would open the door to RST-war attacks. bit would open the door to RST-war attacks.
As discussed in Section 3.2, we also recommend TCP implementations to Some systems have been found to be unable to process TCP segments in
respond with an RST to incoming packets that have a Destination Port which the source endpoint {Source Address, Source Port} is the same
of 0 (provided these incoming segments do not have the RST bit set). 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- A SYN segment in which the source end-point {Source Address, Source
id's 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 A number of implementations will not allow the creation of a new
connection if there exists a previous incarnation of the same connection if there exists a previous incarnation of the same
connection in any state other than the fictional state CLOSED. This connection in any state other than the fictional state CLOSED. This
can be problematic in scenarios in which a client establishes can be problematic in scenarios in which a client establishes
connections with a specific service at a particular server at a high 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 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 systems (the one performing the active close) will keep each of
the closed connections in the TIME-WAIT state for 2*MSL. the closed connections in the TIME-WAIT state for 2*MSL.
MSL (Maximum Segment Lifetime) is the maximum amount of time that a MSL (Maximum Segment Lifetime) is the maximum amount of time that
TCP segment can exist in an internet. It is defined to be 2 minutes a TCP segment can exist in an internet. It is defined to be 2
by RFC 793 [Postel, 1981c]. minutes by RFC 793 [Postel, 1981c].
If the connection rate is high enough, at some point all the 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 ephemeral ports at the client will be in use by some connection in
the TIME-WAIT state, thus preventing the establishment of new the TIME-WAIT state, thus preventing the establishment of new
connections. In order to overcome this problem, a number of TCP connections. In order to overcome this problem, a number of TCP
implementations include some heuristics to allow the creation of a implementations include some heuristics to allow the creation of a
new incarnation of a connection that is in the TIME-WAIT state. In new incarnation of a connection that is in the TIME-WAIT state. In
such implementations a new incarnation of a previous connection is such implementations a new incarnation of a previous connection is
allowed if: allowed if:
skipping to change at page 12, line 15 skipping to change at page 13, line 23
o The incoming SYN segment does not contain a timestamp option, but o The incoming SYN segment does not contain a timestamp option, but
its Initial Sequence Number (ISN) is greater than the last its Initial Sequence Number (ISN) is greater than the last
sequence number seen in the previous incarnation of the connection sequence number seen in the previous incarnation of the connection
(for that direction of the data transfer) (for that direction of the data transfer)
Unfortunately, these heuristics are optional, and thus cannot be Unfortunately, these heuristics are optional, and thus cannot be
relied upon. Additionally, as indicated by [Silbersack, 2005], if relied upon. Additionally, as indicated by [Silbersack, 2005], if
the Timestamp or the ISN are trivially randomized, these heuristics the Timestamp or the ISN are trivially randomized, these heuristics
might fail. 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 for the generation of TCP Initial Sequence Numbers and TCP
timestamps, respectively, that provide randomization, while still timestamps, respectively, that provide randomization, while still
allowing the aforementioned heuristics to work. allowing the aforementioned heuristics to work.
Therefore, the only strategy that can be relied upon to avoid this Therefore, the only strategy that can be relied upon to avoid this
interoperability problem is to minimize the rate of collisions of 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.
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
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 [Ramaiah et al, 2008] suggests that implementations should rate-limit
the challenge ACK segments sent as a result of implementation of this the challenge ACK segments sent as a result of implementation of this
mechanism. mechanism.
Section 11.1 of this document describes TCP-based connection-reset Section 11.1 of this document describes TCP-based connection-reset
attacks, along with a number of countermeasures to mitigate their attacks, along with a number of countermeasures to mitigate their
impact. 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 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 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. Common TCP Options
4.1. End of Option List (Kind = 0) 4.1. End of Option List (Kind = 0)
4.2. No Operation (Kind = 1) 4.2. No Operation (Kind = 1)
4.3. Maximum Segment Size (Kind = 2) 4.3. Maximum Segment Size (Kind = 2)
4.4. Selective Acknowledgement Option 4.4. Selective Acknowledgement Option
4.4.1. SACK-permitted Option (Kind = 4) 4.4.1. SACK-permitted Option (Kind = 4)
4.4.2. SACK Option (Kind = 5) 4.4.2. SACK Option (Kind = 5)
4.5. MD5 Option (Kind=19) 4.5. MD5 Option (Kind=19)
4.6. Window scale option (Kind = 3) 4.6. Window scale option (Kind = 3)
skipping to change at page 18, line 27 skipping to change at page 19, line 9
Additionally, the author would like to thank (in alphabetical order) Additionally, the author would like to thank (in alphabetical order)
Mark Allman, David Black, Ethan Blanton, David Borman, James Chacon, Mark Allman, David Black, Ethan Blanton, David Borman, James Chacon,
John Heffner, Jerrold Leichter, Jamshid Mahdavi, Keith Scott, Bill John Heffner, Jerrold Leichter, Jamshid Mahdavi, Keith Scott, Bill
Squier, and David White, who generously answered a number of Squier, and David White, who generously answered a number of
questions that araised while the aforementioned document was being questions that araised while the aforementioned document was being
written. written.
Finally, the author would like to thank CPNI (formely NISCC) for Finally, the author would like to thank CPNI (formely NISCC) for
their continued support. their continued support.
19. References 19. References-old
Abley, J., Savola, P., Neville-Neil, G. 2007. Deprecation of Type 0 Abley, J., Savola, P., Neville-Neil, G. 2007. Deprecation of Type 0
Routing Headers in IPv6. RFC 5095. Routing Headers in IPv6. RFC 5095.
Allman, M. 2003. TCP Congestion Control with Appropriate Byte Allman, M. 2003. TCP Congestion Control with Appropriate Byte
Counting (ABC). RFC 3465. Counting (ABC). RFC 3465.
Allman, M. 2008. Comments On Selecting Ephemeral Ports. Available Allman, M. 2008. Comments On Selecting Ephemeral Ports. Available
at: http://www.icir.org/mallman/share/ports-dec08.pdf at: http://www.icir.org/mallman/share/ports-dec08.pdf
skipping to change at page 28, line 21 skipping to change at page 29, line 6
Zander, S. 2008. Covert Channels in Computer Networks. Available Zander, S. 2008. Covert Channels in Computer Networks. Available
at: http://caia.swin.edu.au/cv/szander/cc/index.html at: http://caia.swin.edu.au/cv/szander/cc/index.html
Zuquete, A. 2002. Improving the functionality of SYN cookies. 6th Zuquete, A. 2002. Improving the functionality of SYN cookies. 6th
IFIP Communications and Multimedia Security Conference (CMS 2002). IFIP Communications and Multimedia Security Conference (CMS 2002).
Available at: http://www.ieeta.pt/~avz/pubs/CMS02.html Available at: http://www.ieeta.pt/~avz/pubs/CMS02.html
Zweig, J., Partridge, C. 1990. TCP Alternate Checksum Options. RFC Zweig, J., Partridge, C. 1990. TCP Alternate Checksum Options. RFC
1146. 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 Appendix A. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an by the RFC Editor before publishing this document as an
RFC) RFC)
A.1. Changes from draft-gont-tcp-security-00 A.1. Changes from draft-gont-tcp-security-00
o Draft resubmitted as draft-ietf (boilerplate updated as required). o Draft resubmitted as draft-ietf (boilerplate updated as required).
Appendix B. Advice and guidance to vendors Appendix B. Advice and guidance to vendors
 End of changes. 61 change blocks. 
202 lines changed or deleted 247 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/