TCP RST Diagnostic PaylaodOrangeRennes35000Francemohamed.boucadair@orange.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 ,
firewall) for several reasons. Typically, a NAT function can generate an
RST segment to notify the peers 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 a 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.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 .The first version of the specification is meant to discuss 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 at . However, the authoritative
source to retrieve the full list of error codes is the IANA-maintained
registry .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 .In order to unambiguously identify an RST diagnostic payload that is
compliant with the present specification, the payload MUST use the
I-JSON message format . The following
parameters are defined: Stands for "Reason Code". This parameter takes a
value from an available registry such as the "TCP Failure Causes"
registry ().Includes a Private Enterprise Number . This attribute is
included when the reason code is not taken from the IANA-maintained
registry (), but from a vendor-specific
registry.Stands for "Reason Description". It includes a
brief description of the reason code. This parameter SHOULD NOT be
included if a reason code is supplied. This parameter is useful only
for codes that are not yet registered or for application-specific
codes.At least "rc" and "rd" parameters MUST be included in an RST
diagnostic payload. It is RECOMMENDED to omit "pen" if a reason code
from the IANA-maintained registry () fits the
reset case.Malformed RST diagnostic payload messages MUST be silently ignored by
the receiver.A peer that receives a valid diagnostic payload may pass that
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. depicts an example of an RST diagnostic
payload that is generated to inform the peer that the connection is
reset because an ACK was received while the connection is still in the
LISTEN state. shows an example of an RST diagnostic
payload that includes a free description to report a case that is not
covered yet by the IANA-maintained registry ().An RST diagnostic payload may also be reset by an on-path service
function. For example, the following diagnostic payload is returned by a
NAT uppon expiry of the mapping entry to which the TCP connection is
bound (). illustrates the example of an 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 .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 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)1Data lost. New data is received after CLOSE is calledSections 3.6.1 and 3.10.7.1 of 2Still in LISTEN. Received ACK while the connection still in the
LISTEN stateSection 3.10.7.2 of 3Malformed Message[ThisDocument]4Not Authorized[ThisDocument]5Resource Exceeded[ThisDocument]6Network Failure. This code can be used by service functions such
as translators.[ThisDocument]7Connection Reset received from the peer. This code can be used by
service functions such as translators.[ThisDocument]8Destination Unreachable. This code can be used by service
functions such as translators.[ThisDocument]9Connection Timeout.This code can be used by service functions
such as translators.[ThisDocument] discusses TCP-related
security considerations. 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.
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).TBC.Private Enterprise NumbersTransmission Control Protocol (TCP) ParametersIANA YANG