[TLS] DTLS/SCTP and fragmentation
Rick van Rein <rick@openfortress.nl> Fri, 02 April 2021 21:46 UTC
Return-Path: <rick@openfortress.nl>
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 68F003A24E3 for <tls@ietfa.amsl.com>; Fri, 2 Apr 2021 14:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl
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 9g0Smq3uvKgr for <tls@ietfa.amsl.com>; Fri, 2 Apr 2021 14:46:27 -0700 (PDT)
Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (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 8DFA63A24E1 for <tls@ietf.org>; Fri, 2 Apr 2021 14:46:25 -0700 (PDT)
Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud7.xs4all.net with ESMTP id SRcTlr0UEMxedSRcUlzNfa; Fri, 02 Apr 2021 23:46:22 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1617399972; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=jivVdE3N1A7YHkioZlE5F648mnYZSt6oXcyg86hIfIM=; b=df6iqjCi74H2xutWyk3cWWHBv6BSt4gTebllYAC+iPXEPVQfQt8F3Hox /QSDfmdKw6zmuPuybCA5X4PmVkczttS9yFn9WQ6Lbn5SByFw/Prz07irtg aUafR0FBfwx2MCbUwV3V6uPLdoCguBo3dN81+k0V26Ob8VRR2Tg56r7rQ=
Received: by fame.vanrein.org (Postfix, from userid 1006) id 3C00A4C38A; Fri, 2 Apr 2021 21:46:12 +0000 (UTC)
X-Original-To: tls@ietf.org
Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 022A74C364; Fri, 2 Apr 2021 21:46:06 +0000 (UTC)
Message-ID: <6067909D.6090907@openfortress.nl>
Date: Fri, 02 Apr 2021 23:46:05 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
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: MS4xfN/PEF9XeUiu5cVmn8zy5Us6NJUYde74sXAilvrlBaB4YfsqeNjYXnWhyUumom0ltxgDIcS3z90Tf6TIKDQXXUCjxTaEhSARPFO3Crex3ZQTG6R1Y8OX VJnyNmhU67s9is4vUsLffNVto7lpPSaS2Gjpb1PB1q3jfV7ZII2b6ov9dJ2hHZaU+B96CFAjnwFkAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dEfDQGnYQgx_6TXN2wUREAjUQgM>
Subject: [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: Fri, 02 Apr 2021 21:46:33 -0000
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. 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. I hope this is useful, Cheers, Rick van Rein
- [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