This document proposes a small extension to the SCTP protocol to allow saving some computation by not computing a per-packet CRC32c checksum for each packet where the protocol is run over some protocol that provides a stronger integrity check than the CRC32c provides. The first case they have in mind is where SCTP is running over DTLS.

The summary of the review is Ready with issues.

I see no security issues with this document. It does not discuss when it is appropriate to run the SCTP protocol over some cryptographically protected tunnel. Such a discussion would have security significance. This document simply prescribes a mechanism for skipping the creation and checking of the non-security CRC32c checksums when such tunnelling is done.

My only concerns are whether this protocol might be more complex than it needs to be where that complexity needlessly reduces its applicability and robustness.

I have no particular expertise with SCTP, and the answers to some of my concerns would be clear if I did. But I had some thoughts the authors might want to consider with respect to how this protocol should work:

It's not obvious whether the use of TCP checksums, UDP checksums, or these SCTP checksums makes sense in modern networks. They were designed at a time when links and routers were far less reliable and an additional checksum reduced the number of undetected errors in a meaningful way. Undetected errors in most networks today are sufficiently rare that such non-cryptographic checksums are probably not worth the CPU load and algorithm complexity that they cost. This spec goes out of its way to only allow skipping the CRC32c when a stronger integrity check exists. It's possible it would be better to be able to negotiate bypassing it under all circumstances.

This specification requires that the stronger integrity mechanism be specified in the protocol negotiating bypassing the use of CRC32c, and implicitly assumes that the two ends of the connection have the same view of the transport over which the protocol is carried. Besides DTLS, another strong integrity check that might be encountered is IPsec. IPsec certainly, but possibly also DTLS, might not be implemented end-to-end, so one end might believe SCTP is being carried over a cryptographically protected transport while that transport might be transparent to the other end. Specifying the type of integrity encapsulation within the SCTP protocol might therefore be a layer violation where one end thinks they have negotiated bypassing of the CRC32c while the other does not.

If the integrity encapsulation is already taking place before the CRC removal is negotiated, it would be both simpler and more reliable for the one end to propose skipping the generation of CRCs based on the integrity protection it applying to packets and the other end could accept or reject that proposal.

It may also be worth explicitly mentioning that if one end believes the external integrity protection is adequate, it can unilaterally decide to not check CRCs on arriving packets but MUST still generate them on outgoing packets unless the other end has agreed to accept zeros instead. Or alternately to explicitly mention that this is not allowed.

Nits:

The spec implies, but I don't believe it explicitly states, that if an arriving packet contains a non-zero CRC, then the recipient MUST compute the CRC and verify the provided one is correct.

The statement that alternate error detection method MUST NOT result in a path failure due to middleboxes is untestable and unenforceable because it's impossible to predict the behavior of future middleboxes. At best, this could be a goal of any future design.

The statement: "If an alternate error detection method is available, the computation of the CRC32c checksum consumes..." probably should read "is used" rather than "is available".