rfc9653v1.txt | rfc9653.txt | |||
---|---|---|---|---|
skipping to change at line 94 ¶ | skipping to change at line 94 ¶ | |||
protection over that already provided by DTLS. However, computing | protection over that already provided by DTLS. However, computing | |||
the CRC32c checksum at the sender and receiver sides does consume | the CRC32c checksum at the sender and receiver sides does consume | |||
computational resources for no benefit. This is particularly | computational resources for no benefit. This is particularly | |||
important for endpoints that are computationally limited and use SCTP | important for endpoints that are computationally limited and use SCTP | |||
over DTLS. | over DTLS. | |||
The extension described in this document allows an SCTP endpoint to | The extension described in this document allows an SCTP endpoint to | |||
declare that it accepts SCTP packets with a checksum of zero when | declare that it accepts SCTP packets with a checksum of zero when | |||
using a specific alternate error detection method. This declaration | using a specific alternate error detection method. This declaration | |||
happens during the setup of the SCTP association and allows endpoints | happens during the setup of the SCTP association and allows endpoints | |||
supporting this extension to be interoperable with endpoints not | that support this extension to be interoperable with endpoints that | |||
supporting the extension described in this document. To provide this | don't. To provide this backwards compatibility, endpoints using this | |||
backwards compatibility, endpoints using this extension still need to | extension still need to implement the CRC32c checksum algorithm. | |||
implement the CRC32c checksum algorithm. | ||||
2. Conventions | 2. Conventions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
3. Alternate Error Detection Methods | 3. Alternate Error Detection Methods | |||
skipping to change at line 165 ¶ | skipping to change at line 164 ¶ | |||
packets satisfying some method-specific constraints. | packets satisfying some method-specific constraints. | |||
2. Using an alternate error detection method MUST NOT result in a | 2. Using an alternate error detection method MUST NOT result in a | |||
path failure for more than two retransmission timeouts (RTOs) due | path failure for more than two retransmission timeouts (RTOs) due | |||
to middleboxes on the path expecting correct CRC32c checksums. | to middleboxes on the path expecting correct CRC32c checksums. | |||
To fulfill the second requirement, alternate error detection methods | To fulfill the second requirement, alternate error detection methods | |||
could use a heuristic to detect the existence of such middleboxes and | could use a heuristic to detect the existence of such middleboxes and | |||
use correct CRC32c checksums on these affected paths. | use correct CRC32c checksums on these affected paths. | |||
One example fulfilling the first requirement is using DTLS as the | Using DTLS as the lower layer of SCTP as specified in [RFC8261] is | |||
lower layer of SCTP as specified in [RFC8261]. Another example is | one example that fulfills the first requirement. Another example is | |||
using SCTP Authentication as specified in [RFC4895]. Of course, this | using SCTP Authentication as specified in [RFC4895]. Of course, this | |||
only applies to each SCTP packet having an AUTH chunk as its first | only applies to each SCTP packet having an AUTH chunk as its first | |||
chunk. However, using SCTP Authentication without any heuristic does | chunk. However, using SCTP Authentication without any heuristic does | |||
not fulfill the second requirement. Since using DTLS as the lower | not fulfill the second requirement. Since using DTLS as the lower | |||
layer of SCTP as specified in [RFC8261] also fulfills the second | layer of SCTP as specified in [RFC8261] also fulfills the second | |||
requirement, it can be used as an alternate error detection method | requirement, it can be used as an alternate error detection method | |||
(see Section 6). | (see Section 6). | |||
If an alternate error detection method is used, the computation of | If an alternate error detection method is used, the computation of | |||
the CRC32c checksum consumes computational resources without | the CRC32c checksum consumes computational resources without | |||
skipping to change at line 205 ¶ | skipping to change at line 204 ¶ | |||
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 | Length = 8 | | | Type = 0x8001 | Length = 8 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Error Detection Method Identifier (EDMID) | | | Error Detection Method Identifier (EDMID) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: Zero Checksum Acceptable Chunk Parameter | Figure 2: Zero Checksum Acceptable Chunk Parameter | |||
Type: 16 bits (unsigned integer). This field holds the IANA defined | Type: 16 bits (unsigned integer). | |||
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 | This field holds the IANA-defined parameter type for the "Zero | |||
bytes of the chunk parameter; the value MUST be 8. | 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 | Error Detection Method Identifier (EDMID): 32 bits (unsigned | |||
integer). An IANA-registered value specifying the alternate error | integer). | |||
detection method the sender of this parameter is willing to use | ||||
for received packets. | 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 | All transported integer numbers are in network byte order, a.k.a. big | |||
endian. | endian. | |||
The Zero Checksum Acceptable Chunk Parameter MAY appear in INIT and | The Zero Checksum Acceptable Chunk Parameter MAY appear in INIT and | |||
INIT ACK chunks and MUST NOT appear in any other chunk. The | INIT ACK chunks and MUST NOT appear in any other chunk. The | |||
Parameter MUST NOT appear more than once in any chunk. | Parameter MUST NOT appear more than once in any chunk. | |||
If an endpoint not supporting the extension described in this | If an endpoint not supporting the extension described in this | |||
document receives this parameter in an INIT or INIT ACK chunk, it is | document receives this parameter in an INIT or INIT ACK chunk, it is | |||
skipping to change at line 419 ¶ | skipping to change at line 423 ¶ | |||
A designated expert (DE) is expected to ascertain the existence of | A designated expert (DE) is expected to ascertain the existence of | |||
suitable documentation (a specification) as described in [RFC8126] | suitable documentation (a specification) as described in [RFC8126] | |||
and to verify that the document is permanently and publicly | and to verify that the document is permanently and publicly | |||
available. Furthermore, the DE is expected to ensure that the above | available. Furthermore, the DE is expected to ensure that the above | |||
four points have been addressed appropriately. | four points have been addressed appropriately. | |||
9. Security Considerations | 9. Security Considerations | |||
This document does not change the considerations given in [RFC9260]. | This document does not change the considerations given in [RFC9260]. | |||
Using an alternate error detection method provides an equal or better | Due to the first requirement in Section 3, using an alternate error | |||
level of data integrity than the one provided by using the CRC32c | detection method provides an equal or better level of data integrity | |||
checksum algorithm due to the first requirement of alternate error | than the one provided by using the CRC32c checksum algorithm. The | |||
detection methods. The second requirement of alternate error | second requirement in Section 3 ensures that the existence of | |||
detection methods ensures that the existence of middleboxes expecting | middleboxes expecting correct CRC32c checksums does not result in | |||
correct CRC32c checksums does not result in permanent path failures. | permanent path failures. | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[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>. | |||
End of changes. 6 change blocks. | ||||
21 lines changed or deleted | 25 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |