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 10:03 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 BA26DC14CF09 for <tsvwg@ietfa.amsl.com>; Tue, 11 Apr 2023 03:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_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 Txaxw0FuNybR for <tsvwg@ietfa.amsl.com>; Tue, 11 Apr 2023 03:03:32 -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 783DFC14CE42 for <tsvwg@ietf.org>; Tue, 11 Apr 2023 03:03:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ifi.uio.no; s=key2103; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To: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=JjpincyXGnHpVkrYuzDbNFhMM1O3j4KsTFzARry82Lg=; b=Bk6a2g4sBIDHT4q4AgJEAuhYH3 OBEsZ+2kfyyYTniYY4vB7b5+d9ZMGTqAcmp03uiQ5T7ieoDzhPm/oqebLD2gy1svF359OH7xvMfVe pPZhDYFuA/GboSDdo2TLBsgIPpgf3dEbQuT+PIx36rlekdgJ6NSjgRU5kAhx7BT+fRZZNz37gLP0Z uqRuACSql0C3hknF0aB/+Ys+S6/boejJfBay6YHsa902dvY0WLFRICQjXbnTOW88kQxOI0E21GsU8 v/vbIk6OlJRT+2oGSNTxkstkQFJLQCs7NdduxRxl1aT9Xu7o/r76HT2vHn7dJNKiY320YztKs0TZT iopoz2Sg==;
Received: from mail-mx03.uio.no ([129.240.10.15]) 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 1pmAqX-00Cmvp-1t; Tue, 11 Apr 2023 12:03:29 +0200
Received: from 178.165.194.79.wireless.dyn.drei.com ([178.165.194.79] helo=smtpclient.apple) by mail-mx03.uio.no with esmtpsa (TLS1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256) user michawe (Exim 4.96) (envelope-from <michawe@ifi.uio.no>) id 1pmAq6-0009Xz-1D; Tue, 11 Apr 2023 12:03:29 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <D1676DA2-6BEE-4613-A56E-F850D8AC7EA5@lurchi.franken.de>
Date: Tue, 11 Apr 2023 12:02:00 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F384EB80-5D85-40CA-BB20-3209CBB9D0BD@ifi.uio.no>
References: <e9c1cb50-64cb-3d13-2c57-ffb15a101059@erg.abdn.ac.uk> <78604000-0F5E-4E09-8CC3-0BEB06ABC5CF@ifi.uio.no> <D1676DA2-6BEE-4613-A56E-F850D8AC7EA5@lurchi.franken.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.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=-5.0, required=5.0, autolearn=disabled, AWL=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 51E230D16BC658B99C13F4EF77D7556147C34B2B
X-UiOonly: D23FB211C722EDB2600DAA6CED6C2D695D7B7783
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/PSzrfiPQRNdMMyf3ub1RSOMIDLk>
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 10:03:37 -0000


> On Apr 11, 2023, at 11:47 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> 
>> On 11. Apr 2023, at 11:28, Michael Welzl <michawe@ifi.uio.no> 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 <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)
>>> 
>>> 
>> 
>