Skip to main content

Last Call Review of draft-ietf-tsvwg-sctp-zero-checksum-09
review-ietf-tsvwg-sctp-zero-checksum-09-secdir-lc-kaufman-2024-05-18-00

Request Review of draft-ietf-tsvwg-sctp-zero-checksum
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2024-05-16
Requested 2024-05-02
Authors Michael Tüxen , Victor Boivie , Florent Castelli , Randell Jesup
I-D last updated 2024-05-18
Completed reviews Genart Last Call review of -09 by Meral Shirazipour (diff)
Opsdir Last Call review of -11 by Victor Kuarsingh
Artart Last Call review of -09 by Dr. Bernard D. Aboba (diff)
Secdir Telechat review of -10 by Charlie Kaufman (diff)
Secdir Last Call review of -09 by Charlie Kaufman (diff)
Artart Telechat review of -10 by Dr. Bernard D. Aboba (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Request Last Call review on draft-ietf-tsvwg-sctp-zero-checksum by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/N02HXXj6Fi1VDiNFb3KXeHSElQE
Reviewed revision 09 (document currently at 11)
Result Has issues
Completed 2024-05-12
review-ietf-tsvwg-sctp-zero-checksum-09-secdir-lc-kaufman-2024-05-18-00
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".