doc: Add RFC documents

1 files changed, 523 insertions, 0 deletions

diff --git a/doc/rfc/rfc9653.txt b/doc/rfc/rfc9653.txt
new file mode 100644
index 0000000..9b1d0c3
--- /dev/null
+++ b/doc/rfc/rfc9653.txt
@@ -0,0 +1,523 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          M. Tüxen
+Request for Comments: 9653               Münster Univ. of Appl. Sciences
+Category: Standards Track                                      V. Boivie
+ISSN: 2070-1721                                              F. Castelli
+                                                                  Google
+                                                                R. Jesup
+                                                                 Mozilla
+                                                          September 2024
+
+
+       Zero Checksum for the Stream Control Transmission Protocol
+
+Abstract
+
+   The Stream Control Transmission Protocol (SCTP) uses a 32-bit
+   checksum in the common header of each packet to provide some level of
+   data integrity.  If another method used by SCTP already provides the
+   same or a higher level of data integrity, computing this checksum
+   does not provide any additional protection but does consume computing
+   resources.
+
+   This document provides a simple extension allowing SCTP to save these
+   computing resources by using zero as the checksum in a backwards-
+   compatible way.  It also defines how this feature can be used when
+   SCTP packets are encapsulated in Datagram Transport Layer Security
+   (DTLS) packets.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9653.
+
+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
+   2.  Conventions
+   3.  Alternate Error Detection Methods
+   4.  A New Chunk Parameter
+   5.  Procedures
+     5.1.  Declaration of Feature Support
+     5.2.  Sender-Side Considerations
+     5.3.  Receiver-Side Considerations
+   6.  Error Detection via SCTP over DTLS
+   7.  Socket API Considerations
+     7.1.  Set Accepting a Zero Checksum (SCTP_ACCEPT_ZERO_CHECKSUM)
+   8.  IANA Considerations
+   9.  Security Considerations
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   SCTP as specified in [RFC9260] uses a CRC32c checksum to provide some
+   level of data integrity.  When using, for example, Datagram Transport
+   Layer Security (DTLS) as the lower layer for SCTP as specified in
+   [RFC8261], using the CRC32c checksum does not provide any additional
+   protection over that already provided by DTLS.  However, computing
+   the CRC32c checksum at the sender and receiver sides does consume
+   computational resources for no benefit.  This is particularly
+   important for endpoints that are computationally limited and use SCTP
+   over DTLS.
+
+   The extension described in this document allows an SCTP endpoint to
+   declare that it accepts SCTP packets with a checksum of zero when
+   using a specific alternate error detection method.  This declaration
+   happens during the setup of the SCTP association and allows endpoints
+   that support this extension to be interoperable with endpoints that
+   don't.  To provide this backwards compatibility, endpoints using this
+   extension still need to implement the CRC32c checksum algorithm.
+
+2.  Conventions
+
+   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.
+
+3.  Alternate Error Detection Methods
+
+   SCTP uses a CRC32c checksum to provide some level of data integrity.
+   The CRC32c checksum is computed based on the SCTP common header and
+   the chunks contained in the packet.  In particular, the computation
+   of the CRC32c checksum does not involve a pseudo header for IPv4 or
+   IPv6 like the computation of the TCP checksum, as specified in
+   [RFC9293], or the UDP checksum, as specified in [RFC0768].
+
+   Zero is a valid result of the CRC32c checksum algorithm.  For
+   example, the following figure depicts an SCTP packet containing a
+   minimal INIT chunk with a correct CRC32c checksum of zero.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Source Port Number = 5001   |Destination Port Number = 5001 |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                     Verification Tag = 0                      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                         Checksum = 0                          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Type = 1    |Chunk Flags = 0|       Chunk Length = 20       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                   Initiate Tag = 0xFCB75CCA                   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |       Advertised Receiver Window Credit (a_rwnd) = 1500       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |Number of Outbound Streams = 1 | Number of Inbound Streams = 1 |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                        Initial TSN = 0                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 1: SCTP Packet with a Correct CRC32c Checksum of Zero
+
+   Using SCTP in combination with other mechanisms or protocol
+   extensions might provide data integrity protection with an equal or
+   lower probability of false negatives than the one provided by using
+   the CRC32c checksum algorithm.  When using such alternate error
+   detection methods, the SCTP common header containing the 32-bit
+   checksum field might or might not be visible to middleboxes on the
+   paths between the two endpoints.
+
+   Alternate error detection methods have two requirements:
+
+   1.  An alternate error detection method MUST provide an equal or
+       lower probability of false negatives than the one provided by
+       using the CRC32c checksum algorithm.  This MAY only apply to
+       packets satisfying some method-specific constraints.
+
+   2.  Using an alternate error detection method MUST NOT result in a
+       path failure for more than two retransmission timeouts (RTOs) due
+       to middleboxes on the path expecting correct CRC32c checksums.
+
+   To fulfill the second requirement, alternate error detection methods
+   could use a heuristic to detect the existence of such middleboxes and
+   use correct CRC32c checksums on these affected paths.
+
+   Using DTLS as the lower layer of SCTP as specified in [RFC8261] is
+   one example that fulfills the first requirement.  Another example is
+   using SCTP Authentication as specified in [RFC4895].  Of course, this
+   only applies to each SCTP packet having an AUTH chunk as its first
+   chunk.  However, using SCTP Authentication without any heuristic does
+   not fulfill the second requirement.  Since using DTLS as the lower
+   layer of SCTP as specified in [RFC8261] also fulfills the second
+   requirement, it can be used as an alternate error detection method
+   (see Section 6).
+
+   If an alternate error detection method is used, the computation of
+   the CRC32c checksum consumes computational resources without
+   providing any benefit.  To avoid this, an SCTP endpoint could be
+   willing to accept SCTP packets with an incorrect CRC32c checksum
+   value of zero in addition to SCTP packets with correct CRC32c
+   checksum values.
+
+   Because zero is a valid result of the CRC32c checksum algorithm, a
+   receiver of an SCTP packet containing a checksum value of zero cannot
+   determine whether the sender included an incorrect CRC32c checksum of
+   zero to reduce the CPU cost or the result of the CRC32c checksum
+   computation was actually zero.  However, if the receiver is willing
+   to use an alternate error detection method, this ambiguity is
+   irrelevant, since the receiver is fine with not using the CRC32c
+   checksum to protect incoming packets.
+
+4.  A New Chunk Parameter
+
+   The Zero Checksum Acceptable Chunk Parameter is defined by the
+   following figure.
+
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          Type = 0x8001        |          Length = 8           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |           Error Detection Method Identifier (EDMID)           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 2: Zero Checksum Acceptable Chunk Parameter
+
+   Type: 16 bits (unsigned integer)
+      This field holds the IANA-defined parameter type for the "Zero
+      Checksum Acceptable" chunk parameter.  IANA has assigned the value
+      32769 (0x8001) for this parameter type.
+
+   Length: 16 bits (unsigned integer)
+      This field holds the length in bytes of the chunk parameter; the
+      value MUST be 8.
+
+   Error Detection Method Identifier (EDMID): 32 bits (unsigned
+   integer)
+      An IANA-registered value specifying the alternate error detection
+      method the sender of this parameter is willing to use for received
+      packets.
+
+   All transported integer numbers are in network byte order, a.k.a. big
+   endian.
+
+   The Zero Checksum Acceptable Chunk Parameter MAY appear in INIT and
+   INIT ACK chunks and MUST NOT appear in any other chunk.  The
+   Parameter MUST NOT appear more than once in any chunk.
+
+   If an endpoint not supporting the extension described in this
+   document receives this parameter in an INIT or INIT ACK chunk, it is
+   REQUIRED to skip this parameter and continue to process further
+   parameters in the chunk.  This behavior is specified by [RFC9260]
+   because the highest-order two bits of the Type are '10'.
+
+5.  Procedures
+
+5.1.  Declaration of Feature Support
+
+   An endpoint willing to accept SCTP packets with an incorrect checksum
+   of zero MUST include the Zero Checksum Acceptable Chunk Parameter
+   indicating the alternate error detection method it is willing to use
+   in the INIT or INIT ACK chunk it sends.
+
+   An SCTP implementation MAY also require the upper layer to indicate
+   that it is fine to use a specific alternate error detection method
+   before including the corresponding Zero Checksum Acceptable Chunk
+   Parameter.
+
+5.2.  Sender-Side Considerations
+
+   An SCTP endpoint cannot just use an incorrect CRC32c checksum value
+   of zero for all SCTP packets it sends.  The following restrictions
+   apply:
+
+   1.  If an endpoint has not received an INIT or INIT ACK chunk
+       containing a Zero Checksum Acceptable Chunk Parameter indicating
+       an alternate error detection method it supports from its peer
+       during the association setup, it MUST use a correct CRC32c
+       checksum.  In particular, when an endpoint
+
+       a.  sends a packet containing an INIT chunk, it MUST include a
+           correct CRC32c checksum in the packet containing the INIT
+           chunk.
+
+       b.  responds to an "Out of the Blue" (OOTB) SCTP packet, it MUST
+           include a correct CRC32c checksum in the response packet.
+
+   2.  When an endpoint sends a packet containing a COOKIE ECHO chunk,
+       it MUST include a correct CRC32c checksum in the packet
+       containing the COOKIE ECHO chunk.
+
+   3.  When an endpoint supports the dynamic address reconfiguration
+       specified in [RFC5061] and sends a packet containing an ASCONF
+       chunk, it MUST include a correct CRC32c checksum in the packet
+       containing the ASCONF chunk.
+
+   4.  If an alternate error detection method has some method-specific
+       constraints, the sender MUST include a correct CRC32c checksum in
+       all packets that don't fulfill these method-specific constraints.
+
+   The first restriction allows backwards compatibility.  The second and
+   third restrictions allow a simpler implementation of the extension
+   defined in this document, because looking up the association for SCTP
+   packets containing a COOKIE ECHO chunk or an ASCONF chunk might be
+   more complex than for other packets.  Finally, the last restriction
+   covers constraints specific to the alternate error detection method.
+
+   An SCTP endpoint MAY require that the upper layer allow the use of
+   the alternate error detection method that was announced by the peer
+   before sending packets with an incorrect checksum of zero.
+
+   If none of the above restrictions apply, an endpoint SHOULD use zero
+   as the checksum when sending an SCTP packet.
+
+5.3.  Receiver-Side Considerations
+
+   If an endpoint has sent the Zero Checksum Acceptable Chunk Parameter
+   indicating the support of an alternate error detection method in an
+   INIT or INIT ACK chunk, in addition to SCTP packets containing the
+   correct CRC32c checksum value it MUST accept SCTP packets that have
+   an incorrect checksum value of zero and that fulfill the requirements
+   of the announced alternate error detection method used for this
+   association.  Otherwise, the endpoint MUST drop all SCTP packets with
+   an incorrect CRC32c checksum.
+
+   In addition to processing OOTB packets with a correct CRC32c checksum
+   as specified in [RFC9260], an SCTP implementation MAY also process
+   OOTB packets having an incorrect zero checksum.  Doing so might
+   result in faster SCTP association failure detection.
+
+6.  Error Detection via SCTP over DTLS
+
+   Using SCTP over DTLS as specified in [RFC8261] provides a stronger
+   error detection method than using the CRC32c checksum algorithm.
+   Since middleboxes will not observe the unencrypted SCTP packet, there
+   is no risk in interfering with using zero as an incorrect checksum.
+   There are no additional constraints (specific to the error detection
+   method) on packets when using DTLS encapsulation.
+
+7.  Socket API Considerations
+
+   This section describes how the socket API defined in [RFC6458] needs
+   to be extended to provide a way for the application to control the
+   acceptance of a zero checksum.
+
+   A 'Socket API Considerations' section is contained in all SCTP-
+   related specifications published after [RFC6458] describing an
+   extension for which implementations using the socket API as specified
+   in [RFC6458] would require some extension of the socket API.  Please
+   note that this section is informational only.
+
+   A socket API implementation based on [RFC6458] is extended by
+   supporting one new write-only IPPROTO_SCTP-level socket option.
+
+7.1.  Set Accepting a Zero Checksum (SCTP_ACCEPT_ZERO_CHECKSUM)
+
+   This IPPROTO_SCTP-level socket option with the name
+   SCTP_ACCEPT_ZERO_CHECKSUM can be used to control the acceptance of a
+   zero checksum.  It is a write-only socket option and applies only to
+   future SCTP associations on the socket.
+
+   This option expects an unsigned integer.  Possible values include:
+
+   SCTP_EDMID_NONE:  Disable the use of any alternate error detection
+      method.  This means that all SCTP packets being received are only
+      accepted if they have a correct CRC32c checksum value.
+
+   SCTP_EDMID_LOWER_LAYER_DTLS:  Use the alternate error detection
+      method described in Section 6.
+
+   An implementation might only send packets with an incorrect checksum
+   of zero, if the alternate error detection method announced by the
+   peer is also enabled locally via this socket option.
+
+   The default for this socket option is that the use of alternate error
+   detection methods is disabled.
+
+8.  IANA Considerations
+
+   A new chunk parameter type has been assigned by IANA in the "Chunk
+   Parameter Types" registry for SCTP:
+
+       +==========+===================================+===========+
+       | ID Value | Chunk Parameter Type              | Reference |
+       +==========+===================================+===========+
+       | 32769    | Zero Checksum Acceptable (0x8001) | RFC 9653  |
+       +----------+-----------------------------------+-----------+
+
+          Table 1: New Entry in "Chunk Parameter Types" Registry
+
+   Furthermore, IANA has established a new "Error Detection Method"
+   registry for SCTP.  The assignment of new error detection methods is
+   done through the Specification Required policy as defined in
+   [RFC8126].  Documentation for a new error detection method MUST
+   contain the following information:
+
+   1.  A name of an alternate error detection method.
+
+   2.  A reference to a specification describing:
+
+       (a)  the alternate error detection method,
+
+       (b)  why the alternate error detection method provides an equal
+            or lower probability of false negatives than the one
+            provided by using the CRC32c checksum,
+
+       (c)  any constraints (specific to the alternate error detection
+            method) that are referred to in the fourth exception in
+            Section 5.2, and
+
+       (d)  why using the alternate error detection method does not
+            result in path failures due to middleboxes expecting correct
+            CRC32c checksums for more than two RTOs.  In case the
+            alternate error detection method uses a heuristic for
+            detecting such middleboxes, this heuristic needs to be
+            described.
+
+   The initial contents of the registry are as follows:
+
+          +================+========================+===========+
+          | ID Value       | Error Detection Method | Reference |
+          +================+========================+===========+
+          | 0              | Reserved               | RFC 9653  |
+          +----------------+------------------------+-----------+
+          | 1              | SCTP over DTLS         | RFC 9653  |
+          +----------------+------------------------+-----------+
+          | 2 - 4294967295 | Unassigned             |           |
+          +----------------+------------------------+-----------+
+
+             Table 2: Initial Contents of the "Error Detection
+                              Method" Registry
+
+   A designated expert (DE) is expected to ascertain the existence of
+   suitable documentation (a specification) as described in [RFC8126]
+   and to verify that the document is permanently and publicly
+   available.  Furthermore, the DE is expected to ensure that the above
+   four points have been addressed appropriately.
+
+9.  Security Considerations
+
+   This document does not change the considerations given in [RFC9260].
+
+   Due to the first requirement in Section 3, using an alternate error
+   detection method provides an equal or better level of data integrity
+   than the one provided by using the CRC32c checksum algorithm.  The
+   second requirement in Section 3 ensures that the existence of
+   middleboxes expecting correct CRC32c checksums does not result in
+   permanent path failures.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
+              Kozuka, "Stream Control Transmission Protocol (SCTP)
+              Dynamic Address Reconfiguration", RFC 5061,
+              DOI 10.17487/RFC5061, September 2007,
+              <https://www.rfc-editor.org/info/rfc5061>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8261]  Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
+              "Datagram Transport Layer Security (DTLS) Encapsulation of
+              SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
+              2017, <https://www.rfc-editor.org/info/rfc8261>.
+
+   [RFC9260]  Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
+              Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
+              June 2022, <https://www.rfc-editor.org/info/rfc9260>.
+
+10.2.  Informative References
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <https://www.rfc-editor.org/info/rfc768>.
+
+   [RFC4895]  Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
+              "Authenticated Chunks for the Stream Control Transmission
+              Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August
+              2007, <https://www.rfc-editor.org/info/rfc4895>.
+
+   [RFC6458]  Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
+              Yasevich, "Sockets API Extensions for the Stream Control
+              Transmission Protocol (SCTP)", RFC 6458,
+              DOI 10.17487/RFC6458, December 2011,
+              <https://www.rfc-editor.org/info/rfc6458>.
+
+   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
+              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
+              <https://www.rfc-editor.org/info/rfc9293>.
+
+Acknowledgments
+
+   The authors wish to thank Bernard Aboba, Deb Cooley, Martin Duke,
+   Gorry Fairhurst, Mike Heard, Peter Lei, Nils Ohlmeier, Claudio
+   Porfiri, Greg Skinner, Timo Völker, Éric Vyncke, and Magnus
+   Westerlund for their invaluable comments.
+
+Authors' Addresses
+
+   Michael Tüxen
+   Münster University of Applied Sciences
+   Stegerwaldstrasse 39
+   48565 Steinfurt
+   Germany
+   Email: tuexen@fh-muenster.de
+
+
+   Victor Boivie
+   Google
+   Kungsbron 2
+   SE-11122 Stockholm
+   Sweden
+   Email: boivie@google.com
+
+
+   Florent Castelli
+   Google
+   Kungsbron 2
+   SE-11122 Stockholm
+   Sweden
+   Email: orphis@google.com
+
+
+   Randell Jesup
+   Mozilla Corporation
+   1835 Horse Shoe Trl
+   Malvern, PA 19355
+   United States of America
+   Email: randell-ietf@jesup.org