[tsvwg] Re: Erik Kline's No Objection on draft-ietf-tsvwg-sctp-zero-checksum-10: (with COMMENT)

[Michael Tuexen <[e-mail]>]

> On 3. Jun 2024, at 02:57, Erik Kline via Datatracker <[e-mail]> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-tsvwg-sctp-zero-checksum-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-zero-checksum/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # Internet AD comments for draft-ietf-tsvwg-sctp-zero-checksum-10
> CC @ekline
> 
> * comment syntax:
>  - https://github.com/mnot/ietf-comments/blob/main/format.md
> 
> * "Handling Ballot Positions":
>  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> 
> ## Comments
> 
> ### S7
> 
> * Should (SHOULD?) there be a section about considerations for the TAPS API?
Hi Eric,

in general this is an interesting question. Right now, SCTP related documents
have socket API considerations and some TCP related ones, too. This is always
based on some implementation experience. Unfortunately, I don't know if there
is some open source TAPS implementation available, which supports SCTP.
Focussing on your question to this specification: I think there is no
need to expose this to the TAPS user. Right now, the TAPS API contains in
https://www.ietf.org/archive/id/draft-ietf-taps-interface-26.html#section-6.2.7
and
https://www.ietf.org/archive/id/draft-ietf-taps-interface-26.html#section-6.2.8
properties related to the checksum coverage. In my view, this is important since
the upper layer needs to specify if the user data needs the protection provided
be a checksum. However, this document specifies a way to use incorrect checksums
of zero if there is an alternate error detection method. So using this feature
does not weaken the error protection provided. Therefore, the application does
not need to know, if this feature is used or not. Within the TAPS implementation,
if can be decided, if alternate error detection methods are used and then not
do the CRC32c computations.
> 
> ### S9
> 
> * Is a DoS attack possible via a downgrade attack style mechanism?
> 
>  I.e., if a sender does not include this option but an on-path attacker
>  is able to inject it, I suppose the worst that happens is that incorrectly
>  zero-valued checksum packets are dropped all over the place.
I thought about this. In the particular case of SCTPoverDTLS this is not possible,
since the SCTP handshake runs over a protected channel and an on-path attacker
can not modify the SCTP packets.
In general, for future alternate error detection methods an on-path attacker can
do this. However, the result will be that packets are dropped by an endpoint,
which expects correct CRC32c values, but gets 0 instead. From the sender side,
this looks like as if there is a middlebox, which can't deal with incorrect
checksums of zero and the sender has already to deal with this and after 2 RTOs
switch to using a correct CRC32c. So this impact of such an attack is limited.
An on-path attacker can insert incorrect CRC32c already in the base protocol and
the receiver will compute the CRC32c just to see that the packet will be dropped.
So I don't see there any substantial new attack surface, but if you would prefer,
I can suggest some text to make this clear.

Best regards
Michael
> 
>  Nevertheless, is such a thing possible?
> 
> 
>