< draft-boucadair-tcpm-rst-diagnostic-payload-03.txt   draft-boucadair-tcpm-rst-diagnostic-payload-04.txt >
tcpm M. Boucadair tcpm M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track 12 April 2022 Intended status: Standards Track T. Reddy
Expires: 14 October 2022 Expires: 21 October 2022 Akamai
19 April 2022
TCP RST Diagnostic Payload TCP RST Diagnostic Payload
draft-boucadair-tcpm-rst-diagnostic-payload-03 draft-boucadair-tcpm-rst-diagnostic-payload-04
Abstract Abstract
This document specifies a diagnostic payload format to be returned in This document specifies a diagnostic payload format to be returned in
TCP RST segments. Such payloads are used to share with the endpoints 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 the reasons for which a TCP connection has been reset. This is meant
to ease diagnostic and troubleshooting. to ease diagnostic and troubleshooting.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 34
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 14 October 2022. This Internet-Draft will expire on 21 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 13 skipping to change at page 2, line 13
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RST Diagnostic Payload . . . . . . . . . . . . . . . . . . . 3 3. RST Diagnostic Payload . . . . . . . . . . . . . . . . . . . 3
4. Some Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Some Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. RST Diagnostic Payload CBOR Key Values . . . . . . . . . 6 5.1. RST Diagnostic Payload CBOR Key Values . . . . . . . . . 6
5.2. New Registry for TCP Failure Causes . . . . . . . . . . . 6 5.2. New Registry for TCP Failure Causes . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
A TCP connection [I-D.ietf-tcpm-rfc793bis] can be reset by a peer for A TCP connection [I-D.ietf-tcpm-rfc793bis] can be reset by a peer for
various reasons, e.g., received data does not correspond to an active various reasons, e.g., received data does not correspond to an active
connection. Also, a TCP connection can be reset by an on-path connection. Also, a TCP connection can be reset by an on-path
service function (e.g., CGN [RFC6888], NAT64 [RFC6146], firewall) for service function (e.g., CGN [RFC6888], NAT64 [RFC6146], firewall) for
several reasons. Typically, a NAT function can generate an RST several reasons. Typically, a NAT function can generate an RST
segment to notify the peers upon the expiry of the lifetime of the segment to notify the peers upon the expiry of the lifetime of the
corresponding mapping entry or because an RST segment was received corresponding mapping entry or because an RST segment was received
skipping to change at page 3, line 30 skipping to change at page 3, line 30
This document makes use of the terms defined in Section 4 of This document makes use of the terms defined in Section 4 of
[I-D.ietf-tcpm-rfc793bis]. [I-D.ietf-tcpm-rfc793bis].
3. RST Diagnostic Payload 3. RST Diagnostic Payload
The RST diagnostic payload MUST be encoded using Concise Binary The RST diagnostic payload MUST be encoded using Concise Binary
Object Representation (CBOR) Sequence [RFC8742]. The Concise Data Object Representation (CBOR) Sequence [RFC8742]. The Concise Data
Definition Language (CDDL) [RFC8610] for the diagnostic payload is as Definition Language (CDDL) [RFC8610] for the diagnostic payload is as
follows: follows:
; This defines an array, the elements of which are to be used ; This defines an array, the elements of which are to be used
; in a CBOR Sequence: ; in a CBOR Sequence. There is exactly one occurrence.
diagnostic-payload = [magic-word, reason] diagnostic-payload = [magic-cookie, reason]
; Magic word to identify a payload that follows this specification ; Magic cookie to identify a payload that follows this specification
magic-word = 12345 magic-cookie = 12345
; Reset reason details: ; Reset reason details:
reason= { reason= {
? reason-code: uint, ? reason-code: uint,
? pen:uint, ? pen:uint,
? reason-description: tstr, ? reason-description: tstr,
} }
Figure 1: Structure of the RST Diagnostic Payload Figure 1: Structure of the RST Diagnostic Payload
The RST diagnostic payload comprises a magic word that is used to The RST diagnostic payload comprises a magic cookie that is used to
unambiguously identify an RST payload that follows this unambiguously identify an RST payload that follows this
specification. It MUST be set to the RFC number to be assigned to specification. It MUST be set to the RFC number to be assigned to
this document. this document.
Note to the RFC Editor: Please replace "12345" with the RFC number Note to the RFC Editor: Please replace "12345" with the RFC number
assigned to this document. assigned to this document.
All parameters in the reason component of an RST diagnostic payload 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 are mapped to their CBOR key values as specified in Section 5.1. The
description of these parameters is as follows: description of these parameters is as follows:
reason-code: This parameter takes a value from an available registry reason-code: This parameter takes a value from an available registry
such as the "TCP Failure Causes" registry (Section 5.2). such as the "TCP Failure Causes" registry (Section 5.2).
pen: Includes a Private Enterprise Number pen: Includes a Private Enterprise Number
[Private-Enterprise-Numbers]. This parameter is included when the [Private-Enterprise-Numbers]. This parameter MAY be included when
reason code is not taken from the IANA-maintained registry the reason code is not taken from the IANA-maintained registry
(Section 5.2), but from a vendor-specific registry. (Section 5.2), but from a vendor-specific registry.
reason-description: It includes a brief description of the reset reason-description: It includes a brief description of the reset
reason. This parameter SHOULD NOT be included if a reason code is reason encoded as UTF-8 [RFC3629]. This parameter SHOULD NOT be
supplied. This parameter is useful only for reset reasons that included if a reason code is supplied. This parameter is useful
are not yet registered or for application-specific reasons. only for reset reasons that are not yet registered or for
application-specific reasons.
At least one of "reason-code" and "reason-description" parameters At least one of "reason-code" and "reason-description" parameters
MUST be included in an RST diagnostic payload. It is RECOMMENDED to MUST be included in an RST diagnostic payload. The "pen" parameter
omit "pen" if a reason code from the IANA-maintained registry MUST be omitted if a reason code from the IANA-maintained registry
(Section 5.2) fits the reset case. (Section 5.2) fits the reset case.
Malformed RST diagnostic payload messages that include the magic Malformed RST diagnostic payload messages that include the magic
number MUST be silently ignored by the receiver. cookie MUST be silently ignored by the receiver.
A peer that receives a valid diagnostic payload may pass the reset A peer that receives a valid diagnostic payload may pass the reset
reason information to the local application in addition to the reason information to the local application in addition to the
information (MUST-12) described in Section 3.6 of information (MUST-12) described in Section 3.6 of
[I-D.ietf-tcpm-rfc793bis]. That information may also be logged [I-D.ietf-tcpm-rfc793bis]. That information may also be logged
locally, unless a local policy specifies otherwise. How the locally, unless a local policy specifies otherwise. How the
information is passed to an application and how it is stored locally information is passed to an application and how it is stored locally
is implementation specific. is implementation specific.
4. Some Examples 4. Some Examples
skipping to change at page 5, line 20 skipping to change at page 5, line 25
[ [
12345, 12345,
{ {
"reason-code": 2 "reason-code": 2
} }
] ]
Figure 3: An RST Diagnostic Payload with Reason Code (Diagnostic Figure 3: An RST Diagnostic Payload with Reason Code (Diagnostic
Notation) Notation)
Figure 4 shows an example of RST diagnostic payload that includes a Figure 4 shows an example of an RST diagnostic payload that includes
free description to report a case that is not covered yet by the a free description to report a case that is not covered yet by the
IANA-maintained registry (Section 5.2). IANA-maintained registry (Section 5.2).
[ [
12345, 12345,
{ {
"reason-description": "brief human-readable description" "reason-description": "brief human-readable description"
} }
] ]
Figure 4: An RST Diagnostic Payload with Reason Description Figure 4: An RST Diagnostic Payload with Reason Description
(Diagnostic Notation) (Diagnostic Notation)
An RST diagnostic payload may also be reset by an on-path service An RST diagnostic payload may also be sent by an on-path service
function. For example, the following diagnostic payload is returned function. For example, the following diagnostic payload is returned
by a NAT upon expiry of the mapping entry to which the TCP connection by a NAT upon expiry of the mapping entry to which the TCP connection
is bound (Figure 5). is bound (Figure 5).
[ [
12345, 12345,
{ {
"reason-code": 8 "reason-code": 8
} }
] ]
skipping to change at page 8, line 5 skipping to change at page 8, line 5
The designated experts may approve registration once they checked The designated experts may approve registration once they checked
that the new requested code is not covered by an existing code and if 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 the provided reasoning to register the new code is acceptable. A
registration request may supply a pointer to a specification where registration request may supply a pointer to a specification where
that code is defined. However, a registration may be accepted even that code is defined. However, a registration may be accepted even
if no permanent and readily available public specification is if no permanent and readily available public specification is
available. available.
The registry is initially populated with the following values: The registry is initially populated with the following values:
+=======+===============================+===========================+ +=======+========================+==============================+
| Value | Description | Specification (if | | Value | Description | Specification (if available) |
| | | available) | +=======+========================+==============================+
+=======+===============================+===========================+ | 1 | New data is received | Sections 3.6.1 and 3.10.7.1 |
| 1 | Data lost. New data is | Sections 3.6.1 and | | | after CLOSE is called | of [I-D.ietf-tcpm-rfc793bis] |
| | received after CLOSE is | 3.10.7.1 of | +-------+------------------------+------------------------------+
| | called | [I-D.ietf-tcpm-rfc793bis] | | 2 | Received ACK while the | Section 3.10.7.2 of |
+-------+-------------------------------+---------------------------+ | | connection is still in | [I-D.ietf-tcpm-rfc793bis] |
| 2 | Still in LISTEN. | Section 3.10.7.2 of | | | the LISTEN state | |
| | Received ACK while the | [I-D.ietf-tcpm-rfc793bis] | +-------+------------------------+------------------------------+
| | connection still in the | | | 3 | Illegal Option | Section 3.1 of |
| | LISTEN state | | | | | [I-D.ietf-tcpm-rfc793bis] |
+-------+-------------------------------+---------------------------+ +-------+------------------------+------------------------------+
| 3 | Malformed Message | [ThisDocument] | | 4 | Malformed Message | [ThisDocument] |
+-------+-------------------------------+---------------------------+ +-------+------------------------+------------------------------+
| 4 | Not Authorized | [ThisDocument] | | 5 | Not Authorized | [ThisDocument] |
+-------+-------------------------------+---------------------------+ +-------+------------------------+------------------------------+
| 5 | Resource Exceeded | [ThisDocument] | | 6 | Resource Exceeded | [ThisDocument] |
+-------+-------------------------------+---------------------------+ +-------+------------------------+------------------------------+
| 6 | Network Failure. This | [ThisDocument] | | 7 | Network Failure | [ThisDocument] |
| | code can be used by | | +-------+------------------------+------------------------------+
| | service functions such | | | 8 | Reset received from | [ThisDocument] |
| | as translators. | | | | the peer | |
+-------+-------------------------------+---------------------------+ +-------+------------------------+------------------------------+
| 7 | Connection Reset | [ThisDocument] | | 9 | Destination | [ThisDocument] |
| | received from the peer. | | | | Unreachable | |
| | This code can be used | | +-------+------------------------+------------------------------+
| | by service functions | | | 10 | Connection Timeout. | [ThisDocument] |
| | such as translators. | | +-------+------------------------+------------------------------+
+-------+-------------------------------+---------------------------+ | 11 | Too much outstanding | Section 3.6 of [RFC8684] |
| 8 | Destination | [ThisDocument] | | | data | |
| | Unreachable. This code | | +-------+------------------------+------------------------------+
| | can be used by service | | | 12 | Unacceptable | Section 3.6 of [RFC8684] |
| | functions such as | | | | performance | |
| | translators. | | +-------+------------------------+------------------------------+
+-------+-------------------------------+---------------------------+ | 12 | Middlebox interference | Section 3.6 of [RFC8684] |
| 9 | Connection Timeout. | [ThisDocument] | +-------+------------------------+------------------------------+
| | This code can be used | |
| | by service functions | |
| | such as translators. | |
+-------+-------------------------------+---------------------------+
Table 1: Initial TCP Failure Causes Table 1: Initial TCP Failure Causes
Note that codes 6-10 can be used by service functions such as
translators.
6. Security Considerations 6. Security Considerations
[I-D.ietf-tcpm-rfc793bis] discusses TCP-related security [I-D.ietf-tcpm-rfc793bis] discusses TCP-related security
considerations. RST-specific attacks and their mitigations are considerations. RST-specific attacks and their mitigations are
discussed in Section 3.10.7.3 of [I-D.ietf-tcpm-rfc793bis]. discussed in Section 3.10.7.3 of [I-D.ietf-tcpm-rfc793bis].
In addition to these considerations, it is RECOMMENDED to control the In addition to these considerations, it is RECOMMENDED to control the
size of acceptable diagnostic payload and keep it as brief as size of acceptable diagnostic payload and keep it as brief as
possible. Also, it is RECOMMENDED to avoid leaking privacy-related possible. The RECOMMENDED acceptable maximum size of the RST
information as part of the diagnostic payload (e.g., including a diagnostic payload is 255 octets.
description such as "user X resets explicitly the connection" is not
recommended). 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 The presence of vendor-specific reason codes (Section 3) may be used
to fingerprint hosts. Such a concern does not apply if the reason to fingerprint hosts. Such a concern does not apply if the reason
codes are taken from the IANA-maintained registry. Implementers are, codes are taken from the IANA-maintained registry. Implementers are,
thus, encouraged to register new codes within IANA instead of thus, encouraged to register new codes within IANA instead of
maintaining specific registries. 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 7. Acknowledgements
The "diagnostic payload" name is inspired by Section 5.5.2 of The "diagnostic payload" name is inspired by Section 5.5.2 of
[RFC7252] that was cited by Carsten Bormann in the tcpm mailing list. [RFC7252] that was cited by Carsten Bormann in the tcpm mailing list.
Thanks to Jon Jon Shallow for the comments. Thanks to Jon Shallow for the comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-tcpm-rfc793bis] [I-D.ietf-tcpm-rfc793bis]
Eddy, W. M., "Transmission Control Protocol (TCP) Eddy, W. M., "Transmission Control Protocol (TCP)
Specification", Work in Progress, Internet-Draft, draft- Specification", Work in Progress, Internet-Draft, draft-
ietf-tcpm-rfc793bis-28, 7 March 2022, ietf-tcpm-rfc793bis-28, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-tcpm- <https://www.ietf.org/archive/id/draft-ietf-tcpm-
skipping to change at page 10, line 5 skipping to change at page 10, line 5
[Private-Enterprise-Numbers] [Private-Enterprise-Numbers]
"Private Enterprise Numbers", 4 May 2020, "Private Enterprise Numbers", 4 May 2020,
<https://www.iana.org/assignments/enterprise-numbers>. <https://www.iana.org/assignments/enterprise-numbers>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
8.2. Informative References 8.2. Informative References
skipping to change at page 11, line 16 skipping to change at page 11, line 21
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
S., and K. Naito, "Updates to Network Address Translation S., and K. Naito, "Updates to Network Address Translation
(NAT) Behavioral Requirements", BCP 127, RFC 7857, (NAT) Behavioral Requirements", BCP 127, RFC 7857,
DOI 10.17487/RFC7857, April 2016, DOI 10.17487/RFC7857, April 2016,
<https://www.rfc-editor.org/info/rfc7857>. <https://www.rfc-editor.org/info/rfc7857>.
Author's Address Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
35000 Rennes 35000 Rennes
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy
Akamai
Embassy Golf Link Business Park
Bangalore 560071
Karnataka
India
Email: kondtir@gmail.com
 End of changes. 23 change blocks. 
78 lines changed or deleted 97 lines changed or added

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