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.		This field holds the IANA-defined parameter type for the "Zero
	IANA has assigned the value 32769 (0x8001) for this parameter		Checksum Acceptable" chunk parameter. IANA has assigned the value
	type.		32769 (0x8001) for this parameter type.
	Length: 16 bits (unsigned integer). This field holds the length in		Length: 16 bits (unsigned integer)
	bytes of the chunk parameter; the value MUST be 8.		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		An IANA-registered value specifying the alternate error detection
	for received packets.		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 295 ¶		skipping to change at line 296 ¶
	the alternate error detection method that was announced by the peer		the alternate error detection method that was announced by the peer
	before sending packets with an incorrect checksum of zero.		before sending packets with an incorrect checksum of zero.
	If none of the above restrictions apply, an endpoint SHOULD use zero		If none of the above restrictions apply, an endpoint SHOULD use zero
	as the checksum when sending an SCTP packet.		as the checksum when sending an SCTP packet.
	5.3. Receiver-Side Considerations		5.3. Receiver-Side Considerations
	If an endpoint has sent the Zero Checksum Acceptable Chunk Parameter		If an endpoint has sent the Zero Checksum Acceptable Chunk Parameter
	indicating the support of an alternate error detection method in an		indicating the support of an alternate error detection method in an
	INIT or INIT ACK chunk, it MUST accept SCTP packets fulfilling the		INIT or INIT ACK chunk, in addition to SCTP packets containing the
	requirements of the announced alternate error detection method using		correct CRC32c checksum value it MUST accept SCTP packets that have
	an incorrect checksum value of zero in addition to SCTP packets		an incorrect checksum value of zero and that fulfill the requirements
	containing the correct CRC32c checksum value for this association.		of the announced alternate error detection method used for this
	Otherwise, the endpoint MUST drop all SCTP packets with an incorrect		association. Otherwise, the endpoint MUST drop all SCTP packets with
	CRC32c checksum.		an incorrect CRC32c checksum.
	In addition to processing OOTB packets with a correct CRC32c checksum		In addition to processing OOTB packets with a correct CRC32c checksum
	as specified in [RFC9260], an SCTP implementation MAY also process		as specified in [RFC9260], an SCTP implementation MAY also process
	OOTB packets having an incorrect zero checksum. Doing so might		OOTB packets having an incorrect zero checksum. Doing so might
	result in faster SCTP association failure detection.		result in faster SCTP association failure detection.
	6. Error Detection via SCTP over DTLS		6. Error Detection via SCTP over DTLS
	Using SCTP over DTLS as specified in [RFC8261] provides a stronger		Using SCTP over DTLS as specified in [RFC8261] provides a stronger
	error detection method than using the CRC32c checksum algorithm.		error detection method than using the CRC32c checksum algorithm.
	skipping to change at line 419 ¶		skipping to change at line 420 ¶
	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. 7 change blocks.
	28 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48.