IETF Logo Mail Archive

Re: [tsvwg] draft-tuexen-tsvwg-sctp-zero-checksum-02 adoption

tuexen@fh-muenster.de Thu, 13 April 2023 20:38 UTC

Return-Path: <tuexen@fh-muenster.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 BB775C152577 for <tsvwg@ietfa.amsl.com>; Thu, 13 Apr 2023 13:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ly3kEGgg42vg for <tsvwg@ietfa.amsl.com>; Thu, 13 Apr 2023 13:38:19 -0700 (PDT)
Received: from mx-out-02.fh-muenster.de (mx-out-02.fh-muenster.de [212.201.120.206]) (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 6D9A3C1522CB for <tsvwg@ietf.org>; Thu, 13 Apr 2023 13:38:18 -0700 (PDT)
Received: from mail-director-01.fh-muenster.de (mail-director-01.fh-muenster.de [185.149.215.227]) by mx-out-02.fh-muenster.de (Postfix) with ESMTPS id D02C5E0455; Thu, 13 Apr 2023 22:37:45 +0200 (CEST)
Received: from smtpclient.apple (ip4d15f76b.dynamic.kabel-deutschland.de [77.21.247.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: tuexen) by mail-director-01.fh-muenster.de (Postfix) with ESMTPSA id 9DEF01A004A; Thu, 13 Apr 2023 22:37:45 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B418E474-A6FC-412D-AB78-4A60D6103CC6"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: tuexen@fh-muenster.de
In-Reply-To: <6E829A1D-438E-4633-A1AC-A8341AC254A8@8x8.com>
Date: Thu, 13 Apr 2023 22:37:44 +0200
Cc: tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E521C310-4D4D-4851-A668-BDAE119D6C37@fh-muenster.de>
References: <9F7A670A-EA7E-4194-8125-B1DB7030802B@8x8.com> <CFBF062F-91DA-4B54-ACA9-36933EF08788@fh-muenster.de> <6E829A1D-438E-4633-A1AC-A8341AC254A8@8x8.com>
To: Nils Ohlmeier <nils.ohlmeier@8x8.com>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/BxTytTADxKYujCarBA38PI49YwE>
Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-zero-checksum-02 adoption
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: Thu, 13 Apr 2023 20:38:21 -0000

> On 13. Apr 2023, at 21:30, Nils Ohlmeier <nils.ohlmeier@8x8.com> wrote:
> 
> 
> 
>> On Apr 12, 2023, at 06:20, tuexen@fh-muenster.de wrote:
>> 
>>> On 11. Apr 2023, at 19:15, Nils Ohlmeier <nils.ohlmeier@8x8.com> wrote:
>>> 
>>> Hello,
>>> 
>>> I’m supporting adoption of draft draft-tuexen-tsvwg-sctp-zero-checksum-02, because it is going to be useful for all WebRTC endpoints out there to have the option to skip the checksum step.
>>> 
>>> I also reviewed the draft. The only concern I found is this sentence:
>>> 
>>> "Since the lower layer of SCTP can not be IPv4 or IPv6 as specified in [RFC9260] or UDP as specified in [RFC6951], no problems with middle boxes expecting correct CRC32c checksums in the SCTP packets are expected.”
>>> 
>>> Which confuses me, because it sounds to me like this is trying to say that SCTP over IPv4 or IPv6 can not be done. Which obviously doesn’t make any sense. But I honestly fail to parse what this sentence is suppose to tell me (besides no problems with middle boxes is expected).
>> Would using
>> 
>> One example of such a lower layer is the use of SCTP over DTLS as
>> described in [RFC8261] (as used in the WebRTC context). Counter
>> examples include:
>> 
>> * SCTP over IPv4 or IPv6 as specified in [RFC9260].
>> 
>> * SCTP over UDP as specified in [RFC6951].
>> 
>> * The use of SCTP Authentication as specified in [RFC4895].
>> 
>> Therefore using an incorrect zero checksum will not result in
>> problems with middle boxes expecting correct CRC32c checksums in SCTP
>> packets.
>> 
>> be clearer?
> 
> Yes I think that helps.
> I think if you expand the last sentence in our proposal to something like:
> 
> Therefore using an incorrect zero checksum when using SCTP over DTLS will not result in
> problems with the middle boxes expecting correct CRC32c checksums in SCTP packets.
> 
> Should remove any remaining ambiguity.
But we list DTLS over SCTP as an example. Some what about:

Therefore using an incorrect zero checksum, in particular when using SCTP over DTLS,
will not result in problems with the middle boxes expecting correct CRC32c checksums
in SCTP packets.

OK?

Best regards
Michael
> 
> Best
>   Nils

v2.29.0 | Report a Bug | By Email | System Status