Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-sctp-zero-checksum - to conclude 25th April 2023

[Michael Welzl <[e-mail]>]

> On Apr 11, 2023, at 11:47 AM, Michael Tuexen <[e-mail]> wrote:
> 
>> On 11. Apr 2023, at 11:28, Michael Welzl <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> I have now read this document and support progressing it: it looks genuinely useful to me.
>> 
>> I was just wondering if the receiver-side behavior should include a statement about the possibility of simply ignoring the checksum?  The way section 4.3 is written, it doesn’t exclude this, but I guess that the SCTP base RFCs prescribe that the checksum *must* be calculated and checked. So, why not relax this? With or without negotiation of "Zero Checksum Acceptable”, a receiver could probably always locally decide: “I see that this is going over DTLS, so I will ignore the SCTP checksum."
> Right now the idea is to accept packets
> * which contain the correct CRC32c, or
> * which contain an incorrect CRC32c of zero, it this support was announced during the handshake.
> Just ignoring the checksum would also accept packets which contain an invalid checksum different
> from zero. This is currently not allowed.
> 
> Your proposal would be something like 'Any Checksum Acceptable' instead of 'Zero Checksum Acceptable'.
> Could be done, but do you gain anything?

If the sender is not aware of this new mechanism and inserts a correct (zero or not) SCTP checksum, the receiver could nevertheless skip doing the calculation.


> The implementation on the receiver side done in a way that you don't do any computation if
> you receive zero as the CRC32c and after looking up the association, you determine that
> the end point has sent initially the Zero Checksum Acceptable.
> If you know that the Zero Checksum Acceptable feature is used always, you can skip the lookup
> part.

What I’m proposing is to allow the receiver to not even do a checksum calculation even if the peer doesn’t use Zero Checksum Acceptable and/or isn’t aware of this feature.
I don’t know if specifying this matters, as it’s purely a local implementation decision anyway. I guess a receiver implementation could just decide that the checksum is assumed-correct in some cases, as the chance of a CRC below being right but the SCTP CRC being wrong is truly miniscule...

Never mind, then. Probably not worth adding words for it.

Cheers,
Michael


> 
> Best regards
> Michael
>> 
>> A nit - though, not being a native speaker, I don’t even know if this really is a mistake:  "This is in particular important for computational limited end points using SCTP encapsulated in DTLS.”
>> I believe that “computationally” should be used here instead of “computational".
>> 
>> Cheers,
>> Michael
>> 
>> 
>>> On Apr 11, 2023, at 10:31 AM, Gorry Fairhurst <[e-mail]> wrote:
>>> 
>>> This email now marks the start of a WG adoption call for: Zero Checksum for the Stream Control Transmission Protocol (draft-tuexen-tsvwg-sctp-zero-checksum-02). This draft was discussed at the recent TSVWG meeting.
>>> 
>>> Abstract:
>>> 
>>>  The Stream Control Transmission Protocol (SCTP) uses a 32-bit
>>>  checksum in the common header of each packet to provide some level of
>>>  data integrity.  When the lower layer used by SCTP provides already
>>>  the same or a higher level of data integrity, computing this checksum
>>>  does not provide any additional protection, but does require
>>>  computing resources.  This document provides a simple extension to
>>>  SCTP allowing to save these computing resources by using the constant
>>>  0 as the checksum in a backwards compatible way.
>>> 
>>> Please read this draft, and send any comments/concerns to either the TSVWG or to the chairs <[e-mail]>.  Notes of support to progress this work, and volunteers to review the drafts will also be very welcome at this stage.
>>> 
>>> All participants, should disclose any relevant intellectual property rights (IPR) under [RFC8179].
>>> 
>>> 
>>> Best wishes,
>>> Gorry and Marten
>>> (tsvwg co-chairs)
>>> 
>>> 
>> 
>