Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-zero-checksum-01.txt

Michael Tuexen <michael.tuexen@lurchi.franken.de> Fri, 14 July 2023 09:02 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 2A0FFC15155A for <tsvwg@ietfa.amsl.com>; Fri, 14 Jul 2023 02:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.895
X-Spam-Level:
X-Spam-Status: No, score=-6.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 seEzOx5ATmJy for <tsvwg@ietfa.amsl.com>; Fri, 14 Jul 2023 02:02:52 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBE2C15154F for <tsvwg@ietf.org>; Fri, 14 Jul 2023 02:02:51 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:85a6:7e27:ddf8:905b]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 76D8D75EF180E; Fri, 14 Jul 2023 11:02:46 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <PA4PR07MB75686C11F8E26B19C119F7618734A@PA4PR07MB7568.eurprd07.prod.outlook.com>
Date: Fri, 14 Jul 2023 11:02:46 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F66EB8CB-3268-4387-AD60-16049B8A7321@lurchi.franken.de>
References: <168903148526.1545.5012365702693708952@ietfa.amsl.com> <PA4PR07MB75686C11F8E26B19C119F7618734A@PA4PR07MB7568.eurprd07.prod.outlook.com>
To: Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/GluWxKFd3_bUm-gsWGl9A9rHQU0>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-zero-checksum-01.txt
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: Fri, 14 Jul 2023 09:02:54 -0000

> On 14. Jul 2023, at 07:37, Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi Michael,
> I am fine with the adoption, I only have a comment on the procedural part that may be ambiguous so that I'd wish to suggest clarification.
> In section 3 it's specified that the Zero Checksum parameter may appear in INIT and INIT ACK so I assume that it can also be the Server side asking the Client for Zero Checksum by including the parameter in INIT ACK. Is this case the Client cannot confirm that it has accepted Zero checksum.
> It should be stated that it's always the Client asking for Zero Checksum and the Server MUST answer in INIT ACK.
Hi Claudio,

the intention is they each side declares whether it is willing to accept packets
with incorrect zero checksums. It is not a negotiation.
See for example the test case
https://github.com/sctplab/zero-checksum/blob/main/zero-checksum-tests/sctp-zero-checksum-07.pkt
where the client does not announce that it is willing to accept packets with zero
checksums, but the server does.
Please note that I have not updated the code to revision 01, but that is not relevant
for the point we are discussing.

Best regards
Michael
> 
> Best regards,
> Claudio.
> 
> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
> Sent: Tuesday, 11 July 2023 01:25
> To: i-d-announce@ietf.org
> Cc: tsvwg@ietf.org
> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-zero-checksum-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Transport Area Working
> Group (TSVWG) WG of the IETF.
> 
>   Title           : Zero Checksum for the Stream Control Transmission Protocol
>   Authors         : Michael Tüxen
>                     Victor Boivie
>                     Florent Castelli
>                     Randell Jesup
>   Filename        : draft-ietf-tsvwg-sctp-zero-checksum-01.txt
>   Pages           : 10
>   Date            : 2023-07-10
> 
> 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 an alternate method 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 a checksum in a backwards compatible way.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-zero-checksum/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-sctp-zero-checksum-01.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-sctp-zero-checksum-01
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>