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

Michael Welzl <> Tue, 11 April 2023 09:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47860C15152D for <>; Tue, 11 Apr 2023 02:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T6iZoxAGqeak for <>; Tue, 11 Apr 2023 02:28:59 -0700 (PDT)
Received: from ( [IPv6:2001:700:100:8210::71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 4D598C14CE42 for <>; Tue, 11 Apr 2023 02:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=key2103; h=Message-Id:In-Reply-To:To:References:Date:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=leukrctMKfiQUcf9R6l33HBtZbNdi9xny51qietA5Y4=; b=UPxDJLb+JndoLP32sqHGcsj0V7 Y67q3zZ3N1pFzNTisBlSdjlRpWBpO46neuk6iLu1yfHxOy1KPWHQ7x8ezfDZUyaTDlwrw4k5h4VlC vMU1eKxq8yt2rq6HR15M7HLPmvg6P+zPFF2SNgpZ2FZQnSGdwZ6EoIwZ5dMBzeVHaNT9Rv9yebrbH VnnRfbkUIYN87L/qcl0HPhv4kWIBuBvSkrHc3t9ODLkAKkt6Jk326luIwssjLC7+mNuha7RAdCGem p7BlTUZcC0s50C96FhnldBrfDJ+dLWJ20Vafy1HFLQ8Dk8b8XpX0Oo2b4TT3PpxXRNk42AigG3OXd upvHzHXQ==;
Received: from ([]) by with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <>) id 1pmAJ4-00CjqA-1J for; Tue, 11 Apr 2023 11:28:54 +0200
Received: from ([] by with esmtpsa (TLS1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256) user michawe (Exim 4.96) (envelope-from <>) id 1pmAJ3-0000lb-1f for; Tue, 11 Apr 2023 11:28:54 +0200
From: Michael Welzl <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Date: Tue, 11 Apr 2023 11:28:49 +0200
References: <>
To: "" <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3696.
X-UiO-SPF-Received: Received-SPF: neutral ( is neither permitted nor denied by domain of client-ip=;;;
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.058, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 713740F03D698101626C1395DFFC9F71D8085BB7
X-UiOonly: 89FC6A68E1D0044E2D901F60D0AA1562B8D191BF
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 09:29:04 -0000


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."

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".


> 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)