Re: [tsvwg] draft-tuexen-tsvwg-sctp-zero-checksum-02 adoption Wed, 26 April 2023 22:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DA2DC15154F for <>; Wed, 26 Apr 2023 15:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5O8IChF0HP3G for <>; Wed, 26 Apr 2023 15:13:28 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 26139C15153F for <>; Wed, 26 Apr 2023 15:13:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 45F5E20420; Thu, 27 Apr 2023 00:12:55 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: tuexen) by (Postfix) with ESMTPSA id 06EB21A004A; Thu, 27 Apr 2023 00:12:54 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_AFF282E8-3A17-4991-9A9D-8F34014ED8BB"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
In-Reply-To: <>
Date: Thu, 27 Apr 2023 00:12:54 +0200
Cc: Nils Ohlmeier <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Magnus Westerlund <>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <>
Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-zero-checksum-02 adoption
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Apr 2023 22:13:30 -0000

> On 18. Apr 2023, at 11:06, Magnus Westerlund <> wrote:
> Hi Michael,
>  I am slightly confused by your exclusion of UDP for the zero checksum. I would expect that IP/UDP/SCTP per RFC 6951 would actually make it across a network unless a firewall was present that actually checked the CRC on SCTP level with that encapsulation. Which would in fact be a bit surprising as the UDP payload can be a bit of anything unless the UDP port reveals the service and special rules exists.  
Hi Magnus,

there is an IANA assigned UDP port number. So firewalls could use this. However, I don't know if
any product does now or will do in the future.
>  Thus, I would expect that SCTP zero checksum should be possible to deploy when RFC 6951 encapsulation occurs and the SCTP stack would be using SCTP-AUTH or CRYPTO chunk as alternative strong integrity verification.  So I think the zero checksum could actually be allowed for UDP encapsulated SCTP when using a strong integrity mechanism. Just want to ensure that the document doesn’t include unnecessary scoping which doesn’t have technical merit.
I agree. Possibly we should be more precise:

* We should not talk about lower layers providing a protection at least as good as CRC32c, but talk about other
  protocol mechanisms instead. These protocol mechanisms include lower layers like DTLS, but also AUTH or CRYTO.
* We should consider two conditions, where the use of the feature is not appropriate:
  (1) There is no other protocol mechanism to protect a packet at least as good as CRC32c.
  (2) Middleboxes will interfere with SCTP packets containing an incorrect checksum of zero.

* SCTP over DTLS is OK, since (1) and (2) are both not true.
* SCTP over IP is not OK, since (1) and (2) is true.
* SCTP using AUTH for all chunks over IP is not OK, since (2) is true.
* SCTP over UDP over IP is not OK, since (1) is true. Whether (2) is true is not known to me.
* SCTP using AUTH for all chunks over UDP over IP  might be OK, if (2) is not true.
* SCTP using CRYTO is not OK, since (2) is true.
* SCTP using CRPTO might be OK, if (2) is not true.

Would such a change address your issue?

Best regards
>  Cheers
>  Magnus
>    On 2023-04-12, 14:21, "tsvwg" <> wrote:
> > On 11. Apr 2023, at 19:15, Nils Ohlmeier <> 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?
>  Best regards
> Michael
> > > Best
> >  Nils Ohlmeier