Reviewer: Bernard Aboba
Document: draft-ietf-tsvwg-sctp-zero-checksum
Status: Ready with (minor) Issues

The document is well written and allowing a zero checksum for SCTP over DTLS makes sense.
In order to allow for other potential protection mechanisms, the document sets up an
IANA registry and associated documentation requirements. However, I am not sure
that the registration criteria are clear enough. 

At present the document does not talk about implementation status, although I believe it
has been implemented in Pion, dcSCTP and perhaps other WebRTC data channel implementations. 
Have any issues arisen during implementation? 

NITs
----

3.  Alternate Error Detection Methods

   SCTP uses a CRC32c checksum to provide some level of data integrity.
   The CRC32c checksum is computed based on the SCTP common header and
   the chunks contained in the packet.  In particular, the computation
   of the CRC32c checksum does not involve a pseudo header for IPv4 or
   IPv6 like the computation of the TCP checksum, as specified in
   [RFC9293], or the UDP checksum, as specified in [RFC0768].

[BA] Would it be appropriate to advise against turning off the UDP checksum as well?

   Alternate error detection methods have two requirements:

   1.  An alternate error detection method MUST provide an equal or
       better level of data integrity than the one provided by using the
       CRC32c checksum algorithm.  This MAY only apply to packets
       satisfying some method specific constraints.

[BA] I think you may need to define the meaning of "equal or better" more
exactly.  For example, that the alternative provides the same coverage
as the CRC32c checksum, with a lower probability of a false negative.

   2.  Using an alternate error detection method MUST NOT result in a
       path failure for more than two retransmission timeouts (RTO) due
       to middleboxes on the path expecting correct CRC32c checksums.

[BA] This requirement depends on the behavior of middleboxes, so it's
not clear to me how adherence to the MUST NOT can be tested.

   To fulfill the second requirement, alternate error detection methods
   MAY use a heuristic to detect the existence of such middleboxes and
   use correct CRC32c checksums on these affected paths.

[BA] The "MAY" here seems to be somewhat in conflict with the much
stronger MUST NOT, particularly since we are talking about middlebox
detection. At present the document only allocates a code point for
DTLS, to which this requirement doesn't apply. 

   One example fulfilling the first requirement is using DTLS as the
   lower layer of SCTP as specified in [RFC8261].  Another example is
   using SCTP Authentication as specified in [RFC4895].  Of course, this
   only applies to all SCTP packets having an AUTH chunk as its first
   chunk.  However, using SCTP Authentication without any heuristic does
   not fulfill the second requirement.  Since using DTLS as the lower
   layer of SCTP as specified in [RFC8261] also fulfills the second
   requirement, it can be used as an alternate error detection method
   (see Section 6).

[BA] SCTP Authentication is not allocated a code point. So not sure
why this is mentioned as "another example" - is this just to indicate
why it is not acceptable (e.g. not meeting the second requirement)?

5.1.  Declaration of Feature Support

   An endpoint willing to accept SCTP packets with an incorrect checksum
   of zero MUST include the Zero Checksum Acceptable Chunk Parameter
   indicating the alternate error detection method it is willing to use
   in the INIT or INIT ACK chunk it sends.

   An SCTP implementation MAY also require the upper layer to indicate
   that it is fine to use a specific alternate error detection method
   before including the corresponding Zero Checksum Acceptable Chunk
   Parameter.

[BA] What if the alternate error detection method is not consistent
with what has been established? For example, SCTP over DTLS/UDP has
been established, but some other method (not yet allocated a code point)
is negotiated? 

Section 5.2

   4.  Alternate error detection methods might have some additional
       conditions requiring that the sender MUST include a correct
       CRC32c checksum in the packet.

[BA] The combination of "might" and MUST is an odd one. Is this normative language needed? 

   An SCTP end point MAY require that the upper layer allowed the use of
   the alternate error detection method that was announced by the peer
   before sending packets with an incorrect checksum of zero.

[BA] MAY? In the case of DTLS, the alternate error detection method
was setup prior to initiation of the SCTP association. So why would this
be optional?

Section 8 IANA Considerations

   2.  A reference to a specification describing:

       (a)  the alternate error detection method,

       (b)  why the alternate error detection method provides an equal
            or better level of data integrity protection than the one
            provided by using the CRC32c checksum,

[BA] It might help to sharpen the definition of "equal or better".