Section 7. Security and Privacy Considerations

The TCP design includes only rudimentary security features that
   improve the robustness and reliability of connections and application
   data transfer, but there are no built-in cryptographic capabilities
   to support any form of confidentiality, authentication, or other
   typical security functions.  Non-cryptographic enhancements (e.g.,
   [9]) have been developed to improve robustness of TCP connections to
   particular types of attacks, but the applicability and protections of
   non-cryptographic enhancements are limited (e.g., see Section 1.1 of
   [9]).  Applications typically utilize lower-layer (e.g., IPsec) and
   upper-layer (e.g., TLS) protocols to provide security and privacy for
   TCP connections and application data carried in TCP.  Methods based
   on TCP Options have been developed as well, to support some security
   capabilities.
   In order to fully provide confidentiality, integrity protection, and
   authentication for TCP connections (including their control flags),
   IPsec is the only current effective method.  For integrity protection
   and authentication, the TCP Authentication Option (TCP-AO) [38] is
   available, with a proposed extension to also provide confidentiality
   for the segment payload.  Other methods discussed in this section may
   provide confidentiality or integrity protection for the payload, but
   for the TCP header only cover either a subset of the fields (e.g.,
   tcpcrypt [57]) or none at all (e.g., TLS).  Other security features
   that have been added to TCP (e.g., ISN generation, sequence number
   checks, and others) are only capable of partially hindering attacks.
   Applications using long-lived TCP flows have been vulnerable to
   attacks that exploit the processing of control flags described in
   earlier TCP specifications [33].  TCP-MD5 was a commonly implemented
   TCP Option to support authentication for some of these connections,
   but had flaws and is now deprecated.  TCP-AO provides a capability to
   protect long-lived TCP connections from attacks and has superior
   properties to TCP-MD5.  It does not provide any privacy for
   application data or for the TCP headers.
   The "tcpcrypt" [57] experimental extension to TCP provides the
   ability to cryptographically protect connection data.  Metadata
   aspects of the TCP flow are still visible, but the application stream
   is well protected.  Within the TCP header, only the urgent pointer
   and FIN flag are protected through tcpcrypt.
   The TCP Roadmap [49] includes notes about several RFCs related to TCP
   security.  Many of the enhancements provided by these RFCs have been
   integrated into the present document, including ISN generation,
   mitigating blind in-window attacks, and improving handling of soft
   errors and ICMP packets.  These are all discussed in greater detail
   in the referenced RFCs that originally described the changes needed
   to earlier TCP specifications.  Additionally, see RFC 6093 [39] for
   discussion of security considerations related to the urgent pointer
   field, which also discourages new applications from using the urgent
   pointer.
   Since TCP is often used for bulk transfer flows, some attacks are
   possible that abuse the TCP congestion control logic.  An example is
   "ACK-division" attacks.  Updates that have been made to the TCP
   congestion control specifications include mechanisms like Appropriate
   Byte Counting (ABC) [29] that act as mitigations to these attacks.
   Other attacks are focused on exhausting the resources of a TCP
   server.  Examples include SYN flooding [32] or wasting resources on
   non-progressing connections [41].  Operating systems commonly
   implement mitigations for these attacks.  Some common defenses also
   utilize proxies, stateful firewalls, and other technologies outside
   the end-host TCP implementation.
   The concept of a protocol's "wire image" is described in RFC 8546
   [56], which describes how TCP's cleartext headers expose more
   metadata to nodes on the path than is strictly required to route the
   packets to their destination.  On-path adversaries may be able to
   leverage this metadata.  Lessons learned in this respect from TCP
   have been applied in the design of newer transports like QUIC [60].
   Additionally, based partly on experiences with TCP and its
   extensions, there are considerations that might be applicable for
   future TCP extensions and other transports that the IETF has
   documented in RFC 9065 [61], along with IAB recommendations in RFC
   8558 [58] and [67].
   There are also methods of "fingerprinting" that can be used to infer
   the host TCP implementation (operating system) version or platform
   information.  These collect observations of several aspects, such as
   the options present in segments, the ordering of options, the
   specific behaviors in the case of various conditions, packet timing,
   packet sizing, and other aspects of the protocol that are left to be
   determined by an implementer, and can use those observations to
   identify information about the host and implementation.
   Since ICMP message processing also can interact with TCP connections,
   there is potential for ICMP-based attacks against TCP connections.
   These are discussed in RFC 5927 [100], along with mitigations that
   have been implemented.