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, 5 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