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

Michael Tuexen <> Tue, 11 April 2023 10:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A25ACC14CE42 for <>; Tue, 11 Apr 2023 03:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wJmNgPRC9uLo for <>; Tue, 11 Apr 2023 03:20:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCA7CC14CE33 for <>; Tue, 11 Apr 2023 03:20:08 -0700 (PDT)
Received: from (unknown [IPv6:2a02:8109:1140:c3d:ed58:432e:c240:748]) (Authenticated sender: lurchi) by (Postfix) with ESMTPSA id B170970D3F4A5; Tue, 11 Apr 2023 12:20:03 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: Michael Tuexen <>
In-Reply-To: <>
Date: Tue, 11 Apr 2023 12:20:03 +0200
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Michael Welzl <>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <>
Subject: Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-sctp-zero-checksum - to conclude 25th April 2023
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Apr 2023 10:20:14 -0000

> On 11. Apr 2023, at 12:02, Michael Welzl <> wrote:
>> On Apr 11, 2023, at 11:47 AM, Michael Tuexen <> wrote:
>>> On 11. Apr 2023, at 11:28, Michael Welzl <> 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.
Yeah, this is what some implementations are doing right now to reduce the CPU load.
>> 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...
Just ignoring the CRC32c on the receiver side is a local behavior, which does not need negotiation and
is already used.

The specification allows that an end-point only sends zero checksum if the peer allowed it and the
local user also allowed it. There could be the case where one endpoint runs SCTP/DTLS, but the
DTLS "tunnel" is terminated at some point and the SCTP peer does not runs SCTP/DTLS. In this case
using the CRC32c might make sense.

Best regards
> 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 <> 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 <>.  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)