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

Michael Welzl <michawe@ifi.uio.no> Tue, 11 April 2023 09:29 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47860C15152D for <tsvwg@ietfa.amsl.com>; Tue, 11 Apr 2023 02:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ifi.uio.no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6iZoxAGqeak for <tsvwg@ietfa.amsl.com>; Tue, 11 Apr 2023 02:28:59 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [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 ietfa.amsl.com (Postfix) with ESMTPS id 4D598C14CE42 for <tsvwg@ietf.org>; Tue, 11 Apr 2023 02:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ifi.uio.no; 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 mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <michawe@ifi.uio.no>) id 1pmAJ4-00CjqA-1J for tsvwg@ietf.org; Tue, 11 Apr 2023 11:28:54 +0200
Received: from 178.165.194.79.wireless.dyn.drei.com ([178.165.194.79] helo=smtpclient.apple) by mail-mx04.uio.no with esmtpsa (TLS1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256) user michawe (Exim 4.96) (envelope-from <michawe@ifi.uio.no>) id 1pmAJ3-0000lb-1f for tsvwg@ietf.org; Tue, 11 Apr 2023 11:28:54 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Tue, 11 Apr 2023 11:28:49 +0200
References: <e9c1cb50-64cb-3d13-2c57-ffb15a101059@erg.abdn.ac.uk>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
In-Reply-To: <e9c1cb50-64cb-3d13-2c57-ffb15a101059@erg.abdn.ac.uk>
Message-Id: <78604000-0F5E-4E09-8CC3-0BEB06ABC5CF@ifi.uio.no>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 178.165.194.79 is neither permitted nor denied by domain of ifi.uio.no) client-ip=178.165.194.79; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple;
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: <https://mailarchive.ietf.org/arch/msg/tsvwg/b4dTsjg4P_CdkKn-u5iduEGa9Vc>
Subject: Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-sctp-zero-checksum - to conclude 25th April 2023
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Apr 2023 09:29:04 -0000

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

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 <gorry@erg.abdn.ac.uk> 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 <tsvwg-chairs@ietf.org>.  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)
> 
>