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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 05 July 2023 14:06 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 C2D4DC151989 for <tsvwg@ietfa.amsl.com>; Wed, 5 Jul 2023 07:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 (1024-bit key) header.d=ericsson.com
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 KWHjGzEOLzVF for <tsvwg@ietfa.amsl.com>; Wed, 5 Jul 2023 07:06:07 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2068.outbound.protection.outlook.com [40.107.21.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20887C151710 for <tsvwg@ietf.org>; Wed, 5 Jul 2023 07:06:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YCIXJJQFVQXLEyJ2GV7daGD9nZz0PVEuZHzaKqPq0qi/qjXYu47mW00BYE6iL+ZCgl11FJvlnyA1GosTFEuR/H5ffYy7wKTnFzuY0VAhmVsP3IdqKcCqy9owQ9syvHkDMB2+0Cjb6P1Bc57j81j/AHsyZiv4M+JRZ7hNQ9yQ0Eo5VMExwpzIRBMAsPd8lFYWnqzMcln6P2fhtSASVHMydbHr8Y49tWrDFkzmOZc8cBSG+TsVSiD5G2VlILoAek/Tp+gqpYUKDOLs60DWrBrlcSsDDP/phm2nGvgzlxS9GgID9t95HmW2A6X6kskg5Lm2n6PFoi2HS5O/EQgqVAdgLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Xiz12A/Mobfvhpg8k33dzNxrPs9w1CXWbdJsdGxqrLI=; b=AmvOlZ47t1rRvbW+ZZ3PG1P7IGDXUNWAvG+j7aBvzKkqHrse8Q28/b051sYuXVf1sUlqoGNMvVzA11SnvVIuYbUJmILOpgu149v4sKAKZ2ZPZx1xAe2jltf7A94kfehVm/3RCt64jT/UyTzyZDh+z1TWlavTIP4f3jo89lkO4lUhMZDKyaR7eizGzCk4I2bPGH+TG5G6h0p5WpgCZkRSwmMd4NT7m+wbA4oz7H5ZaRBv1t+Dd42Fi4luTksoFA8uK7AonX+zc5310Y9bibsq1cVYLoOuUTcGzVI5148uygwJKVOR0xh45ox2CzcKdE3hfwTsCUwWbfCortSLb9D9sg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xiz12A/Mobfvhpg8k33dzNxrPs9w1CXWbdJsdGxqrLI=; b=pV7UFx2pAevxiK2BYzKIxX5LUjlRqPAobtxO0X4zh2VjrL8CWF7+04+7erZ2DX1dDp3L24R4020vVJ0KOPkKAErROqQoNMYtvJEcYKAGbX+y40yv95qDqMBaRpfD5hR3X8Z/mUZpAkdiVLZ3DIZwFq9HblFVgh2A2g8liIDdgdU=
Received: from DU0PR07MB8970.eurprd07.prod.outlook.com (2603:10a6:10:40e::17) by AM0PR07MB6370.eurprd07.prod.outlook.com (2603:10a6:20b:158::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6565.17; Wed, 5 Jul 2023 14:06:02 +0000
Received: from DU0PR07MB8970.eurprd07.prod.outlook.com ([fe80::38c7:d6ca:110a:abad]) by DU0PR07MB8970.eurprd07.prod.outlook.com ([fe80::38c7:d6ca:110a:abad%7]) with mapi id 15.20.6544.024; Wed, 5 Jul 2023 14:06:02 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "tuexen@fh-muenster.de" <tuexen@fh-muenster.de>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] draft-tuexen-tsvwg-sctp-zero-checksum-02 adoption
Thread-Index: AQHZbJk7z3EhoxIDRUqudPFN6tJMvq8nmQKAgAkvD5aADXc7AIAAnAN1gBVOioCAHQvrP4ADlQGAgDO2utSAAsMlAIAAGYfKgAA4U4CAACK3wA==
Date: Wed, 05 Jul 2023 14:06:02 +0000
Message-ID: <DU0PR07MB89709AB670EB65BF797FA40A952FA@DU0PR07MB8970.eurprd07.prod.outlook.com>
References: <9F7A670A-EA7E-4194-8125-B1DB7030802B@8x8.com> <CFBF062F-91DA-4B54-ACA9-36933EF08788@fh-muenster.de> <DU0PR07MB89700E9D84EBBEF2F8835C99959D9@DU0PR07MB8970.eurprd07.prod.outlook.com> <E9714E49-A217-4F58-A268-737CE5E0B414@fh-muenster.de> <DU0PR07MB89706AA16E41E379E9B0235E956A9@DU0PR07MB8970.eurprd07.prod.outlook.com> <4BB60EB7-4657-4AB6-8248-184D805D8C1F@fh-muenster.de> <DU0PR07MB8970830E1CD2331D8F708BF2954A9@DU0PR07MB8970.eurprd07.prod.outlook.com> <006237CC-AD1D-4C88-9CD7-619057620E8D@fh-muenster.de> <DU0PR07MB8970DABE8172D68941772A469529A@DU0PR07MB8970.eurprd07.prod.outlook.com> <40820EA5-FBDD-43FB-9A07-C8508D003957@fh-muenster.de> <DU0PR07MB897033EFCBE0EA168C41D9D3952FA@DU0PR07MB8970.eurprd07.prod.outlook.com> <AF21F7AE-EDD3-41EF-9306-1CAE3E4A3ED2@fh-muenster.de>
In-Reply-To: <AF21F7AE-EDD3-41EF-9306-1CAE3E4A3ED2@fh-muenster.de>
Accept-Language: en-US, sv-SE
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0PR07MB8970:EE_|AM0PR07MB6370:EE_
x-ms-office365-filtering-correlation-id: 11735060-b56a-488c-46f8-08db7d60f79a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: KukqYp2CgNrKJsBfc3nUVSmMoraqAf/9S0RCAJIhDX0pWNV0XD9ijO8ZHwdYip/8MAqL0Sj8Iqflj7DhfYDWLxjFsNHHF8QZeYsMDuIFauvsL00JGdLM2Kqi2WTwMkF/TV8HZr4nxOJFXCwDTKrszWoGyL/m2YWhH5TjkOi4dDgmk+UQAEZdM6BYb4QqvqOy9UFOlJaC4AB2HnqchPpHAwAc6rE3xP6YzAIzZIYNb7sqJt+UsIEFFNF5GbI7jnzsfFl8Pbtd08GM8VK8UmLovcd+pLOKKIXY31RK06oJGYaB+WLoyhpVy1oMVThY8RT8/H46kgFFR/bmvi19OOhA2FxrWnnlMCnuwrfOPkpU29i5eHZXn52OXJBCiHNURrfiPzOiisyDZpRQ+T5WyW4b8JxPmqriTEJaymZUWko2xy2Xtc+Ys3qwFzs5qyDjIznov5lwaoemRwjNDq1KFlP7uVeP0kWXAmQNoLgp8NSuOuRULjW8fC5xnjjaa0Dt35EQ0qcNBRoxvMAzYV005Rlzl1UIzFI6p0vgAnpDWT0Vy02tRgNlzrpzOZmUcD6j/G6nYgrsf/yVXmfws6KKCbhCP1WawiUsomioTzWFZcB3K4c=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0PR07MB8970.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(39860400002)(346002)(376002)(396003)(366004)(136003)(451199021)(44832011)(8936002)(8676002)(30864003)(52536014)(66574015)(83380400001)(41300700001)(66899021)(316002)(5660300002)(2906002)(99936003)(55016003)(82960400001)(122000001)(91956017)(66946007)(38100700002)(76116006)(6916009)(4326008)(64756008)(66446008)(66476007)(66556008)(86362001)(186003)(53546011)(478600001)(9686003)(26005)(6506007)(33656002)(7696005)(38070700005)(71200400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: gbE11DPwwL25trOxdc/CJibPhSBQxuc+xuVXKzVT8t51eXtnXYkL5Ms746GkTv836uxwTNpuUjkKkjVkk0POPOW26RvzxR9Llrv9sGrZDo/U4XcGdU8MLJRA2YuvqR4PZ1EN5JxoS5zBAp/4FcSdNqVwufUmciQZDlaHiedcdqapL3ajQP+nKCQot778KUaartDOiL1aB1OYwvnFO6BvOGl876sFOIpeHSGhDtAnnCJXe28LCxFMF4DnNDY0LV0IC3F3aE9SULrjdQhNfi0X8tGRg7AfuC8e3zgrAl07lomQb+yBV8ASuIHSCy+SlEpXnkX3onxoYR0UdN4YgRR4yoNzPoYjUNAV1H0UrgNgHX7d6qIda4WWw6IiE7i68EF/bX0eG/m5c1VDn7s3uDvEk47QovqMwyzJcv5LEvwsO5xo3yGTn0j48MKmVTwuv4wzqJ07lr+T6UCDWLNqyqioGLLwCjEtJhFJ8dPkoIVDct3mxyH4H7xlTbWEnqfMCUn6n5f/fFRyV9+7ov6Q0sbhTuEEivnE0SKfXvocF+JupsOiXoqczaGzYaNsFnobTkrcr7cJbRrYcPCirIM7ZiC29Mo0U0SQ/WvnPgNVHiocWfAalE6WNc3E/4DzSL47b+TxjqyZbNaXTErf0ZdCmwMBYbea05gf7PwDPIpNGc8BKDZaekhSmO790y3EqoRHkFoC+zAm7AZMMwxuxBVGnBrHGFRJ7c6VwYDIVuT3y0pIvB25c5bBsU5ZuwIMv3Uj1SuTek9nscIDzoHBfo8Tv+l0qSEODgReJ/B1mpXgVDsrlnP2tgzo3XVl+8O0nr4LChL4W3mhGecnHS1YuzB2upfuUDhWCnj6rvMoHFEqtS0oGaL0x7qlAKU0qvl5daItrX4seg5pjGcauspaS/nzLaAlhfjp4Y6uhxFQRd4F7x4TNbYuUk89FQt8vm/X41oLKR/K5Tq8jm6SRP62K5CnCm+WQhnHWqaGZMjKJ9DrHh+l7nazsv7xlQoaXcWA5BqfKUED5WS62ksJrYDMO62KRqvLYEoBLkCXMkBE++CFE+HB9mDbS4kqI8Ffm9oRDexlpVS+oTiUG2YQXwJMeOJrwMSVluJK1niqKXMJMHTSXVSmSE/ISzHan8y7/mayn7lV98v5gNQ+sdf4JRvB5a1oSXKZMJZo/e3eJXh4CR0M6I0i3WQNUtp++DGjQBfzcpJ8L8lUoU3fmbw9gN22nxXFzllWu3KJPheiLJEC1Fe0JSwH1DKrh8OKY+eyf4g8KoytkZAGBVuS/7CrO9EOB/Rms0vBnHtxBmdP/TztFBKp1nAq9JrHXWCwi5wqqan4o5WrFgr4YjyydaMCUHXKlkkjPEdnk+Wj500XpmqaTjqSRxc1e7mW1U5wM0vuTh37URftcb+xcvLPekdWZujSjfaZ8j2/hKazMHP2AlnFGzW6Wfm7x0oKHpynFz7jFMfSyxJCcx+21y3G7I51Hi5PgSALdiNyGKhE7ZJfZzWDRI26+EOlWpbL9+M+PX7tylYE1s1oIuEPSfI2Jd7BUldyKZIHMLH8YRVkRa0JzV9I7Rla6jrjl31A709GTzLvbqSZ0qfblax82Fj16+VV9yhJNHOPWjC86va2NYZxEP8GB432OVVqSok=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha256"; boundary="_C8E83BCC-BC34-1542-BFBE-F3E9D482726F_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0PR07MB8970.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 11735060-b56a-488c-46f8-08db7d60f79a
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2023 14:06:02.6998 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BKuEvnaO40yLO/xwnbKWJRoo/4JegQduk0cY7Xm3rHqiEekqxRgbQy6iGUR3x/zZ2aYyjuZQbhmHNgpkq2kOmdWv03RcsbRbH1ugt2A/bA0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6370
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/YwbBPdN6b0i5_6ET5WWd3bDVV2s>
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: Wed, 05 Jul 2023 14:06:11 -0000

Hi, 

Yes this sounds good. I was making it unnecessary complex not thinking about how simple this criteria for when it is possible to send zero value for these algorithms actually are. Looking forward to update draft so I can review it. 

Magnus 


On 2023-07-05, 13:57, "tuexen@fh-muenster.de" <tuexen@fh-muenster.de> wrote: 
> On 5. Jul 2023, at 10:44, Magnus Westerlund <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>> wrote: 

> 

> Hi, 

> Your proposal sounds good. That would mean that protection methods might have to specify additional criteria to fulfill to be able to set the CRC field 

OK. I'll update the document and submit an updated version. 

> to all 0. In the review and development of the zero checksum document towards WG LC if there are a common set of rules that have minimal impact on the DTLS encapsulation case we should consider those. The common rules would be to generalize the rules for when to one may send zero value, such that it apply to SCTP-AUTH or CRYPTO chunk when UDP encapsulated. This to minimize the implementation variations depending which protection one applies. 

I think we should keep the requirements for the receiver side at a minimum. At the sender side, you can 

always send with a correct checksum. 



For the alternate methods I see a simple way of specifying it: 

1. For AUTH: 

Sender side: Allow a zero checksum for all packets having an AUTH chunk as the first chunk. 

Receiver side: Accept a zero checksum only for packets having an AUTH chunk as the first chunk. 



2. For CRYTO: 

Same as above, just replace AUTH by CRYPTO. 



Implementation wise: I guess most SCTP stacks will not implement multiple alternate methods. 

* The WebRTC implementations won't most likely use AUTH or CRYPTO. 

* Implementations supporting CRYTO don't need AUTH and are not used over DTLS. 



In the process of updating the ID RFC 4895bis, I'll implement the change to see what the 

impact is. 



Best regards 

Michael 

> Cheers 

> Magnus 

> On 2023-07-05, 09:04, "tuexen@fh-muenster.de <mailto:tuexen@fh-muenster.de>" <tuexen@fh-muenster.de <mailto:tuexen@fh-muenster.de>> wrote: 

> > On 4. Jul 2023, at 10:11, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org <mailto:40ericsson.com@dmarc.ietf.org>> wrote: 

> > > Hi Michael, 

> > So I fail to see the additional complexity beyond the initial negotiation being different. The draft (-00) rules for when to send with a zero value CRC only needs a minor tweak to account for both SCTP-AUTH and CRYPTO chunk. This tweak is that the selected protection mechanism to enable zero checksum would be to require to have reached established state in the SCTP state machine as well as not include it on INIT, INIT-ACK, COOKIE, Cookie-echo and in general packets with ASCONF chunks and OOB responses. When the crypto chunk using SCTP association reaches established state it will be protected. And before that no significant ULP data will flow over the association so the goal is meet. So even if DTLS encapsulation of SCTP association could run zero checksum from the first packet it is not necessary, and gives no practical benefit as it is so few packets until established state. So I think that is a very pragmatic way of doing it that keeps code clean. When it comes to UDP encapsulation, yes there could theoretically exist a firewall that verifies the SCTP CRC in a IP/UDP/SCTP packet. However, we have no knowledge of such a middlebox, does anyone in the WG know of such a one? The important difference here is that where IP/UDP is handled by all middleboxes, and IP/SCTP by some, we are getting into quite exotic territory with IP/UDP/SCTP, especially if one are not using the default UDP port for encapsulation. However, firewalls being overly suspicious are a reality for general internet deployments and affects all type of applications, but it doesn’t stop us from defining specifications that works in general but not in all corner cases. IP/UDP/SCTP has a general Internet checksum in UDP that help ensure that IP/UDP can be verified to a not been unintentional be broken with a certain probability. Further encapsulation or a SCTP strong packet authentication will verify that SCTP is not broken. So the only potential downside we are talking about here is a path failure. And if you are sensitive to that in your intended deployment then don’t do this trick to save resources use full CRC32c. In fact there is a very easy fall back if the SCTP association times out after having been established and then switched to zero checksum. Re-establish it without using it. As we have seen with the SCTP NAT discussion which is a harder problem I agree, attempting to have a bullet proof solution is preventing the evolution. If one are running encrypted encapsulation of the SCTP association, then one are 100% sure that no other than the endpoints. But, I think this is one case where I don’t expect any significant problem and there are choices a deployment can do. Cheers 

> Hi Magnus, 

> what about the following way forward: 

> 1. The zero checksum document will refer to alternate protection methods and 

> the negotiation will be extended to declare support of a single alternate 

> protection method, which is encoded by an IANA assigned number. 

> The zero checksum document will create this registry. 

> 2. The zero checksum will specify the requirements for alternate protection 

> methods (basically that the protection is at least as god as CRC32c and 

> no interference with middle boxes) 

> 3. The zero checksum document will specify a single alternate protection 

> method: the protection by the lower layer DTLS. 

> 4. If wanted, I can add some text to RFC 4895bis, to allow it to be 

> an alternate method. The middlebox discussion will go here. 

> 5. If wanted, you can add some text to the CRYPTO document to 

> allow it to be an alternate method. The middlebox discussion will go here. 

> This allows us to decouple the document and to implement zero checksum 

> for WebRTC without have in to deal with SCTP AUTH and/or CRYPTO. 

> Would you be fine with the above approach? 

> Best regards 

> Michael 

> > Magnus 

> > On 2023-05-31, 17:13, "tsvwg" <tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org>> wrote: 

> > > On 29. May 2023, at 10:56, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org <mailto:40ericsson.com@dmarc.ietf.org>> wrote: 

> > > > Hi Michael, 

> > > Sorry for the delay in answering. So if I understand the issue is the dependency on the protection mechanism being in place to enable zero checksum. So I think your proposal for including a list of entries representing offered protection mechanism that would allow zero checksum work, and each of them define the criteria for when in the handshaking zero checksum can be enabled would work. You would be able to add SCTP- 

> > Hi Magnus, 

> > yes, I think it works. I'm just wondering if we actually need this complexity. 

> > > AUTH immediately. 

> > I'm not sure here. Claudio indicated that there are middleboxes that verify the checksum 

> > of SCTP. I do no understand why NATs would do this, but it might make sense for firewalls 

> > validating the packet format (I know that packet validation exists in products, but I'm 

> > not sure if this includes checksum validation). 

> > So the protection is OK for all packets where the first chunk is an AUTH chunk. 

> > But the middlebox issue is still there. So we would require UDP encapsulation 

> > in addition (which is per path and can change over time). But we would assume 

> > that for UDP encapsulated packets, the SCTP would not be validated. 

> > > I do wonder a bit if DTLS encapsulation is a method requiring to be listed. If it is encapsulation of the whole SCTP packet 

> > > that provides a stronger integrity to the packet, then does it need to be specified? It will be in place from the start, and thus the initiator How does the sender know which packets the receiver is willing to accept. This depends on the mechanism 

> > being used instead of CRC32c. For example, using AUTH, the packet containing an INIT ACK chunk would 

> > need to have a valid checksum, but for DTLS encapsulation the ckecksum could be zero. 

> > > might not need to do more than to indicate that it will rely on the used encapsulation? In regards to middleboxes doing deep inspection, and calculating the CRC32c of an UDP encapsulated SCTP packet and then react to it being wrong. I would be quite surprised to find a middlebox that Why would it be wrong for SCTP over UDP over IP, but OK for SCTP over IP? I do not see the difference. 

> > If you have a firewall which does some SCTP level protection and you deploy SCTP over UDP, you 

> > would like the firewall to do the same of SCTP over UDP over IP. Why would you not want the 

> > same level of protection depending on UDP encapsulation or not? 

> > > does this fairly deep layer violation. Only if one are running on the registered UDP port for SCTP encapsulation a general middlebox know that this is likely SCTP in the payload. I am not expecting this to be a real issue for this solution. Especially not where we would consider deploying a zero checksum solution where the set of middleboxes would be deployed by the same entity that deploys the endpoints. 

> > What about other middleboxes which might be deployed? 

> > Best regards 

> > Michael 

> > > Cheers 

> > > Magnus 

> > > On 2023-05-10, 22:54, "tuexen@fh-muenster.de <mailto:tuexen@fh-muenster.de>" <tuexen@fh-muenster.de <mailto:tuexen@fh-muenster.de>> wrote: 

> > > > On 27. Apr 2023, at 09:31, Magnus Westerlund <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>> wrote: 

> > > > > Hi, 

> > > > Yes proposed change would address my issue. Thanks 

> > > Hi Magnus, 

> > > I wanted to address this issue before submitting version -03 of the individual 

> > > draft, followed up by the -00 version of the WG document. 

> > > However, when drafting the text, I realized that this is more complex than 

> > > I initially thought. 

> > > Your suggestion is to allow zero checksum when using SCTP AUTH or CRYPTO. 

> > > One issue the related to the middleboxes and one could argue that when using 

> > > SCTP over UDP, middleboxes might not interfere with zero checksum. OK, we 

> > > can write that without make things more complex. 

> > > When using DTLS, all packets are protected. Requiring that packets containing 

> > > an INIT chunk is for backwards compatibility and is not specific to SCTP/DTLS 

> > > and would require to all other cases. The same applies to packets containing 

> > > an COOKIE ECHO or ASCONF chunk. This is for keeping implementations simple. 

> > > But there is a difference between SCTP/DTLS and AUTH or CRYPTO: 

> > > * For CRYPTO (as I understand it right now) does not protect packets handled 

> > > in the front states. 

> > > * For AUTH, it protects only packets for which the AUTH chunk is the first one. 

> > > This means that the packets having an alternative protection depends on the 

> > > alternative method. How does the receiver know? How to specify it in a generic 

> > > way that it includes CRYPTO, for example, without referring to it? 

> > > One possibility would be to extend the Zero Checksum Parameter to contain an 

> > > uint32_t, which is an IANA registered value indicating the alternative method. 

> > > The document could define one for SCTP over DTLS, and one for using AUTH. 

> > > Then the CRYTO document could register another one for CRYPTO and provide 

> > > the rules. 

> > > However, I'm still contemplating whether this is worth doing. If middleboxes 

> > > check the CRC32c (which would kill zero checksum for AUTH and CRYPTO for 

> > > SCTP/IPv46), why shouldn't they do the same when SCTP is UDP encapsulated? 

> > > Assuming that they don't do it now, because SCTP over UDP is not used a lot 

> > > right now, does not extrapolate to the case where some specifications exist, 

> > > which require SCTP (with CRYPTO or AUTH) over UDP. 

> > > What do you think? 

> > > I submitted -03 of the individual document and the -00 of the WG document, 

> > > because I did not want to hold them up any longer. Once we have come 

> > > to a conclusion on the above discussion, I'll update the document accordingly. 

> > > Best regards 

> > > Michael 

> > > > Magnus 

> > > > On 2023-04-27, 00:13, "tsvwg" <tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org>> wrote: 

> > > > > On 18. Apr 2023, at 11:06, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org <mailto:40ericsson.com@dmarc.ietf.org>> 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. 

> > > > Then: 

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

> > > > Michael 

> > > > > Cheers 

> > > > > Magnus 

> > > > > On 2023-04-12, 14:21, "tsvwg" <tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org>> wrote: 

> > > > > > On 11. Apr 2023, at 19:15, Nils Ohlmeier <nils.ohlmeier@8x8.com <mailto: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? 

> > > > > Best regards 

> > > > > Michael 

> > > > > > > Best 

> > > > > > Nils Ohlmeier