Stream Control Transmission Protocol (SCTP) Checksum Change
obsoleted by
- rfc-4960 — Stream Control Transmission Protocol
updates
- rfc-2960 — Stream Control Transmission Protocol
Extracted elements (17)
A 'trailer' CRC (appended after the packet as in Ethernet) was considered but rejected because RFC 2960 implementations had already proliferated, and the benefit did not outweigh the cost of making a large change to protocol processing. Packets accepted by the header CRC are in one-to-one correspondence with packets that would be accepted by a trailer CRC approach.
Adler-32 was replaced because for short packets (e.g., 128 bytes) the s1 accumulator never wraps modulo 65521, causing the checksum distribution to cluster around a hot-spot rather than spreading uniformly across available bits. SCTP's primary use as a signaling transport with packets typically under 128 bytes made this weakness especially critical.
The CRC formulation chosen initializes the remainder register to all-1s rather than zero (with no complementing of the first 32 bits). This is noted as equivalent to the alternative formulation for messages longer than 64 bits, and was chosen to permit non-SCTP usage where the same CRC algorithm may protect messages shorter than 64 bits.
The reflected bit ordering for CRC-32c in SCTP (LSB of each byte maps to most significant polynomial coefficient) matches on-the-wire bit order for Ethernet and other serial media. This is the reverse of traditional Internet bit ordering but allows the same CRC hardware used for Ethernet to be reused.
There may be a computational advantage in validating the Association against the Verification Tag before performing the checksum calculation, since invalid tags result in the same action as a bad checksum in most cases. Exceptions are INIT, some SHUTDOWN-COMPLETE exchanges, and stale COOKIE-ECHO, which represent small packets that minimize the effect of the checksum calculation.
Implementors are warned that two equivalent CRC formulations exist in the literature (one initializes the register to zero and complements the first 32 bits; the other initializes to all-1s). Both produce the same result for messages longer than 64 bits, and SCTP uses the all-1s initialization formulation.
There is no graceful transition mechanism for migrating from Adler-32 to CRC-32c. Implementations are expected to immediately switch to the new algorithm; use of the old Adler-32 algorithm is deprecated.
Any hardware implementation of CRC-32c for SCTP SHOULD be done in a way that is verifiable by software.
SCTP implementations MUST replace the Adler-32 checksum with CRC-32c. All references to Adler-32 in RFC 2960 MUST be treated as references to CRC-32c. There is no graceful transition mechanism; implementations are expected to immediately switch.
The default procedure for handling invalid SCTP packets (those with a bad CRC-32c checksum) is to silently discard them.
When receiving an SCTP packet, the receiver MUST first check the CRC-32c checksum by storing the received value, zeroing the checksum field, recalculating over the whole packet, and verifying the values match. If they do not match, the receiver MUST treat the packet as invalid.
When sending an SCTP packet, the endpoint MUST include the CRC-32c checksum value calculated over the entire packet including the SCTP common header and all chunks, with the Checksum field initialized to 0 before calculation.
The CRC-32c checksum is a 32-bit value placed in the Checksum field of the SCTP common header, computed over the entire SCTP packet. The Castagnoli polynomial 0x11EDC6F41 (CRC-32c) is used, replacing the previously specified Adler-32.
The CRC-32c polynomial is 0x11EDC6F41 (Castagnoli), equivalent to x^32+x^28+x^27+x^26+x^25+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is computed using a reflected (mirrored) bit ordering where bytes are taken most-significant first but bits within each byte are taken least-significant first.
The general security considerations of RFC 2960 apply to SCTP with the CRC-32c checksum as well. No new security issues specific to the checksum change are identified beyond the improved error detection properties of CRC-32c over Adler-32.
The bit-ordering convention for CRC-32c in SCTP maps bytes most-significant first, but within each byte bits are taken least-significant first (reflected/mirrored ordering). The CRC remainder register is initialized with all 1s and the final result is complemented.
The SCTP Checksum field is a 32-bit field in the SCTP common header. On transmission it is set to 0 before CRC-32c calculation, then replaced with the computed CRC value. On reception, the field is zeroed before verification recalculation.