TCP RST Diagnostic Payload

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 29 August 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

A TCP connection [RFC9293] 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., Carrier Grade NAT (CGN) [RFC6888], NAT64 [RFC6146], or firewall) for several reasons. Typically, a Network Address Translator (NAT) function can generate an RST segment to notify an endpoint 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 [RFC7857]). 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 [RFC9293] 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 [RFC9293]).¶

The generic procedure for processing an RST segment is specified in Section 3.5.3 of [RFC9293]. Only the deviations from that procedure to insert and validate a diagnostic payload is provided in Section 3. Section 4 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 Table 1. However, the authoritative source to retrieve the full list of error codes is the IANA-maintained registry Section 5.2.¶

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

2. Terminology

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document makes use of the terms defined in Section 4 of [RFC9293].¶

3. RST Diagnostic Payload

The RST diagnostic payload MUST be encoded using Concise Binary Object Representation (CBOR) Sequence [RFC8742]. The Concise Data Definition Language (CDDL) [RFC8610] for the diagnostic payload is shown in Figure 1.¶

   ; This defines an array, the elements of which are to be used
   ; in a CBOR Sequence. There is exactly one occurrence.
   diagnostic-payload = [magic-cookie, reason]
   ; Magic cookie to identify a payload that follows this specification
   magic-cookie = 12345
   ; Reset reason details:
   reason= {
     ? reason-code: uint,
     ? pen:uint,
     ? reason-description: tstr,
   }

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 Section 5.1. The description of these parameters is as follows:¶

reason-code:

This parameter takes a value from an available registry such as the "TCP Failure Causes" registry (Section 5.2).¶

pen:

Includes a Private Enterprise Number [Private-Enterprise-Numbers]. This parameter MAY be included when the reason code is not taken from the IANA-maintained registry (Section 5.2), but from a vendor-specific registry.¶

reason-description:

Includes a brief description of the reset reason encoded as UTF-8 [RFC3629]. 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 (Section 5.2) 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 [RFC9293]. 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 [RFC9293], 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.¶

4. Some Examples

To ease readability, the CBOR diagnostic notation (Section 8 of [RFC8949]) with the parameter names rather than their CBOR key values in Section 5.1 is used in Figures 3, 4, 5, and 6.¶

Figure 2 depicts an example of an 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 [RFC9293]).¶

19 3039 # unsigned(12345)
A1    # map(1)
   01 # unsigned(1)
   02 # unsigned(2)

Figure 3 depicts the same RST diagnostic payload as the one shown in Figure 2 but following the CBOR diagnostic notation.¶

[
  12345,
  {
    "reason-code": 2
  }
]

Figure 4 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 (Section 5.2).¶

[
  12345,
  {
    "reason-description": "brief human-readable description"
  }
]

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 function upon expiry of the mapping entry to which the TCP connection is bound (Figure 5).¶

[
  12345,
  {
    "reason-code": 8
  }
]

Figure 6 illustrates 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.¶

[
  12345,
  {
    "reason-code": 1234,
    "pen": 32473
  }
]

Figure 6 uses the Enterprise Number 32473 defined for documentation use [RFC5612].¶

5. IANA Considerations

+--------------------+------+---------------+--------------+
| Parameter Name     | CBOR | CBOR Major    | Reference    |
|                    | Key  |    Type &     |              |
|                    |      | Information   |              |
+====================+======+===============+==============+
| reason-code        |   1  | 0 unsigned    |[ThisDocument]|
| pen                |   2  | 0 unsigned    |[ThisDocument]|
| reason-description |   3  | 3 text string |[ThisDocument]|
+====================+======+===============+==============+

6. Security Considerations

[RFC9293] discusses TCP-related security considerations. In particular, RST-specific attacks and their mitigations are discussed in Section 3.10.7.3 of [RFC9293].¶

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 (Section 3) 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.¶

7. Acknowledgements

The "diagnostic payload" name is inspired by Section 5.5.2 of [RFC7252] that was cited by Carsten Bormann in the tcpm mailing list.¶

Thanks to Jon Shallow for the comments.¶

Authors' Addresses