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

Michael Tuexen <michael.tuexen@lurchi.franken.de> Tue, 11 April 2023 09:47 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
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 BCDE7C14CE42 for <tsvwg@ietfa.amsl.com>; Tue, 11 Apr 2023 02:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=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 HjCgl6yyPVyA for <tsvwg@ietfa.amsl.com>; Tue, 11 Apr 2023 02:47:46 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EB5C14F73E for <tsvwg@ietf.org>; Tue, 11 Apr 2023 02:47:44 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:ed58:432e:c240:748]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 39D9D74C7607B; Tue, 11 Apr 2023 11:47:40 +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 <michael.tuexen@lurchi.franken.de>
In-Reply-To: <78604000-0F5E-4E09-8CC3-0BEB06ABC5CF@ifi.uio.no>
Date: Tue, 11 Apr 2023 11:47:39 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1676DA2-6BEE-4613-A56E-F850D8AC7EA5@lurchi.franken.de>
References: <e9c1cb50-64cb-3d13-2c57-ffb15a101059@erg.abdn.ac.uk> <78604000-0F5E-4E09-8CC3-0BEB06ABC5CF@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1vAFtM5pCqLJ_-MXsRdr1O6wh_Q>
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:47:47 -0000

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

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.

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