Re: [TLS] DTLS/SCTP and fragmentation
Michael Tuexen <michael.tuexen@lurchi.franken.de> Mon, 05 April 2021 12:18 UTC
Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3333A1658 for <tls@ietfa.amsl.com>; Mon, 5 Apr 2021 05:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOJAOHlt3bNE for <tls@ietfa.amsl.com>; Mon, 5 Apr 2021 05:18:43 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DECF3A1652 for <tls@ietf.org>; Mon, 5 Apr 2021 05:18:42 -0700 (PDT)
Received: from [IPv6:2a02:8109:1140:c3d:98a3:657e:a126:66e5] (unknown [IPv6:2a02:8109:1140:c3d:98a3:657e:a126:66e5]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id B558F7AACAB0F; Mon, 5 Apr 2021 14:18:35 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <6067909D.6090907@openfortress.nl>
Date: Mon, 05 Apr 2021 14:18:35 +0200
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F261C0D-4382-4ABE-9E32-F5FCA3FD4C1E@lurchi.franken.de>
References: <6067909D.6090907@openfortress.nl>
To: Rick van Rein <rick@openfortress.nl>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iV4uDXHIJYcodX5jt3PBoul2kqg>
Subject: Re: [TLS] DTLS/SCTP and fragmentation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Apr 2021 12:18:48 -0000
> On 2. Apr 2021, at 23:46, Rick van Rein <rick@openfortress.nl> wrote: > > Hello, > > I was looking into DTLS/SCTP as a carrier for Diameter. Lengths in > Diameter are 24 bit to avoid ever having to bother about that, but when > run over the preferred DTLS/SCTP carrier this may yet be a concern, so > that its only option is to fallback to a _separate_ TLS/TCP connection: > > * For DTLS over TCP or SCTP, which automatically fragment and > reassemble datagrams, there is no PMTU limitation. However, the > upper layer protocol MUST NOT write any record that exceeds the > maximum record size of 2^14 bytes. > > SCTP can offer better guarantees than UDP; this relaxation may provide > leverage to split a large application message into a sequence of DTLS > frames carried under specific guarantees. > > 1. To handle a larger application message, it is split into pieces > of 2^14 bytes, followed by one that has <2^14 (possibly 0) bytes. > Fragments are sent to the same stream, without interleaving other > content, and in-order. Upon reception, the DTLS frames are each > decoded and the result concatenated to recover the message. Doesn't that results in head of line blocking? > > 2. Since delivery is reliable for SCTP, it would (also) be possible > to send the same sequence number for the fragments. The sequence > number field is not as useful for SCTP as it is for UDP. > > 3. It may be an idea to allocate one stream for all fragmentation. > But even within a stream, it is possible to combine in-order and > out-of-order. It is probably good to continue in-order sending > until the <2^14 sized DTLS frame is acknowledged. The application > or DTLS handshake may further constrain this. > > These are three possible ways of relaxing this. If we pick a simple > one, like the 1st, we might pass more SCTP semantics over to the > application that wants DTLS but not its size constraints. What DTLS > does to Diameter is best resolved. What about using: https://tools.ietf.org/html/draft-westerlund-tsvwg-dtls-over-sctp-bis-01 Best regards Michael > > > I hope this is useful, > > Cheers, > > Rick van Rein > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- [TLS] DTLS/SCTP and fragmentation Rick van Rein
- Re: [TLS] DTLS/SCTP and fragmentation Rick van Rein
- Re: [TLS] DTLS/SCTP and fragmentation Michael Tuexen
- Re: [TLS] DTLS/SCTP and fragmentation Michael Tuexen
- Re: [TLS] DTLS/SCTP and fragmentation Rick van Rein
- Re: [TLS] DTLS/SCTP and fragmentation Martin Thomson