TCP RST Diagnostic PayloadOrangeRennes35000Francemohamed.boucadair@orange.comNokiaIndiakondtir@gmail.comtcpmThis document specifies a diagnostic payload format to be returned in
TCP RST segments. Such payloads are used to share with the endpoints the
reasons for which a TCP connection has been reset. This is meant to ease
diagnostic and troubleshooting.A TCP connection can be reset by a
peer for various reasons, e.g., received data does not correspond to an
active connection. Also, a TCP connection can be reset by an on-path
service function (e.g., CGN , NAT64 , or firewall) for several reasons. Typically, a
Network Address Translator (NAT) function can generate an RST segment to
notify the endpoints upon the expiry of the lifetime of the
corresponding mapping entry or because an RST segment was received from
a peer (Section 2.2 of ). A TCP connection
can also be closed by a user or an application at any time. However, the
peer that receives an RST segment does not have any hint about the
reason that led to terminating the connection. Likewise, the application
that relies upon such a TCP connection may not easily identify the
reason for the connection closure. Troubleshooting such events at the
remote side of the connection that receives the RST segment may not be
trivial.This document fills this void by specifying a format of the
diagnostic payload that is returned in an RST segment. Returning such
data is consistent with the provision in Section 3.5.3 of for RST segments, especially: "TCP implementations SHOULD allow a received RST segment to
include data (SHLD-2)."This document does not change the conditions under which an RST
segment is generated (Section 3.5.2 of ).The generic procedure for processing an RST segment is specified in
Section 3.5.3 of . Only the deviations
from that procedure to insert and validate an enclosed diagnostic
payload is provided in . provides a set of examples to illustrate the
use of TCP RST diagnostic payloads.This document specifies the format and the overall approach to ease
maintaining the list of codes while allowing for adding new codes as
needed in the future and accommodating any existing vendor-specific
codes. An initial version of error codes is available in . However, the authoritative source to retrieve
the full list of error codes is the IANA-maintained registry .Preliminary investigation based on some major CGN vendors revealed
that RSTs with data are not discarded and are translated according to
any matching mapping entry. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and
only when, they appear in all capitals, as shown here.This document makes use of the terms defined in Section 4 of .The RST diagnostic payload MUST be encoded using Concise Binary
Object Representation (CBOR) Sequence .
The Concise Data Definition Language (CDDL) for the diagnostic payload is as
follows:The RST diagnostic payload comprises a magic cookie that is used to
unambiguously identify an RST payload that follows this specification.
It MUST be set to the RFC number to be assigned to this document. Note to the RFC Editor: Please replace "12345" with the RFC
number assigned to this document.All parameters in the reason component of an RST diagnostic payload
are mapped to their CBOR key values as specified in . The description of these parameters is as follows:
This parameter takes a value from an
available registry such as the "TCP Failure Causes" registry ().Includes a Private Enterprise Number . This parameter MAY be
included when the reason code is not taken from the IANA-maintained
registry (), but from a vendor-specific
registry.Includes a brief description of
the reset reason encoded as UTF-8 .
This parameter SHOULD NOT be included if a reason code is supplied.
This parameter is useful only for reset reasons that are not yet
registered or for application-specific reset reasons.At least one of "reason-code" and "reason-description" parameters
MUST be included in an RST diagnostic payload. The "pen" parameter MUST
be omitted if a reason code from the IANA-maintained registry () fits the reset case.Malformed RST diagnostic payload messages that include the magic
cookie MUST be silently ignored by the receiver.A peer that receives a valid diagnostic payload may pass the reset
reason information to the local application in addition to the
information (MUST-12) described in Section 3.6 of . That information may also be logged locally,
unless a local policy specifies otherwise. How the information is passed
to an application and how it is stored locally is implementation
specific.As per Section 3.6 of , one or more RST
segments can be sent to reset a connection. Whether a TCP endpoint
elects to send more than one RST with only a subset of them that include
the diagnostic payload is implementation specific. To ease readability, the CBOR diagnostic notation (Section 8 of ) with the parameter names rather than their
CBOR key values in is used in Figures , , , and
. depicts an example of the RST diagnostic
payload that is generated to inform the peer that the TCP connection is
reset because an ACK was received from that peer while the connection is
still in the LISTEN state (Section 3.10.7.2 of ). depicts the same RST diagnostic payload as
the one shown in but following the CBOR
diagnostic notation. shows an example of an RST diagnostic
payload that includes a free description to report a case that is not
covered by an appropriate code from the IANA-maintained registry ().An RST diagnostic payload may also be sent by an on-path service
function. For example, the following diagnostic payload is returned by a
NAT upon expiry of the mapping entry to which the TCP connection is
bound (). illustrates the RST diagnostic payload
that is returned by a peer that resets a TCP connection for a reason
code 1234 defined by a vendor with the private enterprise number
32473. uses the Enterprise Number 32473 defined
for documentation use .IANA is requested to create a new subregistry titled "RST
Diagnostic Payload CBOR Key Values" under the "Transmission Control
Protocol (TCP) Parameters" registry .The key value MUST be an integer in the 1-255 range.The assignment policy for this registry is "IETF Review" (Section
4.8 of ).The structure of this subregistry and the initial values are
provided below:This document requests IANA to create a new subregistry entitled
"TCP Failure Causes" under the "Transmission Control Protocol (TCP)
Parameters" registry .Values are taken from the 1-65535 range.The assignment policy for this registry is "Expert Review" (Section
4.5 of ).The designated experts may approve registration once they checked
that the new requested code is not covered by an existing code and if
the provided reasoning to register the new code is acceptable. A
registration request may supply a pointer to a specification where
that code is defined. However, a registration may be accepted even if
no permanent and readily available public specification is
available.The registry is initially populated with the following values:ValueDescriptionSpecification (if available)1New data is received after CLOSE is calledSections 3.6.1 and 3.10.7.1 of 2Received ACK while the connection is still in the LISTEN
stateSection 3.10.7.2 of 3Illegal OptionSection 3.1 of 4Malformed Message[ThisDocument]5Not Authorized[ThisDocument]6Resource Exceeded[ThisDocument]7Network Failure[ThisDocument]8Reset received from the peer[ThisDocument]9Destination Unreachable[ThisDocument]10Connection Timeout.[ThisDocument]11Too much outstanding dataSection 3.6 of 12Unacceptable performanceSection 3.6 of 12Middlebox interferenceSection 3.6 of Note that codes in the 6-10 range can be used by service functions
such as translators. discusses TCP-related security
considerations. In particular, RST-specific attacks and their
mitigations are discussed in Section 3.10.7.3 of .In addition to these considerations, it is RECOMMENDED to control the
size of acceptable diagnostic payload and keep it as brief as possible.
The RECOMMENDED acceptable maximum size of the RST diagnostic payload is
255 octets.Also, it is RECOMMENDED to avoid leaking privacy-related information
as part of the diagnostic payload (e.g., including a description such as
"user X resets explicitly the connection" is not recommended). The
"reason-description" string, when present, should not include any
private information that an observer would not otherwise have access
to.The presence of vendor-specific reason codes () may be used to fingerprint hosts. Such a concern
does not apply if the reason codes are taken from the IANA-maintained
registry. Implementers are, thus, encouraged to register new codes
within IANA instead of maintaining specific registries.The reason description, when present, is not intended to be displayed
to end users, but to be consumed by applications. Such a description may
carry a malicious message to mislead the end-user.The "diagnostic payload" name is inspired by Section 5.5.2 of that was cited by Carsten Bormann in the tcpm
mailing list.Thanks to Jon Shallow for the comments.Private Enterprise NumbersTransmission Control Protocol (TCP) ParametersIANA YANG