rfc9653.original.xml   rfc9653.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-model href="rfc7991bis.rnc"?> <!DOCTYPE rfc [
<?rfc toc='yes'?> <!ENTITY nbsp "&#160;">
<?rfc compact='yes'?> <!ENTITY zwsp "&#8203;">
<?rfc subcompact='no'?> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" ipr="trust200902"
xml:lang="en" submissionType="IETF" consensus="true" category="std" docName="draft-ietf-tsvwg-
ipr="trust200902" sctp-zero-checksum-11" number="9653" updates="" obsoletes="" tocInclude="true" v
submissionType="IETF" ersion="3" sortRefs="true" symRefs="true">
consensus="true"
category="std"
docName="draft-ietf-tsvwg-sctp-zero-checksum-11"
version="3">
<front> <front>
<title abbrev='Zero Checksum for SCTP'> <title abbrev='Zero Checksum for SCTP'>Zero Checksum for the Stream Control
Zero Checksum for the Stream Control Transmission Protocol Transmission Protocol</title>
</title> <seriesInfo name="RFC" value="9653"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-sctp-zero-checksum-11" <author initials="M." surname="Tüxen" fullname="Michael Tüxen">
/> <organization abbrev='Münster Univ. of Appl. Sciences'>Münster University
of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<city>48565 Steinfurt</city>
<country>Germany</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<author initials="M." surname="Tüxen" fullname="Michael Tüxen"> <author initials='V.' surname='Boivie' fullname='Victor Boivie'>
<organization abbrev='Münster Univ. of Appl. Sciences'> <organization>Google</organization>
Münster University of Applied Sciences</organization> <address>
<address> <postal>
<postal> <street>Kungsbron 2</street>
<street>Stegerwaldstrasse 39</street> <city>Stockholm</city>
<city>48565 Steinfurt</city> <code>11122</code>
<country>Germany</country> <country>Sweden</country>
</postal> </postal>
<email>tuexen@fh-muenster.de</email> <email>boivie@google.com</email>
</address> </address>
</author> </author>
<author initials='V.' surname='Boivie' fullname='Victor Boivie'> <author initials='F.' surname='Castelli' fullname='Florent Castelli'>
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>Kungsbron 2</street> <street>Kungsbron 2</street>
<city>Stockholm</city> <city>Stockholm</city>
<code>11122</code> <code>11122</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>boivie@google.com</email> <email>orphis@google.com</email>
</address> </address>
</author> </author>
<author initials='F.' surname='Castelli' fullname='Florent Castelli'> <author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization>Google</organization> <organization abbrev='Mozilla'>Mozilla Corporation</organization>
<address> <address>
<postal> <postal>
<street>Kungsbron 2</street> <street>1835 Horse Shoe Trl</street>
<city>Stockholm</city> <city>Malvern</city>
<code>11122</code> <region>PA</region>
<country>Sweden</country> <code>19355</code>
</postal> <country>United States of America</country>
<email>orphis@google.com</email> </postal>
</address> <email>randell-ietf@jesup.org</email>
</author> </address>
</author>
<author initials="R." surname="Jesup" fullname="Randell Jesup"> <date year="2024" month="September"/>
<organization abbrev='Mozilla'>
Mozilla Corporation</organization>
<address>
<postal>
<street>1835 Horse Shoe Trl</street>
<city>Malvern</city>
<region>PA</region>
<code>19355</code>
<country>US</country>
</postal>
<email>randell-ietf@jesup.org</email>
</address>
</author>
<date /> <area>WIT</area>
<workgroup>tsvwg</workgroup>
<abstract> <abstract>
<t>The Stream Control Transmission Protocol (SCTP) uses a 32-bit checksum in <t>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. 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 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 data integrity, computing this checksum does not provide any additional
protection, but does consume computing resources.</t> protection but does consume computing resources.</t>
<t>This document provides a simple extension allowing SCTP to save these <t>This document provides a simple extension allowing SCTP to save these
computing resources by using zero as the checksum in a backwards compatible computing resources by using zero as the checksum in a backwards-compatible
way. way.
It also defines how this feature can be used when SCTP packets are encapsulated It also defines how this feature can be used when SCTP packets are encapsulated
in Datagram Transport Layer Security (DTLS) packets.</t> in Datagram Transport Layer Security (DTLS) packets.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<t>SCTP as specified in <xref target="RFC9260"/> uses a CRC32c checksum to <t>SCTP as specified in <xref target="RFC9260"/> uses a CRC32c checksum to
provide some level of data integrity. provide some level of data integrity.
When using, for example, Datagram Transport Layer Security (DTLS) as the When using, for example, Datagram Transport Layer Security (DTLS) as the
lower layer for SCTP as specified in <xref target="RFC8261"/>, using the CRC32c lower layer for SCTP as specified in <xref target="RFC8261"/>, using the CRC32c
checksum does not provide any additional protection over that already provided checksum does not provide any additional protection over that already provided
by DTLS. by DTLS.
However, computing the CRC32c checksum at the sender and receiver side does However, computing the CRC32c checksum at the sender and receiver sides does
consume computational resources for no benefit. consume computational resources for no benefit.
This is particularly important for endpoints that are computationally limited This is particularly important for endpoints that are computationally limited
and use SCTP over DTLS.</t> and use SCTP over DTLS.</t>
<t>The extension described in this document allows an SCTP endpoint to declare <t>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 that it accepts SCTP packets with a checksum of zero when using a specific
alternate error detection method. alternate error detection method.
This declaration happens during the setup of the SCTP association and allows This declaration
endpoints supporting this extension to be interoperable with endpoints not happens during the setup of the SCTP association and allows endpoints
supporting the extension described in this document. that support this extension to be interoperable with endpoints that don't.
To provide this backwards compatibility, endpoints using this extension still To provide this backwards compatibility, endpoints using this extension still
need to implement the CRC32c checksum algorithm.</t> need to implement the CRC32c checksum algorithm.</t>
</section> </section>
<section anchor='conventions'> <section anchor='conventions'>
<name>Conventions</name> <name>Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", <t>
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
be interpreted as described in "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
they appear in all capitals, as shown here.</t> be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor='alternate_error_detection_methods'> <section anchor='alternate_error_detection_methods'>
<name>Alternate Error Detection Methods</name> <name>Alternate Error Detection Methods</name>
<t>SCTP uses a CRC32c checksum to provide some level of data integrity. <t>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 The CRC32c checksum is computed based on the SCTP common header and the chunks
contained in the packet. contained in the packet.
In particular, the computation of the CRC32c checksum does not involve a pseudo 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 header for IPv4 or IPv6 like the computation of the TCP checksum, as specified
in <xref target='RFC9293'/>, or the UDP checksum, as specified in in <xref target='RFC9293'/>, or the UDP checksum, as specified in
<xref target='RFC0768'/>.</t> <xref target='RFC0768'/>.</t>
<t>Zero is a valid result of the CRC32c checksum algorithm. <t>Zero is a valid result of the CRC32c checksum algorithm.
For example, the following figure depicts an SCTP packet containing a minimal For example, the following figure depicts an SCTP packet containing a minimal
INIT chunk with a correct CRC32c checksum of zero.</t> INIT chunk with a correct CRC32c checksum of zero.</t>
<figure> <figure>
<name>SCTP Packet with a correct CRC32c checksum of zero</name> <name>SCTP Packet with a Correct CRC32c Checksum of Zero</name>
<artwork align='center'> <artwork align='center'>
0 1 2 3 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 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 | | Source Port Number = 5001 |Destination Port Number = 5001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag = 0 | | Verification Tag = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum = 0 | | Checksum = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 172 skipping to change at line 167
</figure> </figure>
<t>Using SCTP in combination with other mechanisms or protocol extensions might <t>Using SCTP in combination with other mechanisms or protocol extensions might
provide data integrity protection with an equal or lower probability of false provide data integrity protection with an equal or lower probability of false
negatives than the one provided by using the CRC32c checksum algorithm. negatives than the one provided by using the CRC32c checksum algorithm.
When using such alternate error detection methods, the SCTP common header When using such alternate error detection methods, the SCTP common header
containing the 32-bit checksum field might or might not be visible to containing the 32-bit checksum field might or might not be visible to
middleboxes on the paths between the two endpoints.</t> middleboxes on the paths between the two endpoints.</t>
<t>Alternate error detection methods have two requirements:</t> <t>Alternate error detection methods have two requirements:</t>
<ol> <ol>
<li><t>An alternate error detection method <bcp14>MUST</bcp14> provide an equal <li><t>An alternate error detection method <bcp14>MUST</bcp14> provide an equa
or lower probability of false negatives than the one provided by using the l
CRC32c checksum algorithm. or lower probability of false negatives than the one provided by using the
This <bcp14>MAY</bcp14> only apply to packets satisfying some method specific CRC32c checksum algorithm.
constraints.</t></li> This <bcp14>MAY</bcp14> only apply to packets satisfying some method-specific
<li><t>Using an alternate error detection method <bcp14>MUST NOT</bcp14> constraints.</t></li>
result in a path failure for more than two retransmission timeouts (RTO) <li><t>Using an alternate error detection method <bcp14>MUST NOT</bcp14>
due to middleboxes on the path expecting correct CRC32c checksums.</t></li> result in a path failure for more than two retransmission timeouts (RTOs)
due to middleboxes on the path expecting correct CRC32c checksums.</t></li>
</ol> </ol>
<t>To fulfill the second requirement, alternate error detection methods could <t>To fulfill the second requirement, alternate error detection methods could
use a heuristic to detect the existence of such middleboxes and use correct use a heuristic to detect the existence of such middleboxes and use correct
CRC32c checksums on these affected paths.</t> CRC32c checksums on these affected paths.</t>
<t>One example fulfilling the first requirement is using DTLS as the lower layer <t>
of SCTP as specified in <xref target="RFC8261"/>. Using DTLS as the lower layer of SCTP as specified in <xref target="RFC8261"/
>
is one example that fulfills the first requirement.
Another example is using SCTP Authentication as specified in Another example is using SCTP Authentication as specified in
<xref target="RFC4895"/>. <xref target="RFC4895"/>.
Of course, this only applies to all SCTP packets having an AUTH chunk as its Of course, this only applies to each SCTP packet having an AUTH chunk as its
first chunk. first chunk.
However, using SCTP Authentication without any heuristic does not fulfill the However, using SCTP Authentication without any heuristic does not fulfill the
second requirement. second requirement.
Since using DTLS as the lower layer of SCTP as specified in Since using DTLS as the lower layer of SCTP as specified in
<xref target="RFC8261"/> also fulfills the second requirement, it can be used <xref target="RFC8261"/> also fulfills the second requirement, it can be used
as an alternate error detection method as an alternate error detection method
(see <xref target="edm_sctp_over_dtls"/>).</t> (see <xref target="edm_sctp_over_dtls"/>).</t>
<t>If an alternate error detection method is used, the computation of the <t>If an alternate error detection method is used, the computation of the
CRC32c checksum consumes computational resources without providing any benefit. CRC32c checksum consumes computational resources without providing any benefit.
To avoid this, an SCTP endpoint could be willing to accept SCTP packets with To avoid this, an SCTP endpoint could be willing to accept SCTP packets with
skipping to change at line 219 skipping to change at line 215
<section> <section>
<name>A New Chunk Parameter</name> <name>A New Chunk Parameter</name>
<t>The Zero Checksum Acceptable Chunk Parameter is defined by the <t>The Zero Checksum Acceptable Chunk Parameter is defined by the
following figure.</t> following figure.</t>
<figure> <figure>
<name>Zero Checksum Acceptable Chunk Parameter</name> <name>Zero Checksum Acceptable Chunk Parameter</name>
<artwork align="center"> <artwork align="center">
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 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 (suggested) | Length = 8 | | Type = 0x8001 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Detection Method Identifier (EDMID) | | Error Detection Method Identifier (EDMID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> </artwork>
</figure> </figure>
<dl newline="true"> <dl newline="true">
<dt>Type: 16 bits (unsigned integer)</dt> <dt>Type: 16 bits (unsigned integer)</dt>
<dd> <dd>
<t>This field holds the IANA defined parameter type for the This field holds the IANA-defined parameter type for the
"Zero Checksum Acceptable" chunk parameter. "Zero Checksum Acceptable" chunk parameter.
IANA is requested to assign the value 32769 (0x8001) (suggested) for this IANA has assigned the value 32769 (0x8001) for this
parameter type.</t> parameter type.
</dd> </dd>
<dt>Length: 16 bits (unsigned integer)</dt> <dt>Length: 16 bits (unsigned integer)</dt>
<dd> <dd>
<t>This field holds the length in bytes of the chunk parameter; This field holds the length in bytes of the chunk parameter;
the value <bcp14>MUST</bcp14> be 8.</t> the value <bcp14>MUST</bcp14> be 8.
</dd> </dd>
<dt>Error Detection Method Identifier (EDMID): 32 bits (unsigned integer)</dt> <dt>Error Detection Method Identifier (EDMID): 32 bits (unsigned integer)</dt>
<dd> <dd>
<t>An IANA registered value specifying the alternate error detection method An IANA-registered value specifying the alternate error detection method
the sender of this parameter is willing to use for received packets.</t> the sender of this parameter is willing to use for received packets.
</dd> </dd>
</dl> </dl>
<t>All transported integer numbers are in "network byte order" a.k.a., <t>All transported integer numbers are in network byte order, a.k.a.
Big Endian.</t> big endian.</t>
<t>The Zero Checksum Acceptable Chunk Parameter <bcp14>MAY</bcp14> appear <t>The Zero Checksum Acceptable Chunk Parameter <bcp14>MAY</bcp14> appear
in INIT and INIT ACK chunks and <bcp14>MUST NOT</bcp14> appear in any other in INIT and INIT ACK chunks and <bcp14>MUST NOT</bcp14> appear in any other
chunk. chunk.
The Parameter <bcp14>MUST NOT</bcp14> appear more than once in any chunk.</t> The Parameter <bcp14>MUST NOT</bcp14> appear more than once in any chunk.</t>
<t>If an endpoint not supporting the extension described in this document <t>If an endpoint not supporting the extension described in this document
receives this parameter in an INIT or INIT ACK chunk, it is receives this parameter in an INIT or INIT ACK chunk, it is
<bcp14>REQUIRED</bcp14> to skip this parameter and continue to process further <bcp14>REQUIRED</bcp14> to skip this parameter and continue to process further
parameters in the chunk. parameters in the chunk.
This behavior is specified by <xref target="RFC9260"/> because the highest-order This behavior is specified by <xref target="RFC9260"/> because the highest-order
two bits of the Type are '10'.</t> two bits of the Type are '10'.</t>
skipping to change at line 273 skipping to change at line 269
<t>An endpoint willing to accept SCTP packets with an incorrect checksum of <t>An endpoint willing to accept SCTP packets with an incorrect checksum of
zero <bcp14>MUST</bcp14> include the Zero Checksum Acceptable Chunk Parameter zero <bcp14>MUST</bcp14> include the Zero Checksum Acceptable Chunk Parameter
indicating the alternate error detection method it is willing to use in the indicating the alternate error detection method it is willing to use in the
INIT or INIT ACK chunk it sends.</t> INIT or INIT ACK chunk it sends.</t>
<t>An SCTP implementation <bcp14>MAY</bcp14> also require the upper layer to <t>An SCTP implementation <bcp14>MAY</bcp14> also require the upper layer to
indicate that it is fine to use a specific alternate error detection method indicate that it is fine to use a specific alternate error detection method
before including the corresponding Zero Checksum Acceptable Chunk Parameter.</t> before including the corresponding Zero Checksum Acceptable Chunk Parameter.</t>
</section> </section>
<section anchor='sender_side_considerations'> <section anchor='sender_side_considerations'>
<name>Sender Side Considerations</name> <name>Sender-Side Considerations</name>
<t>An SCTP endpoint cannot just use an incorrect CRC32c checksum value of zero <t>An SCTP endpoint cannot just use an incorrect CRC32c checksum value of zero
for all SCTP packets it sends. for all SCTP packets it sends.
The following restrictions apply:</t> The following restrictions apply:</t>
<ol> <ol>
<li><t>If an endpoint has not received an INIT or INIT ACK chunk containing a <li><t>If an endpoint has not received an INIT or INIT ACK chunk containing a
Zero Checksum Acceptable Chunk Parameter indicating an alternate error detection Zero Checksum Acceptable Chunk Parameter indicating an alternate error detection
method it supports from its peer during the association setup, method it supports from its peer during the association setup,
it <bcp14>MUST</bcp14> use a correct CRC32c checksum. it <bcp14>MUST</bcp14> use a correct CRC32c checksum.
In particular, when an endpoint</t> In particular, when an endpoint</t>
<ol type='%c.'> <ol type='%c.'>
skipping to change at line 297 skipping to change at line 293
<bcp14>MUST</bcp14> include a correct CRC32c checksum in the response <bcp14>MUST</bcp14> include a correct CRC32c checksum in the response
packet.</t></li> packet.</t></li>
</ol></li> </ol></li>
<li><t>When an endpoint sends a packet containing a COOKIE ECHO chunk, it <li><t>When an endpoint sends a packet containing a COOKIE ECHO chunk, it
<bcp14>MUST</bcp14> include a correct CRC32c checksum in the packet containing <bcp14>MUST</bcp14> include a correct CRC32c checksum in the packet containing
the COOKIE ECHO chunk.</t></li> the COOKIE ECHO chunk.</t></li>
<li><t>When an endpoint supports the dynamic address reconfiguration specified <li><t>When an endpoint supports the dynamic address reconfiguration specified
in <xref target='RFC5061'/> and sends a packet containing an ASCONF chunk, it in <xref target='RFC5061'/> and sends a packet containing an ASCONF chunk, it
<bcp14>MUST</bcp14> include a correct CRC32c checksum in the packet containing <bcp14>MUST</bcp14> include a correct CRC32c checksum in the packet containing
the ASCONF chunk.</t></li> the ASCONF chunk.</t></li>
<li><t>If an alternate error detection method has some method specific <li><t>If an alternate error detection method has some method-specific
constraints, the sender <bcp14>MUST</bcp14> include a correct CRC32c checksum constraints, the sender <bcp14>MUST</bcp14> include a correct CRC32c checksum
in all packets not fulfilling these method specific constraints.</t></li> in all packets that don't fulfill these method-specific constraints.</t></li>
</ol> </ol>
<t>The first restriction allows backwards compatibility. <t>The first restriction allows backwards compatibility.
The second and third restrictions allow a simpler implementation of the The second and third restrictions allow a simpler implementation of the
extension defined in this document, because looking up the association extension defined in this document, because looking up the association
for SCTP packets containing a COOKIE ECHO chunk or an ASCONF chunk might for SCTP packets containing a COOKIE ECHO chunk or an ASCONF chunk might
be more complex than for other packets. be more complex than for other packets.
Finally, the last restriction covers alternate error detection method Finally, the last restriction covers constraints specific to the alternate error
specific constraints.</t> detection method.</t>
<t>An SCTP end point <bcp14>MAY</bcp14> require that the upper layer allowed <t>An SCTP endpoint <bcp14>MAY</bcp14> require that the upper layer allow
the use of the alternate error detection method that was announced by the peer the use of the alternate error detection method that was announced by the peer
before sending packets with an incorrect checksum of zero.</t> before sending packets with an incorrect checksum of zero.</t>
<t>If none of the above restrictions apply, an endpoint <bcp14>SHOULD</bcp14> <t>If none of the above restrictions apply, an endpoint <bcp14>SHOULD</bcp14>
use zero as the checksum when sending an SCTP packet.</t> use zero as the checksum when sending an SCTP packet.</t>
</section> </section>
<section> <section>
<name>Receiver Side Considerations</name> <name>Receiver-Side Considerations</name>
<t>If an endpoint has sent the Zero Checksum Acceptable Chunk Parameter <t>If an endpoint has sent the Zero Checksum Acceptable Chunk Parameter
indicating the support of an alternate error detection method in an INIT or indicating the support of an alternate error detection method in an INIT or
INIT ACK chunk, it <bcp14>MUST</bcp14> accept SCTP packets fulfilling the INIT ACK chunk, in addition to SCTP packets containing the
requirements of the announced alternate error detection method using correct CRC32c checksum value it <bcp14>MUST</bcp14> accept SCTP packets that ha
an incorrect checksum value of zero in addition to SCTP packets containing the ve an
correct CRC32c checksum value for this association. incorrect checksum value of zero and that fulfill the requirements of
the announced alternate error detection method used for this association.
Otherwise, the endpoint <bcp14>MUST</bcp14> drop all SCTP packets with an Otherwise, the endpoint <bcp14>MUST</bcp14> drop all SCTP packets with an
incorrect CRC32c checksum.</t> incorrect CRC32c checksum.</t>
<t>In addition to processing OOTB packets with a correct CRC32c checksum as <t>In addition to processing OOTB packets with a correct CRC32c checksum as
specified in <xref target='RFC9260'/>, an SCTP implementation specified in <xref target='RFC9260'/>, an SCTP implementation
<bcp14>MAY</bcp14> also process OOTB packets having an incorrect zero checksum. <bcp14>MAY</bcp14> also process OOTB packets having an incorrect zero checksum.
Doing so might result in faster SCTP association failure detection.</t> Doing so might result in faster SCTP association failure detection.</t>
</section> </section>
</section> </section>
<section anchor='edm_sctp_over_dtls'> <section anchor='edm_sctp_over_dtls'>
<name>Error Detection via SCTP over DTLS</name> <name>Error Detection via SCTP over DTLS</name>
<t>Using SCTP over DTLS as specified in <xref target="RFC8261"/> provides <t>Using SCTP over DTLS as specified in <xref target="RFC8261"/> provides
a stronger error detection method than using the CRC32c checksum algorithm. a stronger error detection method than using the CRC32c checksum algorithm.
Since middleboxes will not observe the unencrypted SCTP packet, there is Since middleboxes will not observe the unencrypted SCTP packet, there is
no risk in interfering with using zero as an incorrect checksum. no risk in interfering with using zero as an incorrect checksum.
There are no additional error detection method specific constraints on packets There are no additional constraints (specific to the error detection method) on packets
when using DTLS encapsulation.</t> when using DTLS encapsulation.</t>
</section> </section>
<section> <section>
<name>Socket API Considerations</name> <name>Socket API Considerations</name>
<t>This section describes how the socket API defined in <t>This section describes how the socket API defined in
<xref target='RFC6458'/> needs to be extended to provide a way for the <xref target='RFC6458'/> needs to be extended to provide a way for the
application to control the acceptance of a zero checksum.</t> application to control the acceptance of a zero checksum.</t>
<t>A 'Socket API Considerations' section is contained in all SCTP related <t>A 'Socket API Considerations' section is contained in all SCTP-related
specifications published after <xref target='RFC6458'/> describing an extension specifications published after <xref target='RFC6458'/> describing an extension
for which implementations using the socket API as specified in for which implementations using the socket API as specified in
<xref target='RFC6458'/> would require some extension of the socket API. <xref target='RFC6458'/> would require some extension of the socket API.
Please note that this section is informational only.</t> Please note that this section is informational only.</t>
<t>A socket API implementation based on <xref target='RFC6458'/> is extended by <t>A socket API implementation based on <xref target='RFC6458'/> is extended by
supporting one new write-only IPPROTO_SCTP-level socket option.</t> supporting one new write-only IPPROTO_SCTP-level socket option.</t>
<section> <section>
<name>Set Accepting a Zero Checksum (SCTP_ACCEPT_ZERO_CHECKSUM)</name> <name>Set Accepting a Zero Checksum (SCTP_ACCEPT_ZERO_CHECKSUM)</name>
<t>This IPPROTO_SCTP-level socket option with the name SCTP_ACCEPT_ZERO_CHECKSUM <t>This IPPROTO_SCTP-level socket option with the name SCTP_ACCEPT_ZERO_CHECKSUM
skipping to change at line 382 skipping to change at line 379
<t>An implementation might only send packets with an incorrect checksum of zero, <t>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 if the alternate error detection method announced by the peer is also enabled
locally via this socket option.</t> locally via this socket option.</t>
<t>The default for this socket option is that the use of alternate error <t>The default for this socket option is that the use of alternate error
detection methods is disabled.</t> detection methods is disabled.</t>
</section> </section>
</section> </section>
<section> <section>
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>[NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you <t>A new chunk parameter type has been assigned by IANA in the "Chunk Parameter
assign this document.]</t> Types" registry for SCTP:</t>
<t>[NOTE to RFC-Editor: The suggested value for the parameter type is tentative
and to be confirmed by IANA.]</t>
<t>This document (RFCXXXX) is the reference for the registration described
in this section.</t>
<t>A new chunk parameter type has to be assigned by IANA.
This requires an additional line in the "Chunk Parameter Types" registry for
SCTP:</t>
<table> <table>
<name>New entry in "Chunk Parameter Types" registry</name> <name>New Entry in "Chunk Parameter Types" Registry</name>
<thead> <thead>
<tr><th>ID Value</th> <th>Chunk Parameter Type</th> <tr>
<th>Reference</th></tr> <th>ID Value</th>
</thead> <th>Chunk Parameter Type</th>
<tbody> <th>Reference</th>
<tr><td>32769 (suggested)</td> <td>Zero Checksum Acceptable (0x8001 (suggeste </tr>
d))</td> <td>[RFCXXXX]</td></tr> </thead>
</tbody> <tbody>
<tr><td>32769</td>
<td>Zero Checksum Acceptable (0x8001)</td>
<td>RFC 9653</td></tr>
</tbody>
</table> </table>
<t>Furthermore, IANA is requested to establish a new "Error Detection Method" <t>Furthermore, IANA has established a new "Error Detection Method"
registry for SCTP. registry for SCTP.
The assignment of new error detection methods is done through the Specification The assignment of new error detection methods is done through the Specification
Required policy as defined in <xref target='RFC8126'/>. Required policy as defined in <xref target='RFC8126'/>.
Documentation for a new error detection method <bcp14>MUST</bcp14> contain the Documentation for a new error detection method <bcp14>MUST</bcp14> contain the
following information:</t> following information:</t>
<ol> <ol>
<li><t>A name of an alternate error detection method.</t></li> <li><t>A name of an alternate error detection method.</t></li>
<li><t>A reference to a specification describing:</t> <li><t>A reference to a specification describing:</t>
<ol type='(%c)'> <ol type='(%c)'>
<li><t>the alternate error detection method,</t></li> <li><t>the alternate error detection method,</t></li>
<li><t>why the alternate error detection method provides an equal or <li><t>why the alternate error detection method provides an equal or
lower probability of false negatives than the one provided by using the CRC32c lower probability of false negatives than the one provided by using the CRC3
checksum,</t></li> 2c
<li><t>any alternate error detection method specific constraints referred to in checksum,</t></li>
the fourth exception in <xref target='sender_side_considerations'/>, and</t></li <li><t>any constraints (specific to the alternate error detection method) th
> at are referred to in the fourth exception in <xref target='sender_side_consider
<li><t>why using the alternate error detection method does not result in ations'/>, and</t></li>
path failures due to middleboxes expecting correct CRC32c checksums for more <li><t>why using the alternate error detection method does not result in
than two RTOs. path failures due to middleboxes expecting correct CRC32c checksums for more
In case the alternate error detection method uses a heuristic for detecting than two RTOs.
such middleboxes, this heuristic needs to be described.</t></li> In case the alternate error detection method uses a heuristic for detecting
</ol></li> such middleboxes, this heuristic needs to be described.</t></li>
</ol></li>
</ol> </ol>
<t>IANA is requested to use the following as the initial contents of the <t>The initial contents of the registry are as follows:</t>
registry:</t>
<table> <table>
<name>Initial Contents of the "Error Detection Method" registry</name> <name>Initial Contents of the "Error Detection Method" Registry</name>
<thead> <thead>
<tr><th>ID Value</th> <th>Error Detection Method</th> <th>Reference</th></ <tr><th>ID Value</th> <th>Error Detection Method</th> <th>Reference</t
tr> h></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td>0 </td> <td>Reserved</td> <td>[RFCXXXX]</td></ <tr><td>0 </td> <td>Reserved</td> <td>RFC 9653</td><
tr> /tr>
<tr><td>1 </td> <td>SCTP over DTLS</td> <td>[RFCXXXX]</td></ <tr><td>1 </td> <td>SCTP over DTLS</td> <td>RFC 9653</td><
tr> /tr>
<tr><td>2 - 4294967295</td> <td>Unassigned</td> <td> </td></ <tr><td>2 - 4294967295</td> <td>Unassigned</td> <td></td></tr>
tr> </tbody>
</tbody>
</table> </table>
<t>A Designated Expert (DE) is expected to ascertain the existence of suitable <t>A designated expert (DE) is expected to ascertain the existence of suitable
documentation (a specification) as described in <xref target='RFC8126'/> and to documentation (a specification) as described in <xref target='RFC8126'/> and to
verify that the document is permanently and publicly available. verify that the document is permanently and publicly available.
Furthermore, the DE is expected to ensure that the above four points have been Furthermore, the DE is expected to ensure that the above four points have been
addressed appropriately.</t> addressed appropriately.</t>
</section> </section>
<section> <section>
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document does not change the considerations given in <t>This document does not change the considerations given in
<xref target="RFC9260"/>.</t> <xref target="RFC9260"/>.</t>
<t>Using an alternate error detection method provides an equal or better level <t>Due to the first requirement in <xref target="alternate_error_detection_metho
of data integrity than the one provided by using the CRC32c checksum algorithm ds"/>, using an alternate error
due to the first requirement of alternate error detection methods. detection method provides an equal or better level of data integrity
The second requirement of alternate error detection methods ensures that the than the one provided by using the CRC32c checksum algorithm. The
second requirement in <xref target="alternate_error_detection_methods"/> ensu
res that the
existence of middleboxes expecting correct CRC32c checksums does not result in existence of middleboxes expecting correct CRC32c checksums does not result in
permanent path failures.</t> permanent path failures.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
.2119.xml"/> />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5061.xml"
.5061.xml"/> />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
.8126.xml"/> />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
.8174.xml"/> />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8261.xml"
.8261.xml"/> />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"
.9260.xml"/> />
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"
.0768.xml"/> />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4895.xml"
.4895.xml"/> />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6458.xml"
.6458.xml"/> />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"
.9293.xml"/> />
</references> </references>
</references> </references>
<section numbered='false'> <section numbered='false'>
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors wish to thank <t>The authors wish to thank
<contact fullname="Bernard Aboba"/>, <contact fullname="Bernard Aboba"/>,
<contact fullname="Deb Cooley"/>, <contact fullname="Deb Cooley"/>,
<contact fullname="Martin Duke"/>, <contact fullname="Martin Duke"/>,
<contact fullname="Gorry Fairhurst"/>, <contact fullname="Gorry Fairhurst"/>,
 End of changes. 38 change blocks. 
204 lines changed or deleted 209 lines changed or added

This html diff was produced by rfcdiff 1.48.