Summary

  • RFC 9653 does not disable SCTP integrity checking in general. It lets a sender place an intentionally incorrect zero in the checksum field only for an association whose peer advertised a supported alternative error-detection method.
  • The exception preserves hard boundaries: the alternative must be at least as good at avoiding undetected errors, middleboxes must not break the path for more than two retransmission timeouts, and several packet classes still require a correct CRC32c.

A zero that cannot explain itself

SCTP normally gives every packet a 32-bit CRC32c in its common header. The sender computes it across the common header and all chunks; the receiver discards a packet whose value is invalid. Unlike TCP or UDP, this calculation does not include an IPv4 or IPv6 pseudo-header. That is the baseline consolidated in RFC 9260, whose author list includes Michael Tüxen.

The extension in RFC 9653 begins with a surprisingly awkward fact: zero is not an out-of-band symbol. It can be the correct result of the CRC32c calculation. A receiver cannot inspect the four bytes, see zero and infer whether the sender deliberately skipped the calculation or happened to compute that value. The meaning therefore cannot safely live in the field alone.

RFC 9653 moves the decision to association setup. An endpoint may include a Zero Checksum Acceptable parameter in INIT or INIT ACK. The parameter may appear at most once and identifies a specific alternative error-detection method. Only after receiving that declaration, recognizing the method and satisfying any local upper-layer policy may a sender transmit packets with an intentionally incorrect zero checksum. This is bilateral capability discovery, not a permanent node-wide switch.

That distinction is operationally important. A packet capture showing zeros is incomplete evidence. To judge the traffic, an operator also needs the association's opening exchange, the advertised method identifier, the encapsulation actually used and the packet class. Removing that context makes legitimate optimization and silent corruption look identical.

The substitute has two tests to pass

The standards language does not accept “some other protection exists” as a sufficient claim. An alternative method must first have an equal or lower probability of failing to detect an error than CRC32c. The method may impose packet-specific conditions, so eligibility can vary within one association.

It must also survive the network between the endpoints. If a middlebox expects to validate SCTP's CRC32c, sending the deliberately wrong value can cause a path failure. RFC 9653 therefore requires confidence that such failure does not persist for more than two retransmission timeout periods. The time bound converts middlebox uncertainty into a recovery requirement: an implementation cannot keep an association marooned indefinitely while assuming its negotiated optimization ought to work.

SCTP over DTLS, described by RFC 8261, is the specification's concrete success case. DTLS protects the SCTP packets with confidentiality, source authentication and integrity, whether the stack runs over UDP directly or through ICE/UDP. It meets the error-detection requirement, and because an on-path middlebox cannot inspect the encrypted SCTP packet, the middlebox test is also satisfied. RFC 9653 assigns this method identifier 1. The number is a registry value, not a rank or security score.

SCTP-AUTH illustrates the boundary. RFC 4895 can authenticate selected chunks. When AUTH is the first chunk, it can meet the first test for the protected material. But an SCTP-aware middlebox can still see the common header and reject a bad CRC32c. Without another deployment-specific mechanism, AUTH alone therefore does not establish the second condition. Cryptographic strength at the endpoint does not automatically prove path compatibility.

The checksum remains in the protocol

Even after successful negotiation, RFC 9653 reserves packet classes that still need a correct CRC32c. INIT and packets sent in response to out-of-the-blue traffic are outside an established permission. COOKIE ECHO and ASCONF also retain the checksum. Packets outside a method's stated constraints do too. And if the peer never advertised an acceptable method, the original rule applies without qualification.

Receiving logic is equally conditional. An endpoint may accept an incorrect zero only if it advertised the relevant method and that method's requirements are met. An incorrect nonzero checksum is not converted into valid traffic. Nor may a receiver treat every zero as intentionally omitted, because zero can be a correct CRC result. Implementations still need CRC32c for association setup, exceptions, fallback and interoperability with peers that do not implement the extension.

This design makes the checksum field the visible tip of a larger state machine. The control surface includes the INIT/INIT ACK parameters, support for the named method, upper-layer authorization, outer protection, packet classification, retransmission timers and a route's middlebox behavior. Optimizing only the arithmetic while ignoring those dependencies changes the protocol contract.

Why Tüxen's contribution matters

Tüxen heads the Network Programming Laboratory at FH Münster. The IETF Datatracker also records a broad transport-protocol role: he is a current TCPM chair, serves as a TSVART reviewer and is associated with dozens of RFCs. In the checksum lineage, he appears on the modern SCTP base specification as well as the extension that narrows when its checksum may be omitted.

The notable engineering move is not the permission to write zero. It is the refusal to let an optimization erase its proof obligations. RFC 3309 had earlier replaced SCTP's original Adler-32 with CRC32c because the checksum's error-detection properties mattered. RFC 9653 does not reverse that history. It says the work may move to a qualifying layer, but the resulting protection and the path behavior must remain measurable.

That makes the extension useful beyond SCTP. Layering arguments often claim that a lower or outer mechanism makes another check redundant. Tüxen and his co-authors show what a defensible version of that claim looks like: name the replacement, negotiate it in the correct scope, define comparative reliability, list the packets outside the exception, bound failure detection and retain a compatible path home.

Sources