draft-ietf-tcpm-rfc793bis-09.txt   draft-ietf-tcpm-rfc793bis-10.txt 
Internet Engineering Task Force W. Eddy, Ed. Internet Engineering Task Force W. Eddy, Ed.
Internet-Draft MTI Systems Internet-Draft MTI Systems
Obsoletes: 793, 879, 2873, 6093, 6429, March 28, 2018 Obsoletes: 793, 879, 2873, 6093, 6429, July 1, 2018
6528, 6691 (if approved) 6528, 6691 (if approved)
Updates: 5961, 1122 (if approved) Updates: 5961, 1122 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 29, 2018 Expires: January 2, 2019
Transmission Control Protocol Specification Transmission Control Protocol Specification
draft-ietf-tcpm-rfc793bis-09 draft-ietf-tcpm-rfc793bis-10
Abstract Abstract
This document specifies the Internet's Transmission Control Protocol This document specifies the Internet's Transmission Control Protocol
(TCP). TCP is an important transport layer protocol in the Internet (TCP). TCP is an important transport layer protocol in the Internet
stack, and has continuously evolved over decades of use and growth of stack, and has continuously evolved over decades of use and growth of
the Internet. Over this time, a number of changes have been made to the Internet. Over this time, a number of changes have been made to
TCP as it was specified in RFC 793, though these have only been TCP as it was specified in RFC 793, though these have only been
documented in a piecemeal fashion. This document collects and brings documented in a piecemeal fashion. This document collects and brings
those changes together with the protocol specification from RFC 793. those changes together with the protocol specification from RFC 793.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 29, 2018. This Internet-Draft will expire on January 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 5 skipping to change at page 3, line 5
3. Functional Specification . . . . . . . . . . . . . . . . . . 6 3. Functional Specification . . . . . . . . . . . . . . . . . . 6
3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 15 3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 15
3.4. Establishing a connection . . . . . . . . . . . . . . . . 22 3.4. Establishing a connection . . . . . . . . . . . . . . . . 22
3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 29 3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 29
3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 31 3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 31
3.6. Precedence and Security . . . . . . . . . . . . . . . . . 32 3.6. Precedence and Security . . . . . . . . . . . . . . . . . 32
3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 33 3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 33
3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 34 3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 34
3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 35 3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 36
3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 36 3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 36
3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 36 3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 37
3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 37 3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 37
3.8. Data Communication . . . . . . . . . . . . . . . . . . . 37 3.8. Data Communication . . . . . . . . . . . . . . . . . . . 37
3.8.1. Retransmission Timeout . . . . . . . . . . . . . . . 38 3.8.1. Retransmission Timeout . . . . . . . . . . . . . . . 38
3.8.2. TCP Congestion Control . . . . . . . . . . . . . . . 38 3.8.2. TCP Congestion Control . . . . . . . . . . . . . . . 38
3.8.3. TCP Connection Failures . . . . . . . . . . . . . . . 38 3.8.3. TCP Connection Failures . . . . . . . . . . . . . . . 39
3.8.4. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . 39 3.8.4. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . 40
3.8.5. The Communication of Urgent Information . . . . . . . 40 3.8.5. The Communication of Urgent Information . . . . . . . 40
3.8.6. Managing the Window . . . . . . . . . . . . . . . . . 41 3.8.6. Managing the Window . . . . . . . . . . . . . . . . . 41
3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 45 3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 45
3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 45 3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 46
3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 53 3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 54
3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 56 3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 56
3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 81 3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 81
4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 86 4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 86
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
6. Security and Privacy Considerations . . . . . . . . . . . . . 91 6. Security and Privacy Considerations . . . . . . . . . . . . . 91
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 92
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.1. Normative References . . . . . . . . . . . . . . . . . . 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 93
8.2. Informative References . . . . . . . . . . . . . . . . . 94 8.2. Informative References . . . . . . . . . . . . . . . . . 94
Appendix A. Other Implementation Notes . . . . . . . . . . . . . 97 Appendix A. Other Implementation Notes . . . . . . . . . . . . . 97
A.1. IP Security Compartment and Precedence . . . . . . . . . 97 A.1. IP Security Compartment and Precedence . . . . . . . . . 97
A.2. Sequence Number Validation . . . . . . . . . . . . . . . 97 A.2. Sequence Number Validation . . . . . . . . . . . . . . . 98
A.3. Nagle Modification . . . . . . . . . . . . . . . . . . . 98 A.3. Nagle Modification . . . . . . . . . . . . . . . . . . . 98
A.4. Low Water Mark . . . . . . . . . . . . . . . . . . . . . 98 A.4. Low Water Mark . . . . . . . . . . . . . . . . . . . . . 99
Appendix B. TCP Requirement Summary . . . . . . . . . . . . . . 98 Appendix B. TCP Requirement Summary . . . . . . . . . . . . . . 99
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 102
1. Purpose and Scope 1. Purpose and Scope
In 1981, RFC 793 [12] was released, documenting the Transmission In 1981, RFC 793 [12] was released, documenting the Transmission
Control Protocol (TCP), and replacing earlier specifications for TCP Control Protocol (TCP), and replacing earlier specifications for TCP
that had been published in the past. that had been published in the past.
Since then, TCP has been implemented many times, and has been used as Since then, TCP has been implemented many times, and has been used as
a transport protocol for numerous applications on the Internet. a transport protocol for numerous applications on the Internet.
For several decades, RFC 793 plus a number of other documents have For several decades, RFC 793 plus a number of other documents have
combined to serve as the specification for TCP [36]. Over time, a combined to serve as the specification for TCP [37]. Over time, a
number of errata have been identified on RFC 793, as well as number of errata have been identified on RFC 793, as well as
deficiencies in security, performance, and other aspects. A number deficiencies in security, performance, and other aspects. A number
of enhancements has grown and been documented separately. These were of enhancements has grown and been documented separately. These were
never accumulated together into an update to the base specification. never accumulated together into an update to the base specification.
The purpose of this document is to bring together all of the IETF The purpose of this document is to bring together all of the IETF
Standards Track changes that have been made to the basic TCP Standards Track changes that have been made to the basic TCP
functional specification and unify them into an update of the RFC 793 functional specification and unify them into an update of the RFC 793
protocol specification. Some companion documents are referenced for protocol specification. Some companion documents are referenced for
important algorithms that TCP uses (e.g. for congestion control), but important algorithms that TCP uses (e.g. for congestion control), but
skipping to change at page 4, line 48 skipping to change at page 4, line 48
repair losses. repair losses.
This document describes the basic functionality expected in modern This document describes the basic functionality expected in modern
implementations of TCP, and replaces the protocol specification in implementations of TCP, and replaces the protocol specification in
RFC 793. It does not replicate or attempt to update the examples and RFC 793. It does not replicate or attempt to update the examples and
other discussion in RFC 793. Other documents are referenced to other discussion in RFC 793. Other documents are referenced to
provide explanation of the theory of operation, rationale, and provide explanation of the theory of operation, rationale, and
detailed discussion of design decisions. This document only focuses detailed discussion of design decisions. This document only focuses
on the normative behavior of the protocol. on the normative behavior of the protocol.
The "TCP Roadmap" [36] provides a more extensive guide to the RFCs The "TCP Roadmap" [37] provides a more extensive guide to the RFCs
that define TCP and describe various important algorithms. The TCP that define TCP and describe various important algorithms. The TCP
Roadmap contains sections on strongly encouraged enhancements that Roadmap contains sections on strongly encouraged enhancements that
improve performance and other aspects of TCP beyond the basic improve performance and other aspects of TCP beyond the basic
operation specified in this document. As one example, implementing operation specified in this document. As one example, implementing
congestion control (e.g. [24]) is a TCP requirement, but is a complex congestion control (e.g. [25]) is a TCP requirement, but is a complex
topic on its own, and not described in detail in this document, as topic on its own, and not described in detail in this document, as
there are many options and possibilities that do not impact basic there are many options and possibilities that do not impact basic
interoperability. Similarly, most common TCP implementations today interoperability. Similarly, most common TCP implementations today
include the high-performance extensions in [34], but these are not include the high-performance extensions in [35], but these are not
strictly required or discussed in this document. strictly required or discussed in this document.
TEMPORARY EDITOR'S NOTE: This is an early revision in the process of TEMPORARY EDITOR'S NOTE: This is an early revision in the process of
updating RFC 793. Many planned changes are not yet incorporated. updating RFC 793. Many planned changes are not yet incorporated.
***Please do not use this revision as a basis for any work or ***Please do not use this revision as a basis for any work or
reference.*** reference.***
A list of changes from RFC 793 is contained in Section 4. A list of changes from RFC 793 is contained in Section 4.
skipping to change at page 6, line 6 skipping to change at page 6, line 6
liveness detection capability. liveness detection capability.
Data flow is supported bidirectionally over TCP connections, though Data flow is supported bidirectionally over TCP connections, though
applications are free to flow data only unidirectionally, if they so applications are free to flow data only unidirectionally, if they so
choose. choose.
TCP uses port numbers to identify application services and to TCP uses port numbers to identify application services and to
multiplex multiple flows between hosts. multiplex multiple flows between hosts.
A more detailed description of TCP's features compared to other A more detailed description of TCP's features compared to other
transport protocols can be found in Section 3.1 of [39]. Further transport protocols can be found in Section 3.1 of [40]. Further
description of the motivations for developing TCP and its role in the description of the motivations for developing TCP and its role in the
Internet stack can be found in Section 2 of [12] and earlier versions Internet stack can be found in Section 2 of [12] and earlier versions
of the TCP specification. of the TCP specification.
3. Functional Specification 3. Functional Specification
3.1. Header Format 3.1. Header Format
TCP segments are sent as internet datagrams. The Internet Protocol TCP segments are sent as internet datagrams. The Internet Protocol
(IP) header carries several information fields, including the source (IP) header carries several information fields, including the source
skipping to change at page 9, line 35 skipping to change at page 9, line 35
Case 2: An octet of option-kind, an octet of option-length, and Case 2: An octet of option-kind, an octet of option-length, and
the actual option-data octets. the actual option-data octets.
The option-length counts the two octets of option-kind and option- The option-length counts the two octets of option-kind and option-
length as well as the option-data octets. length as well as the option-data octets.
Note that the list of options may be shorter than the data offset Note that the list of options may be shorter than the data offset
field might imply. The content of the header beyond the End-of- field might imply. The content of the header beyond the End-of-
Option option must be header padding (i.e., zero). Option option must be header padding (i.e., zero).
The list of all currently defined options is managed by IANA [40], The list of all currently defined options is managed by IANA [41],
and each option is defined in other RFCs, as indicated there. That and each option is defined in other RFCs, as indicated there. That
set includes experimental options that can be extended to support set includes experimental options that can be extended to support
multiple concurrent uses [33]. multiple concurrent uses [34].
A given TCP implementation can support any currently defined A given TCP implementation can support any currently defined
options, but the following options MUST be supported (kind options, but the following options MUST be supported (kind
indicated in octal): indicated in octal):
Kind Length Meaning Kind Length Meaning
---- ------ ------- ---- ------ -------
0 - End of option list. 0 - End of option list.
1 - No-Operation. 1 - No-Operation.
2 4 Maximum Segment Size. 2 4 Maximum Segment Size.
skipping to change at page 19, line 6 skipping to change at page 19, line 6
ISN = M + F(localip, localport, remoteip, remoteport, secretkey) ISN = M + F(localip, localport, remoteip, remoteport, secretkey)
where M is the 4 microsecond timer, and F() is a pseudorandom where M is the 4 microsecond timer, and F() is a pseudorandom
function (PRF) of the connection's identifying parameters ("localip, function (PRF) of the connection's identifying parameters ("localip,
localport, remoteip, remoteport") and a secret key ("secretkey"). localport, remoteip, remoteport") and a secret key ("secretkey").
F() MUST NOT be computable from the outside, or an attacker could F() MUST NOT be computable from the outside, or an attacker could
still guess at sequence numbers from the ISN used for some other still guess at sequence numbers from the ISN used for some other
connection. The PRF could be implemented as a cryptographic has of connection. The PRF could be implemented as a cryptographic has of
the concatenation of the TCP connection parameters and some secret the concatenation of the TCP connection parameters and some secret
data. For discussion of the selection of a specific hash algorithm data. For discussion of the selection of a specific hash algorithm
and management of the secret key data, please see Section 3 of [31]. and management of the secret key data, please see Section 3 of [32].
For each connection there is a send sequence number and a receive For each connection there is a send sequence number and a receive
sequence number. The initial send sequence number (ISS) is chosen by sequence number. The initial send sequence number (ISS) is chosen by
the data sending TCP, and the initial receive sequence number (IRS) the data sending TCP, and the initial receive sequence number (IRS)
is learned during the connection establishing procedure. is learned during the connection establishing procedure.
For a connection to be established or initialized, the two TCPs must For a connection to be established or initialized, the two TCPs must
synchronize on each other's initial sequence numbers. This is done synchronize on each other's initial sequence numbers. This is done
in an exchange of connection establishing segments carrying a control in an exchange of connection establishing segments carrying a control
bit called "SYN" (for synchronize) and the initial sequence numbers. bit called "SYN" (for synchronize) and the initial sequence numbers.
skipping to change at page 31, line 29 skipping to change at page 31, line 29
(2 MSL) (2 MSL) (2 MSL) (2 MSL)
CLOSED CLOSED CLOSED CLOSED
Simultaneous Close Sequence Simultaneous Close Sequence
Figure 12 Figure 12
A TCP connection may terminate in two ways: (1) the normal TCP close A TCP connection may terminate in two ways: (1) the normal TCP close
sequence using a FIN handshake, and (2) an "abort" in which one or sequence using a FIN handshake, and (2) an "abort" in which one or
more RST segments are sent and the connection state is immediately more RST segments are sent and the connection state is immediately
discarded. If a TCP connection is closed by the remote site, the discarded. If the local TCP connection is closed by the remote side
local application MUST be informed whether it closed normally or was due to a FIN or RST received from the remote side, then the local
application MUST be informed whether it closed normally or was
aborted. aborted.
3.5.1. Half-Closed Connections 3.5.1. Half-Closed Connections
The normal TCP close sequence delivers buffered data reliably in both The normal TCP close sequence delivers buffered data reliably in both
directions. Since the two directions of a TCP connection are closed directions. Since the two directions of a TCP connection are closed
independently, it is possible for a connection to be "half closed," independently, it is possible for a connection to be "half closed,"
i.e., closed in only one direction, and a host is permitted to i.e., closed in only one direction, and a host is permitted to
continue sending data in the open direction on a half-closed continue sending data in the open direction on a half-closed
connection. connection.
A host MAY implement a "half-duplex" TCP close sequence, so that an A host MAY implement a "half-duplex" TCP close sequence, so that an
application that has called CLOSE cannot continue to read data from application that has called CLOSE cannot continue to read data from
the connection. If such a host issues a CLOSE call while received the connection. If such a host issues a CLOSE call while received
data is still pending in TCP, or if new data is received after CLOSE data is still pending in TCP, or if new data is received after CLOSE
is called, its TCP SHOULD send a RST to show that data was lost. is called, its TCP SHOULD send a RST to show that data was lost. See
[17] section 2.17 for discussion.
When a connection is closed actively, it MUST linger in TIME-WAIT When a connection is closed actively, it MUST linger in TIME-WAIT
state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY
accept a new SYN from the remote TCP to reopen the connection accept a new SYN from the remote TCP to reopen the connection
directly from TIME-WAIT state, if it: directly from TIME-WAIT state, if it:
(1) assigns its initial sequence number for the new connection to (1) assigns its initial sequence number for the new connection to
be larger than the largest sequence number it used on the previous be larger than the largest sequence number it used on the previous
connection incarnation, and connection incarnation, and
(2) returns to TIME-WAIT state if the SYN turns out to be an old (2) returns to TIME-WAIT state if the SYN turns out to be an old
duplicate. duplicate.
When the TCP Timestamp options are available, an improved algorithm When the TCP Timestamp options are available, an improved algorithm
is described in [29] in order to support higher connection is described in [30] in order to support higher connection
establishment rates. This algorithm for reducing TIME-WAIT is a Best establishment rates. This algorithm for reducing TIME-WAIT is a Best
Current Practice that SHOULD be implemented, since timestamp options Current Practice that SHOULD be implemented, since timestamp options
are commonly used, and using them to reduce TIME-WAIT provides are commonly used, and using them to reduce TIME-WAIT provides
benefits for busy Internet servers. benefits for busy Internet servers.
3.6. Precedence and Security 3.6. Precedence and Security
The IPv4 specification [1] includes a precedence value in the Type of The IPv4 specification [1] includes a precedence value in the (now
Service field (TOS), that was also modified in [15], and then obsoleted) Type of Service field (TOS) field. It was modified in
obsoleted by the definition of Differentiated Services (DiffServ) [15], and then obsoleted by the definition of Differentiated Services
[6]. In DiffServ the former precedence values are treated as Class (DiffServ) [6]. Setting and conveying TOS between the network layer,
TCP, and applications is obsolete, and replaced by DiffServ in the
current TCP specification.
In DiffServ the former precedence values are treated as Class
Selector codepoints, and methods for compatible treatment are Selector codepoints, and methods for compatible treatment are
described in the DiffServ architecture. The RFC 793/1122 TCP described in the DiffServ architecture. The RFC 793/1122 TCP
specification includes logic intending to have connections use the specification includes logic intending to have connections use the
highest precedence requested by either endpoint application, and to highest precedence requested by either endpoint application, and to
keep the precedence consistent throughout a connection. There is an keep the precedence consistent throughout a connection. This logic
assumption of bidirectional/symmetric precedence values, however, the from the obsolete TOS is not applicable for DiffServ, and should not
DiffServ architecture is asymmetric. Problems were described in [17] be included in TCP implementations, though changes to DiffServ values
and the solution described is to ignore IP precedence in TCP. Since within a connection are discouraged. For discussion of this, see RFC
RFC 2873 is a Standards Track document (although not marked as 7657 (sec 5.1, 5.3, and 6) [38].
updating RFC 793), these checks are no longer a part of the TCP
standard defined in this document, though the DiffServ field value is The obsoleted TOS processing rules in TCP assumed bidirectional (or
still is a part of the interface between TCP and the network layer, symmetric) precedence values used on a connection, but the DiffServ
and values can be indicated both ways between TCP and the architecture is asymmetric. Problems with the old TCP logic in this
application. regard were described in [18] and the solution described is to ignore
IP precedence in TCP. Since RFC 2873 is a Standards Track document
(although not marked as updating RFC 793), current implementations
are expected to be robust to these conditions. Note that the
DiffServ field value used in each direction is a part of the
interface between TCP and the network layer, and values in use can be
indicated both ways between TCP and the application.
The IP security option (IPSO) and compartment defined in [1] was The IP security option (IPSO) and compartment defined in [1] was
refined in RFC 1038 that was later obsoleted by RFC 1108. The refined in RFC 1038 that was later obsoleted by RFC 1108. The
Commercial IP Security Option (CIPSO) is defined in FIPS-188, and is Commercial IP Security Option (CIPSO) is defined in FIPS-188, and is
supported by some vendors and operating systems. RFC 1108 is now supported by some vendors and operating systems. RFC 1108 is now
Historic, though RFC 791 itself has not been updated to remove the IP Historic, though RFC 791 itself has not been updated to remove the IP
security option. For IPv6, a similar option (CALIPSO) has been security option. For IPv6, a similar option (CALIPSO) has been
defined [23]. RFC 793 includes logic that includes the IP security/ defined [24]. RFC 793 includes logic that includes the IP security/
compartment information in treatment of TCP segments. References to compartment information in treatment of TCP segments. References to
the IP "security/compartment" in this document may be relevant for the IP "security/compartment" in this document may be relevant for
Multi-Level Secure (MLS) system implementers, but can be ignored for Multi-Level Secure (MLS) system implementers, but can be ignored for
non-MLS implementations, consistent with running code on the non-MLS implementations, consistent with running code on the
Internet. See Appendix A.1 for further discussion. Note that RFC Internet. See Appendix A.1 for further discussion. Note that RFC
5570 describes some MLS networking scenarios where IPSO, CIPSO, or 5570 describes some MLS networking scenarios where IPSO, CIPSO, or
CALIPSO may be used. In these special cases, TCP implementers should CALIPSO may be used. In these special cases, TCP implementers should
see section 7.3.1 of RFC 5570, and follow the guidance in that see section 7.3.1 of RFC 5570, and follow the guidance in that
document on the relation between IP security. document on the relation between IP security.
skipping to change at page 33, line 19 skipping to change at page 33, line 33
The term "segmentation" refers to the activity TCP performs when The term "segmentation" refers to the activity TCP performs when
ingesting a stream of bytes from a sending application and ingesting a stream of bytes from a sending application and
packetizing that stream of bytes into TCP segments. Individual TCP packetizing that stream of bytes into TCP segments. Individual TCP
segments often do not correspond one-for-one to individual send (or segments often do not correspond one-for-one to individual send (or
socket write) calls from the application. Applications may perform socket write) calls from the application. Applications may perform
writes at the granularity of messages in the upper layer protocol, writes at the granularity of messages in the upper layer protocol,
but TCP guarantees no boundary coherence between the TCP segments but TCP guarantees no boundary coherence between the TCP segments
sent and received versus user application data read or write buffer sent and received versus user application data read or write buffer
boundaries. In some specific protocols, such as RDMA using DDP and boundaries. In some specific protocols, such as RDMA using DDP and
MPA [21], there are performance optimizations possible when the MPA [22], there are performance optimizations possible when the
relation between TCP segments and application data units can be relation between TCP segments and application data units can be
controlled, and MPA includes a specific mechanism for detecting and controlled, and MPA includes a specific mechanism for detecting and
verifying this relationship between TCP segments and application verifying this relationship between TCP segments and application
message data strcutures, but this is specific to applications like message data strcutures, but this is specific to applications like
RDMA. In general, multiple goals influence the sizing of TCP RDMA. In general, multiple goals influence the sizing of TCP
segments created by a TCP implementation. segments created by a TCP implementation.
Goals driving the sending of larger segments include: Goals driving the sending of larger segments include:
o Reducing the number of packets in flight within the network. o Reducing the number of packets in flight within the network.
skipping to change at page 35, line 18 skipping to change at page 35, line 31
o IPoptionsize is the size of any IP options associated with a TCP o IPoptionsize is the size of any IP options associated with a TCP
connection. Note that some options may not be included on all connection. Note that some options may not be included on all
packets, but that for each segment sent, the sender should adjust packets, but that for each segment sent, the sender should adjust
the data length accordingly, within the Eff.snd.MSS. the data length accordingly, within the Eff.snd.MSS.
The MSS value to be sent in an MSS option should be equal to the The MSS value to be sent in an MSS option should be equal to the
effective MTU minus the fixed IP and TCP headers. By ignoring both effective MTU minus the fixed IP and TCP headers. By ignoring both
IP and TCP options when calculating the value for the MSS option, if IP and TCP options when calculating the value for the MSS option, if
there are any IP or TCP options to be sent in a packet, then the there are any IP or TCP options to be sent in a packet, then the
sender must decrease the size of the TCP data accordingly. RFC 6691 sender must decrease the size of the TCP data accordingly. RFC 6691
[32] discusses this in greater detail. [33] discusses this in greater detail.
The MSS value to be sent in an MSS option must be less than or equal The MSS value to be sent in an MSS option must be less than or equal
to: to:
MMS_R - 20 MMS_R - 20
where MMS_R is the maximum size for a transport-layer message that where MMS_R is the maximum size for a transport-layer message that
can be received (and reassembled at the IP layer). TCP obtains MMS_R can be received (and reassembled at the IP layer). TCP obtains MMS_R
and MMS_S from the IP layer; see the generic call GET_MAXSIZES in and MMS_S from the IP layer; see the generic call GET_MAXSIZES in
Section 3.4 of RFC 1122. These are defined in terms of their IP MTU Section 3.4 of RFC 1122. These are defined in terms of their IP MTU
skipping to change at page 36, line 12 skipping to change at page 36, line 26
avoid both on-path (for IPv4) and source fragmentation (IPv4 and avoid both on-path (for IPv4) and source fragmentation (IPv4 and
IPv6). IPv6).
PMTUD for IPv4 [2] or IPv6 [3] is implemented in conjunction between PMTUD for IPv4 [2] or IPv6 [3] is implemented in conjunction between
TCP, IP, and ICMP protocols. It relies both on avoiding source TCP, IP, and ICMP protocols. It relies both on avoiding source
fragmentation and setting the IPv4 DF (don't fragment) flag, the fragmentation and setting the IPv4 DF (don't fragment) flag, the
latter to inhibit on-path fragmentation. It relies on ICMP errors latter to inhibit on-path fragmentation. It relies on ICMP errors
from routers along the path, whenever a segment is too large to from routers along the path, whenever a segment is too large to
traverse a link. Several adjustments to a TCP implementation with traverse a link. Several adjustments to a TCP implementation with
PMTUD are described in RFC 2923 in order to deal with problems PMTUD are described in RFC 2923 in order to deal with problems
experienced in practice [8]. PLPMTUD [18] is a Standards Track experienced in practice [8]. PLPMTUD [19] is a Standards Track
improvement to PMTUD that relaxes the requirement for ICMP support improvement to PMTUD that relaxes the requirement for ICMP support
across a path, and improves performance in cases where ICMP is not across a path, and improves performance in cases where ICMP is not
consistently conveyed, but still tries to avoid source fragmentation. consistently conveyed, but still tries to avoid source fragmentation.
The mechanisms in all four of these RFCs are recommended to be The mechanisms in all four of these RFCs are recommended to be
included in TCP implementations. included in TCP implementations.
The TCP MSS option specifies an upper bound for the size of packets The TCP MSS option specifies an upper bound for the size of packets
that can be received. Hence, setting the value in the MSS option too that can be received. Hence, setting the value in the MSS option too
small can impact the ability for PMTUD or PLPMTUD to find a larger small can impact the ability for PMTUD or PLPMTUD to find a larger
path MTU. RFC 1191 discusses this implication of many older TCP path MTU. RFC 1191 discusses this implication of many older TCP
implementations setting MSS to 536 for non-local destinations, rather implementations setting MSS to 536 for non-local destinations, rather
than deriving it from the MTUs of connected interfaces as than deriving it from the MTUs of connected interfaces as
recommended. recommended.
3.7.3. Interfaces with Variable MTU Values 3.7.3. Interfaces with Variable MTU Values
The effective MTU can sometimes vary, as when used with variable The effective MTU can sometimes vary, as when used with variable
compression, e.g., RObust Header Compression (ROHC) [25]. It is compression, e.g., RObust Header Compression (ROHC) [26]. It is
tempting for TCP to want to advertise the largest possible MSS, to tempting for TCP to want to advertise the largest possible MSS, to
support the most efficient use of compressed payloads. support the most efficient use of compressed payloads.
Unfortunately, some compression schemes occasionally need to transmit Unfortunately, some compression schemes occasionally need to transmit
full headers (and thus smaller payloads) to resynchronize state at full headers (and thus smaller payloads) to resynchronize state at
their endpoint compressors/decompressors. If the largest MTU is used their endpoint compressors/decompressors. If the largest MTU is used
to calculate the value to advertise in the MSS option, TCP to calculate the value to advertise in the MSS option, TCP
retransmission may interfere with compressor resynchronization. retransmission may interfere with compressor resynchronization.
As a result, when the effective MTU of an interface varies, TCP As a result, when the effective MTU of an interface varies, TCP
SHOULD use the smallest effective MTU of the interface to calculate SHOULD use the smallest effective MTU of the interface to calculate
skipping to change at page 37, line 11 skipping to change at page 37, line 26
If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the
sending TCP buffers all user data (regardless of the PSH bit), until sending TCP buffers all user data (regardless of the PSH bit), until
the outstanding data has been acknowledged or until the TCP can send the outstanding data has been acknowledged or until the TCP can send
a full-sized segment (Eff.snd.MSS bytes). a full-sized segment (Eff.snd.MSS bytes).
A TCP SHOULD implement the Nagle Algorithm to coalesce short A TCP SHOULD implement the Nagle Algorithm to coalesce short
segments. However, there MUST be a way for an application to disable segments. However, there MUST be a way for an application to disable
the Nagle algorithm on an individual connection. In all cases, the Nagle algorithm on an individual connection. In all cases,
sending data is also subject to the limitation imposed by the Slow sending data is also subject to the limitation imposed by the Slow
Start algorithm [24]. Start algorithm [25].
3.7.5. IPv6 Jumbograms 3.7.5. IPv6 Jumbograms
In order to support TCP over IPv6 jumbograms, implementations need to In order to support TCP over IPv6 jumbograms, implementations need to
be able to send TCP segments larger than the 64KB limit that the MSS be able to send TCP segments larger than the 64KB limit that the MSS
option can convey. RFC 2675 [7] defines that an MSS value of 65,535 option can convey. RFC 2675 [7] defines that an MSS value of 65,535
bytes is to be treated as infinity, and Path MTU Discovery [3] is bytes is to be treated as infinity, and Path MTU Discovery [3] is
used to determine the actual MSS. used to determine the actual MSS.
3.8. Data Communication 3.8. Data Communication
skipping to change at page 38, line 36 skipping to change at page 38, line 49
RFC 1122 required implementation of Van Jacobson's congestion control RFC 1122 required implementation of Van Jacobson's congestion control
algorithm combining slow start with congestion avoidance. RFC 2581 algorithm combining slow start with congestion avoidance. RFC 2581
provided IETF Standards Track description of this, along with fast provided IETF Standards Track description of this, along with fast
retransmit and fast recovery. RFC 5681 is the current description of retransmit and fast recovery. RFC 5681 is the current description of
these algorithms and is the current standard for TCP congestion these algorithms and is the current standard for TCP congestion
control. control.
A TCP MUST implement RFC 5681. A TCP MUST implement RFC 5681.
Explicit Congestion Notification (ECN) was defined in RFC 3168 and is Explicit Congestion Notification (ECN) was defined in RFC 3168 and is
an IETF Standards Track enhancement that has many benefits [38]. an IETF Standards Track enhancement that has many benefits [39].
A TCP SHOULD implement ECN as described in RFC 3168. A TCP SHOULD implement ECN as described in RFC 3168.
3.8.3. TCP Connection Failures 3.8.3. TCP Connection Failures
Excessive retransmission of the same segment by TCP indicates some Excessive retransmission of the same segment by TCP indicates some
failure of the remote host or the Internet path. This failure may be failure of the remote host or the Internet path. This failure may be
of short or long duration. The following procedure MUST be used to of short or long duration. The following procedure MUST be used to
handle excessive retransmissions of data segments: handle excessive retransmissions of data segments:
skipping to change at page 40, line 17 skipping to change at page 40, line 32
An implementation SHOULD send a keep-alive segment with no data; An implementation SHOULD send a keep-alive segment with no data;
however, it MAY be configurable to send a keep-alive segment however, it MAY be configurable to send a keep-alive segment
containing one garbage octet, for compatibility with erroneous TCP containing one garbage octet, for compatibility with erroneous TCP
implementations. implementations.
3.8.5. The Communication of Urgent Information 3.8.5. The Communication of Urgent Information
As a result of implementation differences and middlebox interactions, As a result of implementation differences and middlebox interactions,
new applications SHOULD NOT employ the TCP urgent mechanism. new applications SHOULD NOT employ the TCP urgent mechanism.
However, TCP implementations MUST still include support for the However, TCP implementations MUST still include support for the
urgent mechanism. Details can be found in RFC 6093 [28]. urgent mechanism. Details can be found in RFC 6093 [29].
The objective of the TCP urgent mechanism is to allow the sending The objective of the TCP urgent mechanism is to allow the sending
user to stimulate the receiving user to accept some urgent data and user to stimulate the receiving user to accept some urgent data and
to permit the receiving TCP to indicate to the receiving user when to permit the receiving TCP to indicate to the receiving user when
all the currently known urgent data has been received by the user. all the currently known urgent data has been received by the user.
This mechanism permits a point in the data stream to be designated as This mechanism permits a point in the data stream to be designated as
the end of urgent information. Whenever this point is in advance of the end of urgent information. Whenever this point is in advance of
the receive sequence number (RCV.NXT) at the receiving TCP, that TCP the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
must tell the user to go into "urgent mode"; when the receive must tell the user to go into "urgent mode"; when the receive
skipping to change at page 42, line 27 skipping to change at page 42, line 40
(ZWP) in other documents. (ZWP) in other documents.
Probing of zero (offered) windows MUST be supported. Probing of zero (offered) windows MUST be supported.
A TCP MAY keep its offered receive window closed indefinitely. As A TCP MAY keep its offered receive window closed indefinitely. As
long as the receiving TCP continues to send acknowledgments in long as the receiving TCP continues to send acknowledgments in
response to the probe segments, the sending TCP MUST allow the response to the probe segments, the sending TCP MUST allow the
connection to stay open. This enables TCP to function in scenarios connection to stay open. This enables TCP to function in scenarios
such as the "printer ran out of paper" situation described in such as the "printer ran out of paper" situation described in
Section 4.2.2.17 of RFC1122. The behavior is subject to the Section 4.2.2.17 of RFC1122. The behavior is subject to the
implementation's resource management concerns, as noted in [30]. implementation's resource management concerns, as noted in [31].
When the receiving TCP has a zero window and a segment arrives it When the receiving TCP has a zero window and a segment arrives it
must still send an acknowledgment showing its next expected sequence must still send an acknowledgment showing its next expected sequence
number and current window (zero). number and current window (zero).
3.8.6.2. Silly Window Syndrome Avoidance 3.8.6.2. Silly Window Syndrome Avoidance
The "Silly Window Syndrome" (SWS) is a stable pattern of small The "Silly Window Syndrome" (SWS) is a stable pattern of small
incremental window movements resulting in extremely poor TCP incremental window movements resulting in extremely poor TCP
performance. Algorithms to avoid SWS are described below for both performance. Algorithms to avoid SWS are described below for both
skipping to change at page 48, line 50 skipping to change at page 49, line 15
which case, an automatic OPEN would be done. For example, this which case, an automatic OPEN would be done. For example, this
might be one way for application data to be included in SYN might be one way for application data to be included in SYN
segments. If the calling process is not authorized to use this segments. If the calling process is not authorized to use this
connection, an error is returned. connection, an error is returned.
If the PUSH flag is set, the data must be transmitted promptly If the PUSH flag is set, the data must be transmitted promptly
to the receiver, and the PUSH bit will be set in the last TCP to the receiver, and the PUSH bit will be set in the last TCP
segment created from the buffer. If the PUSH flag is not set, segment created from the buffer. If the PUSH flag is not set,
the data may be combined with data from subsequent SENDs for the data may be combined with data from subsequent SENDs for
transmission efficiency. Note that when the Nagle algorithm is transmission efficiency. Note that when the Nagle algorithm is
in use, TCP may be buffer the data before sending, without in use, TCP may buffer the data before sending, without regard
regard to the PUSH flag (see Section 3.7.4). to the PUSH flag (see Section 3.7.4).
New applications SHOULD NOT set the URGENT flag [28] due to New applications SHOULD NOT set the URGENT flag [29] due to
implementation differences and middlebox issues. implementation differences and middlebox issues.
If the URGENT flag is set, segments sent to the destination TCP If the URGENT flag is set, segments sent to the destination TCP
will have the urgent pointer set. The receiving TCP will will have the urgent pointer set. The receiving TCP will
signal the urgent condition to the receiving process if the signal the urgent condition to the receiving process if the
urgent pointer indicates that data preceding the urgent pointer urgent pointer indicates that data preceding the urgent pointer
has not been consumed by the receiving process. The purpose of has not been consumed by the receiving process. The purpose of
urgent is to stimulate the receiver to process the urgent data urgent is to stimulate the receiver to process the urgent data
and to indicate to the receiver when all the currently known and to indicate to the receiver when all the currently known
urgent data has been received. The number of times the sending urgent data has been received. The number of times the sending
skipping to change at page 54, line 31 skipping to change at page 54, line 46
that a segment be destroyed if it cannot be delivered by the that a segment be destroyed if it cannot be delivered by the
internet system within one minute. RFC 1122 changed this internet system within one minute. RFC 1122 changed this
specification to require that the TTL be configurable. specification to require that the TTL be configurable.
Note that the DiffServ field is permitted to change during a Note that the DiffServ field is permitted to change during a
connection (section 4.2.4.2 of RFC 1122). However, the connection (section 4.2.4.2 of RFC 1122). However, the
application interface might not support this ability, and the application interface might not support this ability, and the
application does not have knowledge about individual TCP application does not have knowledge about individual TCP
segments, so this can only be done on a coarse granularity, at segments, so this can only be done on a coarse granularity, at
best. This limitation is further discussed in RFC 7657 (sec best. This limitation is further discussed in RFC 7657 (sec
5.1, 5.3, and 6) [37]. Generally, an application SHOULD NOT 5.1, 5.3, and 6) [38]. Generally, an application SHOULD NOT
change the DiffServ field value during the course of a change the DiffServ field value during the course of a
connection. connection.
Any lower level protocol will have to provide the source address, Any lower level protocol will have to provide the source address,
destination address, and protocol fields, and some way to determine destination address, and protocol fields, and some way to determine
the "TCP length", both to provide the functional equivalent service the "TCP length", both to provide the functional equivalent service
of IP and to be used in the TCP checksum. of IP and to be used in the TCP checksum.
When received options are passed up to TCP from the IP layer, TCP When received options are passed up to TCP from the IP layer, TCP
MUST ignore options that it does not understand. MUST ignore options that it does not understand.
skipping to change at page 55, line 26 skipping to change at page 55, line 40
3.9.2.2. ICMP Messages 3.9.2.2. ICMP Messages
TCP MUST act on an ICMP error message passed up from the IP layer, TCP MUST act on an ICMP error message passed up from the IP layer,
directing it to the connection that created the error. The necessary directing it to the connection that created the error. The necessary
demultiplexing information can be found in the IP header contained demultiplexing information can be found in the IP header contained
within the ICMP message. within the ICMP message.
This applies to ICMPv6 in addition to IPv4 ICMP. This applies to ICMPv6 in addition to IPv4 ICMP.
[22] contains discussion of specific ICMP and ICMPv6 messages [23] contains discussion of specific ICMP and ICMPv6 messages
classified as either "soft" or "hard" errors that may bear different classified as either "soft" or "hard" errors that may bear different
responses. Treatment for classes of ICMP messages is described responses. Treatment for classes of ICMP messages is described
below: below:
Source Quench Source Quench
TCP MUST silently discard any received ICMP Source Quench messages. TCP MUST silently discard any received ICMP Source Quench messages.
See [11] for discussion. See [11] for discussion.
Soft Errors Soft Errors
For ICMP these include: Destination Unreachable -- codes 0, 1, 5, For ICMP these include: Destination Unreachable -- codes 0, 1, 5,
skipping to change at page 55, line 38 skipping to change at page 56, line 4
responses. Treatment for classes of ICMP messages is described responses. Treatment for classes of ICMP messages is described
below: below:
Source Quench Source Quench
TCP MUST silently discard any received ICMP Source Quench messages. TCP MUST silently discard any received ICMP Source Quench messages.
See [11] for discussion. See [11] for discussion.
Soft Errors Soft Errors
For ICMP these include: Destination Unreachable -- codes 0, 1, 5, For ICMP these include: Destination Unreachable -- codes 0, 1, 5,
Time Exceeded -- codes 0, 1, and Parameter Problem. Time Exceeded -- codes 0, 1, and Parameter Problem.
For ICMPv6 these include: Destination Unreachable -- codes 0 and 3, For ICMPv6 these include: Destination Unreachable -- codes 0 and 3,
Time Exceeded -- codes 0, 1, and Parameter Problem -- codes 0, 1, 2 Time Exceeded -- codes 0, 1, and Parameter Problem -- codes 0, 1, 2
Since these Unreachable messages indicate soft error conditions, Since these Unreachable messages indicate soft error conditions,
TCP MUST NOT abort the connection, and it SHOULD make the TCP MUST NOT abort the connection, and it SHOULD make the
information available to the application. information available to the application.
Hard Errors Hard Errors
For ICMP these include Destination Unreachable -- codes 2-4"> For ICMP these include Destination Unreachable -- codes 2-4">
These are hard error conditions, so TCP SHOULD abort the These are hard error conditions, so TCP SHOULD abort the
connection. [22] notes that some implementations do not abort connection. [23] notes that some implementations do not abort
connections when an ICMP hard error is received for a connection connections when an ICMP hard error is received for a connection
that is in any of the synchronized states. that is in any of the synchronized states.
Note that [22] section 4 describes widespread implementation behavior Note that [23] section 4 describes widespread implementation behavior
that treats soft errors as hard errors during connection that treats soft errors as hard errors during connection
establishment. establishment.
3.9.2.3. Remote Address Validation 3.9.2.3. Remote Address Validation
RFC 1122 requires addresses to be validated in incoming SYN packets: RFC 1122 requires addresses to be validated in incoming SYN packets:
An incoming SYN with an invalid source address must be ignored An incoming SYN with an invalid source address must be ignored
either by TCP or by the IP layer (see Section 3.2.1.3 of [14]). either by TCP or by the IP layer (see Section 3.2.1.3 of [14]).
skipping to change at page 68, line 46 skipping to change at page 68, line 46
If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset
(unless the RST bit is set, if so drop the segment and (unless the RST bit is set, if so drop the segment and
return) return)
<SEQ=SEG.ACK><CTL=RST> <SEQ=SEG.ACK><CTL=RST>
and discard the segment. Return. and discard the segment. Return.
If SND.UNA < SEG.ACK =< SND.NXT then the ACK is If SND.UNA < SEG.ACK =< SND.NXT then the ACK is
acceptable. Some deployed TCP code has used the check acceptable. Some deployed TCP code has used the check
SEG.ACK == SND.NEXT (using "==" rather than "=<", but SEG.ACK == SND.NXT (using "==" rather than "=<", but this
this is not appropriate when the stack is capable of is not appropriate when the stack is capable of sending
sending data on the SYN, because the peer TCP may not data on the SYN, because the peer TCP may not accept and
accept and acknowledge all of the data on the SYN. acknowledge all of the data on the SYN.
second check the RST bit second check the RST bit
If the RST bit is set If the RST bit is set
A potential blind reset attack is described in RFC 5961 A potential blind reset attack is described in RFC 5961
[27], with the mitigation that a TCP implementation [28], with the mitigation that a TCP implementation
SHOULD first check that the sequence number exactly SHOULD first check that the sequence number exactly
matches RCV.NXT prior to executing the action in the next matches RCV.NXT prior to executing the action in the next
paragraph. paragraph.
If the ACK was acceptable then signal the user "error: If the ACK was acceptable then signal the user "error:
connection reset", drop the segment, enter CLOSED state, connection reset", drop the segment, enter CLOSED state,
delete TCB, and return. Otherwise (no ACK) drop the delete TCB, and return. Otherwise (no ACK) drop the
segment and return. segment and return.
third check the security third check the security
skipping to change at page 70, line 25 skipping to change at page 70, line 25
If there are other controls or text in the segment, queue If there are other controls or text in the segment, queue
them for processing after the ESTABLISHED state has been them for processing after the ESTABLISHED state has been
reached, return. reached, return.
Note that it is legal to send and receive application data Note that it is legal to send and receive application data
on SYN segments (this is the "text in the segment" mentioned on SYN segments (this is the "text in the segment" mentioned
above. There has been significant misinformation and above. There has been significant misinformation and
misunderstanding of this topic historically. Some firewalls misunderstanding of this topic historically. Some firewalls
and security devices consider this suspicious. However, the and security devices consider this suspicious. However, the
capability was used in T/TCP [16] and is used in TCP Fast capability was used in T/TCP [16] and is used in TCP Fast
Open (TFO) [35], so is important for implementations and Open (TFO) [36], so is important for implementations and
network devices to permit. network devices to permit.
fifth, if neither of the SYN or RST bits is set then drop the fifth, if neither of the SYN or RST bits is set then drop the
segment and return. segment and return.
Otherwise, Otherwise,
first check sequence number first check sequence number
SYN-RECEIVED STATE SYN-RECEIVED STATE
skipping to change at page 71, line 40 skipping to change at page 71, line 40
If an incoming segment is not acceptable, an acknowledgment If an incoming segment is not acceptable, an acknowledgment
should be sent in reply (unless the RST bit is set, if so should be sent in reply (unless the RST bit is set, if so
drop the segment and return): drop the segment and return):
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, drop the unacceptable After sending the acknowledgment, drop the unacceptable
segment and return. segment and return.
Note that for the TIME-WAIT state, there is an improved Note that for the TIME-WAIT state, there is an improved
algorithm described in [29] for handling incoming SYN algorithm described in [30] for handling incoming SYN
segments, that utilizes timestamps rather than relying on segments, that utilizes timestamps rather than relying on
the sequence number check described here. When the improved the sequence number check described here. When the improved
algorithm is implemented, the logic above is not applicable algorithm is implemented, the logic above is not applicable
for incoming SYN segments with timestamp options, received for incoming SYN segments with timestamp options, received
on a connection in the TIME-WAIT state. on a connection in the TIME-WAIT state.
In the following it is assumed that the segment is the In the following it is assumed that the segment is the
idealized segment that begins at RCV.NXT and does not exceed idealized segment that begins at RCV.NXT and does not exceed
the window. One could tailor actual segments to fit this the window. One could tailor actual segments to fit this
assumption by trimming off any portions that lie outside the assumption by trimming off any portions that lie outside the
skipping to change at page 74, line 28 skipping to change at page 74, line 28
FIN-WAIT STATE-2 FIN-WAIT STATE-2
CLOSE-WAIT STATE CLOSE-WAIT STATE
CLOSING STATE CLOSING STATE
LAST-ACK STATE LAST-ACK STATE
TIME-WAIT STATE TIME-WAIT STATE
If the SYN bit is set in these synchronized states, it If the SYN bit is set in these synchronized states, it
may be either a legitimate new connection attempt (e.g. may be either a legitimate new connection attempt (e.g.
in the case of TIME-WAIT), an error where the connection in the case of TIME-WAIT), an error where the connection
should be reset, or the result of an attack attempt, as should be reset, or the result of an attack attempt, as
described in RFC 5961 [27]. For the TIME-WAIT state, new described in RFC 5961 [28]. For the TIME-WAIT state, new
connections can be accepted if the timestamp option is connections can be accepted if the timestamp option is
used and meets expectations (per [29]). For all other used and meets expectations (per [30]). For all other
caess, RFC 5961 provides a mitigation that SHOULD be caess, RFC 5961 provides a mitigation that SHOULD be
implemented, though there are alternatives (see implemented, though there are alternatives (see
Section 6). RFC 5961 recommends that in these Section 6). RFC 5961 recommends that in these
synchronized states, if the SYN bit is set, irrespective synchronized states, if the SYN bit is set, irrespective
of the sequence number, TCP MUST send a "challenge ACK" of the sequence number, TCP MUST send a "challenge ACK"
to the remote peer: to the remote peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgement, TCP MUST drop the After sending the acknowledgement, TCP MUST drop the
skipping to change at page 86, line 19 skipping to change at page 86, line 19
TCB TCB
Transmission control block, the data structure that records Transmission control block, the data structure that records
the state of a connection. the state of a connection.
TCP TCP
Transmission Control Protocol: A host-to-host protocol for Transmission Control Protocol: A host-to-host protocol for
reliable communication in internetwork environments. reliable communication in internetwork environments.
TOS TOS
Type of Service, an IPv4 field, that currently carries the Type of Service, an obsoleted IPv4 field. The same header
Differentiated Services field [6] containing the bits currently are used for the Differentiated Services field
Differentiated Services Code Point (DSCP) value and two [6] containing the Differentiated Services Code Point (DSCP)
unused bits. value and two unused bits.
Type of Service Type of Service
An Internet Protocol field which indicates the type of An Internet Protocol field which indicates the type of
service for this internet fragment. service for this internet fragment.
URG URG
A control bit (urgent), occupying no sequence space, used to A control bit (urgent), occupying no sequence space, used to
indicate that the receiving user should be notified to do indicate that the receiving user should be notified to do
urgent processing as long as there is data to be consumed urgent processing as long as there is data to be consumed
with sequence numbers less than the value indicated in the with sequence numbers less than the value indicated in the
skipping to change at page 90, line 39 skipping to change at page 90, line 39
multihomed multihomed
fixed/updated definition of options in glossary fixed/updated definition of options in glossary
moved note on aggregating ACKs from 1122 to a more appropriate moved note on aggregating ACKs from 1122 to a more appropriate
location location
resolved notes on IP precedence and security/compartment resolved notes on IP precedence and security/compartment
added implementation note on sequence number validation added implementation note on sequence number validation
added note that PUSH does not apply when Nagle is active added note that PUSH does not apply when Nagle is active
added 1122 content on asynchronous reports to replace 793 section added 1122 content on asynchronous reports to replace 793 section
on TCP to user messages on TCP to user messages
The -09 revision fixes section numbering problems.
The -10 revision includes additions to the security considerations
based on comments from Joe Touch, and suggested edits on RST/FIN
notification, RFC 2525 reference, and other edits suggested by
Yuchung Cheng, as well as modifications to DiffServ text from Yuchung
Cheng and Gorry Fairhurst.
Some other suggested changes that will not be incorporated in this Some other suggested changes that will not be incorporated in this
793 update unless TCPM consensus changes with regard to scope are: 793 update unless TCPM consensus changes with regard to scope are:
1. look at Tony Sabatini suggestion for describing DO field 1. look at Tony Sabatini suggestion for describing DO field
2. per discussion with Joe Touch (TAPS list, 6/20/2015), the 2. per discussion with Joe Touch (TAPS list, 6/20/2015), the
description of the API could be revisited description of the API could be revisited
Early in the process of updating RFC 793, Scott Brim mentioned that Early in the process of updating RFC 793, Scott Brim mentioned that
this should include a PERPASS/privacy review. This may be something this should include a PERPASS/privacy review. This may be something
for the chairs or AD to request during WGLC or IETF LC. for the chairs or AD to request during WGLC or IETF LC.
skipping to change at page 91, line 17 skipping to change at page 91, line 23
This memo includes no request to IANA. Existing IANA registries for This memo includes no request to IANA. Existing IANA registries for
TCP parameters are sufficient. TCP parameters are sufficient.
TODO: check whether entries pointing to 793 and other documents TODO: check whether entries pointing to 793 and other documents
obsoleted by this one should be updated to point to this one instead. obsoleted by this one should be updated to point to this one instead.
6. Security and Privacy Considerations 6. Security and Privacy Considerations
The TCP design includes only rudimentary security features that The TCP design includes only rudimentary security features that
improve the robustness and reliability of connections and application improve the robustness and reliability of connections and application
data transfer, but there are no built-in capabilities to support any data transfer, but there are no built-in cryptographic capabilities
form of privacy, authentication, or other typical security functions. to support any form of privacy, authentication, or other typical
Applications typically utilize lower-layer (e.g. IPsec) and upper- security functions. Non-cryptographic enhancements (e.g. [28]) have
layer (e.g. TLS) protocols to provide security and privacy for TCP been developed to improve robustness of TCP connections to particular
connections and application data carried in TCP. TCP options are types of attacks, but the applicability and protections of non-
available as well, to support some security capabilities. cryptographic enhancements are limited (e.g. see section 1.1 of
[28]). 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 protect TCP connections (including their control
flags) IPsec or the TCP Authentication Option (TCP-AO) [27] are the
only current effective methods. Other methods discussed in this
section may protect the payload, but either only a subset of the
fields (e.g. tcpcrypt) or none at all (e.g. TLS). Other security
features that have been added to TCP (e.g. ISN generation, sequence
number checks, etc.) are only capable of partially hindering attacks.
Applications using long-lived TCP flows have been vulnerable to Applications using long-lived TCP flows have been vulnerable to
attacks that exploit the processing of control flags described in attacks that exploit the processing of control flags described in
earlier TCP specifications [20]. TCP-MD5 was a commonly implemented earlier TCP specifications [21]. TCP-MD5 was a commonly implemented
TCP option to support authentication for some of these connections, TCP option to support authentication for some of these connections,
but had flaws and is now deprecated. The TCP Authentication Option but had flaws and is now deprecated. TCP-AO provides a capability to
(TCP AO) [26] provides a capability to protect long-lived TCP protect long-lived TCP connections from attacks, and has superior
connections from attacks, and has superior properties to TCP-MD5. It properties to TCP-MD5. It does not provide any privacy for
does not provide any privacy for application data, nor for the TCP application data, nor for the TCP headers.
headers.
The "tcpcrypt" [43]Experimental extension to TCP provides the ability The "tcpcrypt" [44]Experimental extension to TCP provides the ability
to cryptographically protect connection data. Metadata aspects of to cryptographically protect connection data. Metadata aspects of
the TCP flow are still visible, but the application stream is well- the TCP flow are still visible, but the application stream is well-
protected. Within the TCP header, only the urgent pointer and FIN protected. Within the TCP header, only the urgent pointer and FIN
flag are protected through tcpcrypt. flag are protected through tcpcrypt.
The TCP Roadmap [36] includes notes about several RFCs related to TCP The TCP Roadmap [37] includes notes about several RFCs related to TCP
security. Many of the enhancements provided by these RFCs have been security. Many of the enhancements provided by these RFCs have been
integrated into the present document, including ISN generation, integrated into the present document, including ISN generation,
mitigating blind in-window attacks, and improving handling of soft mitigating blind in-window attacks, and improving handling of soft
errors and ICMP packets. These are all discussed in greater detail errors and ICMP packets. These are all discussed in greater detail
in the referenced RFCs that originally described the changes needed in the referenced RFCs that originally described the changes needed
to earlier TCP specifications. Additionally, see RFC 6093 [28] for to earlier TCP specifications. Additionally, see RFC 6093 [29] for
discussion of security considerations related to the urgent pointer discussion of security considerations related to the urgent pointer
field, that has been deprecated. field, that has been deprecated.
Since TCP is often used for bulk transfer flows, some attacks are Since TCP is often used for bulk transfer flows, some attacks are
possible that abuse the TCP congestion control logic. An example is possible that abuse the TCP congestion control logic. An example is
"ACK-division" attacks. Updates that have been made to the TCP "ACK-division" attacks. Updates that have been made to the TCP
congestion control specifications include mechanisms like Appropriate congestion control specifications include mechanisms like Appropriate
Byte Counting (ABC) that act as mitigations to these attacks. Byte Counting (ABC) that act as mitigations to these attacks.
Other attacks are focused on exhausting the resources of a TCP Other attacks are focused on exhausting the resources of a TCP
server. Examples include SYN flooding [19] or wasting resources on server. Examples include SYN flooding [20] or wasting resources on
non-progressing connections [30]. Operating systems commonly non-progressing connections [31]. Operating systems commonly
implement mitigations for these attacks. Some common defenses also implement mitigations for these attacks. Some common defenses also
utilize proxies, stateful firewalls, and other technologies outside utilize proxies, stateful firewalls, and other technologies outside
of the end-host TCP implementation. of the end-host TCP implementation.
7. Acknowledgements 7. Acknowledgements
This document is largely a revision of RFC 793, which Jon Postel was This document is largely a revision of RFC 793, which Jon Postel was
the editor of. Due to his excellent work, it was able to last for the editor of. Due to his excellent work, it was able to last for
three decades before we felt the need to revise it. three decades before we felt the need to revise it.
skipping to change at page 94, line 28 skipping to change at page 94, line 46
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[15] Almquist, P., "Type of Service in the Internet Protocol [15] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992,
<https://www.rfc-editor.org/info/rfc1349>. <https://www.rfc-editor.org/info/rfc1349>.
[16] Braden, R., "T/TCP -- TCP Extensions for Transactions [16] Braden, R., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, DOI 10.17487/RFC1644, Functional Specification", RFC 1644, DOI 10.17487/RFC1644,
July 1994, <https://www.rfc-editor.org/info/rfc1644>. July 1994, <https://www.rfc-editor.org/info/rfc1644>.
[17] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP [17] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner,
J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known
TCP Implementation Problems", RFC 2525,
DOI 10.17487/RFC2525, March 1999,
<https://www.rfc-editor.org/info/rfc2525>.
[18] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP
Processing of the IPv4 Precedence Field", RFC 2873, Processing of the IPv4 Precedence Field", RFC 2873,
DOI 10.17487/RFC2873, June 2000, DOI 10.17487/RFC2873, June 2000,
<https://www.rfc-editor.org/info/rfc2873>. <https://www.rfc-editor.org/info/rfc2873>.
[18] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [19] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[19] Eddy, W., "TCP SYN Flooding Attacks and Common [20] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>. <https://www.rfc-editor.org/info/rfc4987>.
[20] Touch, J., "Defending TCP Against Spoofing Attacks", [21] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, DOI 10.17487/RFC4953, July 2007, RFC 4953, DOI 10.17487/RFC4953, July 2007,
<https://www.rfc-editor.org/info/rfc4953>. <https://www.rfc-editor.org/info/rfc4953>.
[21] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. [22] Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
Carrier, "Marker PDU Aligned Framing for TCP Carrier, "Marker PDU Aligned Framing for TCP
Specification", RFC 5044, DOI 10.17487/RFC5044, October Specification", RFC 5044, DOI 10.17487/RFC5044, October
2007, <https://www.rfc-editor.org/info/rfc5044>. 2007, <https://www.rfc-editor.org/info/rfc5044>.
[22] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, [23] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
DOI 10.17487/RFC5461, February 2009, DOI 10.17487/RFC5461, February 2009,
<https://www.rfc-editor.org/info/rfc5461>. <https://www.rfc-editor.org/info/rfc5461>.
[23] StJohns, M., Atkinson, R., and G. Thomas, "Common [24] StJohns, M., Atkinson, R., and G. Thomas, "Common
Architecture Label IPv6 Security Option (CALIPSO)", Architecture Label IPv6 Security Option (CALIPSO)",
RFC 5570, DOI 10.17487/RFC5570, July 2009, RFC 5570, DOI 10.17487/RFC5570, July 2009,
<https://www.rfc-editor.org/info/rfc5570>. <https://www.rfc-editor.org/info/rfc5570>.
[24] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [25] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[25] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [26] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010, DOI 10.17487/RFC5795, March 2010,
<https://www.rfc-editor.org/info/rfc5795>. <https://www.rfc-editor.org/info/rfc5795>.
[26] Touch, J., Mankin, A., and R. Bonica, "The TCP [27] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[27] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [28] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, Robustness to Blind In-Window Attacks", RFC 5961,
DOI 10.17487/RFC5961, August 2010, DOI 10.17487/RFC5961, August 2010,
<https://www.rfc-editor.org/info/rfc5961>. <https://www.rfc-editor.org/info/rfc5961>.
[28] Gont, F. and A. Yourtchenko, "On the Implementation of the [29] Gont, F. and A. Yourtchenko, "On the Implementation of the
TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,
January 2011, <https://www.rfc-editor.org/info/rfc6093>. January 2011, <https://www.rfc-editor.org/info/rfc6093>.
[29] Gont, F., "Reducing the TIME-WAIT State Using TCP [30] Gont, F., "Reducing the TIME-WAIT State Using TCP
Timestamps", BCP 159, RFC 6191, DOI 10.17487/RFC6191, Timestamps", BCP 159, RFC 6191, DOI 10.17487/RFC6191,
April 2011, <https://www.rfc-editor.org/info/rfc6191>. April 2011, <https://www.rfc-editor.org/info/rfc6191>.
[30] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender [31] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender
Clarification for Persist Condition", RFC 6429, Clarification for Persist Condition", RFC 6429,
DOI 10.17487/RFC6429, December 2011, DOI 10.17487/RFC6429, December 2011,
<https://www.rfc-editor.org/info/rfc6429>. <https://www.rfc-editor.org/info/rfc6429>.
[31] Gont, F. and S. Bellovin, "Defending against Sequence [32] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <https://www.rfc-editor.org/info/rfc6528>. 2012, <https://www.rfc-editor.org/info/rfc6528>.
[32] Borman, D., "TCP Options and Maximum Segment Size (MSS)", [33] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
RFC 6691, DOI 10.17487/RFC6691, July 2012, RFC 6691, DOI 10.17487/RFC6691, July 2012,
<https://www.rfc-editor.org/info/rfc6691>. <https://www.rfc-editor.org/info/rfc6691>.
[33] Touch, J., "Shared Use of Experimental TCP Options", [34] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013, RFC 6994, DOI 10.17487/RFC6994, August 2013,
<https://www.rfc-editor.org/info/rfc6994>. <https://www.rfc-editor.org/info/rfc6994>.
[34] Borman, D., Braden, B., Jacobson, V., and R. [35] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance", Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014, RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>. <https://www.rfc-editor.org/info/rfc7323>.
[35] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [36] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[36] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [37] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414, (TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015, DOI 10.17487/RFC7414, February 2015,
<https://www.rfc-editor.org/info/rfc7414>. <https://www.rfc-editor.org/info/rfc7414>.
[37] Black, D., Ed. and P. Jones, "Differentiated Services [38] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, DOI 10.17487/RFC7657, November 2015,
<https://www.rfc-editor.org/info/rfc7657>. <https://www.rfc-editor.org/info/rfc7657>.
[38] Fairhurst, G. and M. Welzl, "The Benefits of Using [39] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087, Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017, DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>. <https://www.rfc-editor.org/info/rfc8087>.
[39] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [40] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/info/rfc8095>. <https://www.rfc-editor.org/info/rfc8095>.
[40] IANA, "Transmission Control Protocol (TCP) Parameters, [41] IANA, "Transmission Control Protocol (TCP) Parameters,
https://www.iana.org/assignments/tcp-parameters/ https://www.iana.org/assignments/tcp-parameters/
tcp-parameters.xhtml", 2017. tcp-parameters.xhtml", 2017.
[41] Gont, F., "Processing of IP Security/Compartment and [42] Gont, F., "Processing of IP Security/Compartment and
Precedence Information by TCP", draft-gont-tcpm-tcp- Precedence Information by TCP", draft-gont-tcpm-tcp-
seccomp-prec-00 (work in progress), March 2012. seccomp-prec-00 (work in progress), March 2012.
[42] Gont, F. and D. Borman, "On the Validation of TCP Sequence [43] Gont, F. and D. Borman, "On the Validation of TCP Sequence
Numbers", draft-gont-tcpm-tcp-seq-validation-02 (work in Numbers", draft-gont-tcpm-tcp-seq-validation-02 (work in
progress), March 2015. progress), March 2015.
[43] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, [44] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic protection of TCP Streams Q., and E. Smith, "Cryptographic protection of TCP Streams
(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-09 (work in (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-09 (work in
progress), November 2017. progress), November 2017.
[44] Minshall, G., "A Proposed Modification to Nagle's [45] Minshall, G., "A Proposed Modification to Nagle's
Algorithm", draft-minshall-nagle-01 (work in progress), Algorithm", draft-minshall-nagle-01 (work in progress),
June 1999. June 1999.
Appendix A. Other Implementation Notes Appendix A. Other Implementation Notes
This section includes additional notes and references on TCP This section includes additional notes and references on TCP
implementation decisions that are currently not a part of the RFC implementation decisions that are currently not a part of the RFC
series or included within the TCP standard. These items can be series or included within the TCP standard. These items can be
considered by implementers, but there was not yet a consensus to considered by implementers, but there was not yet a consensus to
include them in the standard. include them in the standard.
A.1. IP Security Compartment and Precedence A.1. IP Security Compartment and Precedence
RFC 793 requires checking the IP security compartment and precedence RFC 793 requires checking the IP security compartment and precedence
on incoming TCP segments for consistency within a connection, and on incoming TCP segments for consistency within a connection, and
with application requests. Each of these aspects of IP have become with application requests. Each of these aspects of IP have become
outdated, without specific updates to RFC 793. The issues with outdated, without specific updates to RFC 793. The issues with
precedence were fixed by [17] which is Standards Track, and so this precedence were fixed by [18] which is Standards Track, and so this
present TCP specification includes those changes. However, the state present TCP specification includes those changes. However, the state
of IP security options that may be used by MLS systems is not as of IP security options that may be used by MLS systems is not as
clean. clean.
Implementers of MLS systems that use IP security options (e.g. IPSO, Implementers of MLS systems that use IP security options (e.g. IPSO,
CIPSO, or CALIPSO) should implement any additional logic appropriate CIPSO, or CALIPSO) should implement any additional logic appropriate
for their requirements. for their requirements.
Reseting connections when incoming packets do not meet expected Reseting connections when incoming packets do not meet expected
security compartment or precedence expectations has been recognized security compartment or precedence expectations has been recognized
as a possible attack vector [41], and there has been discussion about as a possible attack vector [42], and there has been discussion about
ammending the TCP specification to prevent connections from being ammending the TCP specification to prevent connections from being
aborted due to non-matching IP security compartment and DiffServ aborted due to non-matching IP security compartment and DiffServ
codepoint values. codepoint values.
A.2. Sequence Number Validation A.2. Sequence Number Validation
There are cases where the TCP sequence number validation rules can There are cases where the TCP sequence number validation rules can
prevent ACK fields from being processed. This can result in prevent ACK fields from being processed. This can result in
connection issues, as described in [42], which includes descriptions connection issues, as described in [43], which includes descriptions
of potential problems in conditions of simultaneous open, self- of potential problems in conditions of simultaneous open, self-
connects, simultaneous close, and simultaneous window probes. The connects, simultaneous close, and simultaneous window probes. The
document also describes potential changes to the TCP specification to document also describes potential changes to the TCP specification to
mitigate the issue by expanding the acceptable sequence numbers. mitigate the issue by expanding the acceptable sequence numbers.
In Internet usage of TCP, these conditions are rarely occuring. In Internet usage of TCP, these conditions are rarely occuring.
Common operating systems include different alternative mitigations, Common operating systems include different alternative mitigations,
and the standard has not been updated yet to codify one of them, but and the standard has not been updated yet to codify one of them, but
implementers should consider the problems described in [42]. implementers should consider the problems described in [43].
A.3. Nagle Modification A.3. Nagle Modification
In common operating systems, both the Nagle algorithm and delayed In common operating systems, both the Nagle algorithm and delayed
acknowledgements are implemented and enabled by default. TCP is used acknowledgements are implemented and enabled by default. TCP is used
by many applications that have a request-response style of by many applications that have a request-response style of
communication, where the combination of the Nagle algorithm and communication, where the combination of the Nagle algorithm and
delayed acknowledgements can result in poor application performance. delayed acknowledgements can result in poor application performance.
A modification to the Nagle algorithm is described in [44] that A modification to the Nagle algorithm is described in [45] that
improves the situation for these applications. improves the situation for these applications.
This modification is implemented in some common operating systems, This modification is implemented in some common operating systems,
and does not impact TCP interoperability. Additionally, many and does not impact TCP interoperability. Additionally, many
applications simply disable Nagle, since this is generally supported applications simply disable Nagle, since this is generally supported
by a socket option. The TCP standard has not been updated to include by a socket option. The TCP standard has not been updated to include
this Nagle modification, but implementers may find it beneficial to this Nagle modification, but implementers may find it beneficial to
consider. consider.
A.4. Low Water Mark A.4. Low Water Mark
 End of changes. 88 change blocks. 
120 lines changed or deleted 159 lines changed or added

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