Reviewer: Bernard Aboba
Review result: Ready with Issues
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".
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
