Re: [TLS] DTLS/SCTP and fragmentation

Rick van Rein <> Mon, 05 April 2021 12:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5572B3A1615 for <>; Mon, 5 Apr 2021 05:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OOGnGUEGaXgy for <>; Mon, 5 Apr 2021 05:13:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F4463A1613 for <>; Mon, 5 Apr 2021 05:13:10 -0700 (PDT)
Received: from ([]) by with ESMTP id TO6Nl9o0uMxedTO6Ol8KeE; Mon, 05 Apr 2021 14:13:08 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=fame; t=1617624781; h=message-id : date : from : mime-version : to : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=eTguid3KxApgDx4BFltqU7rv6KXwUlAVe4f8lIzMink=; b=kmyadRbFAYJxsDG/TMuQnlDlCNSBKn91isIior58/XvRPwhMmPGJ1fAm Vfj6QxALi+W3qLIzwQPvPf5alcqKATtylOCYdDhLXqQLneYnSBByhXY8O0 4LSerIWuwVrzav5NjO1RT6LMaUWHe0H4J0ZukonkqdM/y671fvupwaDik=
Received: by (Postfix, from userid 1006) id 639E950038; Mon, 5 Apr 2021 12:13:01 +0000 (UTC)
Received: from airhead.local ( []) by (Postfix) with ESMTPA id 3ACE950033; Mon, 5 Apr 2021 12:13:00 +0000 (UTC)
Message-ID: <>
Date: Mon, 05 Apr 2021 14:12:58 +0200
From: Rick van Rein <>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "" <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4
X-CMAE-Envelope: MS4xfCR29UqU5Cu3z/CH+FH2dd12n345yGAKF6kXXip/pg4VG3mCFu5VVNZCMK5TU9dSUnhjqu2yNCNGwk4E+hi6AHGcwv12w4yYMrYf7BUJaSxokmhIzhyW btjE0UsYMXsI1Tyc8gU/FY3wKWM1kqM4VblFrpC5cFRCaNGzgUDKm/IYO4lbPIIl5zy/Vl/XAOwX8Q==
Archived-At: <>
Subject: Re: [TLS] DTLS/SCTP and fragmentation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Apr 2021 12:13:19 -0000


Larger frames than the MTU are not just a problem to Diameter; they also
complicate the normal handshake in DTLS which is a bit of a misfit with
DTLS delivery semantics.

Since the version is bit-swapped in DTLS, each record can easily be
distinguished as being either DTLS or TLS.  Then, why not allow the
mixing of those records in a stream, and map them differently to the
transport protocol?

I suppose the records could be marked as being the first and/or last in
a large user message, and this could be meaningfully translated to
properties and behaviour of the transport.  Below the DTLS MTU,
information is sent as DTLS, and above it, it is sent as a sequence of
TLS frames -- or are rejected, if the transport cannot handle that.
Plain TLS could be a special case where the DTLS MTU is set to 0.

Datagrams may have a number of meanings, too, that translate to
different transport meanings.  Diameter differs from RTP in that it
wants reliable delivery (which is why it does not carry over UDP) but it
is like RTP in that it does not want ordered delivery.  Plain TLS
applications would present the usecase of reliable ordered delivery.

Hopefully helpful,