[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