Re: [tsvwg] DTLS 1.3 over SCTP

Michael Tuexen <michael.tuexen@lurchi.franken.de> Fri, 14 July 2023 09:14 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 636DFC15155B for <tsvwg@ietfa.amsl.com>; Fri, 14 Jul 2023 02:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sbnS-nJ3pl75 for <tsvwg@ietfa.amsl.com>; Fri, 14 Jul 2023 02:14:10 -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 C5ABEC15155A for <tsvwg@ietf.org>; Fri, 14 Jul 2023 02:14:10 -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 AA9F175EF180E; Fri, 14 Jul 2023 11:14:07 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <PA4PR07MB7568B70C363F70CA9CF005648734A@PA4PR07MB7568.eurprd07.prod.outlook.com>
Date: Fri, 14 Jul 2023 11:14:07 +0200
Cc: tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B35A9C2C-9360-4248-B0FA-552ADC1F5D05@lurchi.franken.de>
References: <0C990143-D450-4288-9390-E06D3469FF1D@lurchi.franken.de> <PA4PR07MB7568B70C363F70CA9CF005648734A@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/Y4rsGUH2ySlFAnSHiDt9QSyv7gI>
Subject: Re: [tsvwg] DTLS 1.3 over SCTP
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:14:15 -0000

> On 14. Jul 2023, at 08:04, Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi Michael,
> I am reading this new draft but I have a quick comment at once.
> The requirements from 3GPP towards SCTP are far beyond the limit of 64k, for instance S1-AP needs up to 142k.
Hi Claudio,

could you provide some insight what kind of signalling message needs up to 142KB?
Just wondering what kind of information needs 142 KB.
> This new draft improves the situation but doesn't solve it.
The focus is not limited to 3GPP. We are trying to improve the situation
for RFC 6083 with minimizing the changes.

Best regards
Michael
> 
> Best regards,
> Claudio
> 
> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Michael Tuexen
> Sent: Thursday, 13 July 2023 16:35
> To: tsvwg IETF list <tsvwg@ietf.org>
> Subject: [tsvwg] DTLS 1.3 over SCTP
> 
> Dear all,
> 
> Hannes Tschofenig and myself have submitted an ID for using DTLS 1.3 over SCTP:
> https://www.ietf.org/archive/id/draft-tuexen-tsvwg-rfc6083-bis-02.html
> 
> This is an alternative to
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-dtls-over-sctp-bis-06.html
> 
> Our document is based on RFC 6083. The major differences are:
> * Use DTLS 1.3 instead of DTLS 1.0
> * Use key updates instead of renegotiation. This limits the number of
>  rekeyings to 2^64, but that should not limit in real world scenarios.
> * Bump the maximum user message size to 64KB by using RFC 8449.
> 
> Any comments welcome.
> 
> Best regards
> Michael