Re: [TLS] DTLS/SCTP and fragmentation

Michael Tuexen <michael.tuexen@lurchi.franken.de> Mon, 05 April 2021 12:24 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 766623A169F for <tls@ietfa.amsl.com>; Mon, 5 Apr 2021 05:24:05 -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 b0YYn5WGzuRl for <tls@ietfa.amsl.com>; Mon, 5 Apr 2021 05:24:00 -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 5FBBF3A1699 for <tls@ietf.org>; Mon, 5 Apr 2021 05:24:00 -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 6113C7AAACE02; Mon, 5 Apr 2021 14:23:53 +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: <606AFECA.2010100@openfortress.nl>
Date: Mon, 5 Apr 2021 14:23:52 +0200
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <D1F47AE4-600F-4206-B203-0394ADFB86A4@lurchi.franken.de>
References: <6067909D.6090907@openfortress.nl> <606AFECA.2010100@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/V3orKhuDunNfhbfYvM9dNJQaMl4>
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:24:06 -0000


> On 5. Apr 2021, at 14:12, Rick van Rein <rick@openfortress.nl> wrote:
> 
> Hi,
> 
> 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?
Why do to use TLS over SCTP? It has substantial limitations. That is
why DTLS over SCTP was specified.
> 
> 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.
You still would need to preserve message boundaries, don't you?
> 
> 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.
My understanding is that Diameter wants reliable unordered delivery.
So basically you can send every diameter message as an unordered
SCTP user message. At least this is what is described in
https://tools.ietf.org/html/rfc6733#section-2.1.1

Best regards
Michael
> 
> 
> Hopefully helpful,
> -Rick
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls