[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

TCP Maintenance and Minor                                        F. Gont
Extensions (tcpm)                                                UK CPNI
Internet-Draft                                         February 19, 2010
Intended status: BCP
Expires: August 23, 2010


     Security Assessment of the Transmission Control Protocol (TCP)
                  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.

   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 August 23, 2010.

Copyright Notice

   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



Gont                     Expires August 23, 2010                [Page 1]

Internet-Draft           TCP Security Assessment           February 2010


   (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 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.8.2.  Security implications arising from the
               implementation of the urgent mechanism as "out of
               band" data . . . . . . . . . . . . . . . . . . . . . . 14



Gont                     Expires August 23, 2010                [Page 2]

Internet-Draft           TCP Security Assessment           February 2010


     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 . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . . . . . . . . . . . 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



Gont                     Expires August 23, 2010                [Page 3]

Internet-Draft           TCP Security Assessment           February 2010


     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  . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . . . . . . . . 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-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)  . . . . . . . . . . . . . . 29
     A.1.  Changes from draft-gont-tcp-security-00  . . . . . . . . . 29
   Appendix B.  Advice and guidance to vendors  . . . . . . . . . . . 29
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29



Gont                     Expires August 23, 2010                [Page 4]

Internet-Draft           TCP Security Assessment           February 2010


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 August 23, 2010                [Page 5]

Internet-Draft           TCP Security Assessment           February 2010


   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 August 23, 2010                [Page 6]

Internet-Draft           TCP Security Assessment           February 2010


   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 August 23, 2010                [Page 7]

Internet-Draft           TCP Security Assessment           February 2010


   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 August 23, 2010                [Page 8]

Internet-Draft           TCP Security Assessment           February 2010


   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 MUST be dropped.

   The following subsections contain further sanity checks that should
   be performed on TCP segments.

3.1.  Source Port and Destination Port

3.1.1.  REQUIREMENTS

   TCP SHOULD randomize its ephemeral (client-side) ports, to improve
   its resistance to off-path attacks.  For the purpose of ephemeral



Gont                     Expires August 23, 2010                [Page 9]

Internet-Draft           TCP Security Assessment           February 2010


   port selection, the largest posible port range SHOULD be used
   (ideally 1024-65535) [I-D.ietf-tsvwg-port-randomization].

   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).

   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).

   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.

   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).

   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.

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



Gont                     Expires August 23, 2010               [Page 10]

Internet-Draft           TCP Security Assessment           February 2010


   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].

   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 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.

   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.

   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



Gont                     Expires August 23, 2010               [Page 11]

Internet-Draft           TCP Security Assessment           February 2010


   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].

   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



Gont                     Expires August 23, 2010               [Page 12]

Internet-Draft           TCP Security Assessment           February 2010


   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,

   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.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.

3.2.  Sequence number

3.2.1.  Generation of Initial Sequence Numbers

3.3.  Acknowledgement Number

3.4.  Data Offset

3.5.  Control bits

3.5.1.  Reserved (four bits)

3.5.2.  CWR (Congestion Window Reduced)

3.5.3.  ECE (ECN-Echo)

3.5.4.  URG

3.5.5.  ACK




Gont                     Expires August 23, 2010               [Page 13]

Internet-Draft           TCP Security Assessment           February 2010


3.5.6.  PSH

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.5.8.  SYN

3.5.9.  FIN

3.6.  Window

3.6.1.  Security implications of the maximum TCP window size

3.6.2.  Security implications arising from closed windows

3.7.  Checksum

3.8.  Urgent pointer

3.8.1.  Security implications arising from ambiguities in the processing
        of urgent indications

3.8.2.  Security implications arising from the implementation of the
        urgent mechanism as "out of band" data

3.9.  Options

3.10.  Padding

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)





Gont                     Expires August 23, 2010               [Page 14]

Internet-Draft           TCP Security Assessment           February 2010


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

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





Gont                     Expires August 23, 2010               [Page 15]

Internet-Draft           TCP Security Assessment           February 2010


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

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





Gont                     Expires August 23, 2010               [Page 16]

Internet-Draft           TCP Security Assessment           February 2010


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

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







Gont                     Expires August 23, 2010               [Page 17]

Internet-Draft           TCP Security Assessment           February 2010


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


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



Gont                     Expires August 23, 2010               [Page 18]

Internet-Draft           TCP Security Assessment           February 2010


   written.

   Finally, the author would like to thank CPNI (formely NISCC) for
   their continued support.


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

   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.

   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



Gont                     Expires August 23, 2010               [Page 19]

Internet-Draft           TCP Security Assessment           February 2010


   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:
   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



Gont                     Expires August 23, 2010               [Page 20]

Internet-Draft           TCP Security Assessment           February 2010


   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

   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.



Gont                     Expires August 23, 2010               [Page 21]

Internet-Draft           TCP Security Assessment           February 2010


   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/.

   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                     Expires August 23, 2010               [Page 22]

Internet-Draft           TCP Security Assessment           February 2010


   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.
   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




Gont                     Expires August 23, 2010               [Page 23]

Internet-Draft           TCP Security Assessment           February 2010


   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.

   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.



Gont                     Expires August 23, 2010               [Page 24]

Internet-Draft           TCP Security Assessment           February 2010


   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

   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



Gont                     Expires August 23, 2010               [Page 25]

Internet-Draft           TCP Security Assessment           February 2010


   (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.

   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



Gont                     Expires August 23, 2010               [Page 26]

Internet-Draft           TCP Security Assessment           February 2010


   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:
   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.




Gont                     Expires August 23, 2010               [Page 27]

Internet-Draft           TCP Security Assessment           February 2010


   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

   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



Gont                     Expires August 23, 2010               [Page 28]

Internet-Draft           TCP Security Assessment           February 2010


   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

   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/ .


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 August 23, 2010               [Page 29]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/