Subject: [TLS] DTLS/SCTP and fragmentation

From: Rick van Rein <[email-masked]>
Date: Fri, 02 Apr 2021 23:46:05 +0200

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

---

From: Rick van Rein <[email-masked]>
Date: Mon, 05 Apr 2021 14:12:58 +0200

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?

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 5 Apr 2021 14:18:35 +0200

> On 2. Apr 2021, at 23:46, Rick van Rein <[email-masked]> wrote:
> 
> Hello,
> 
Doesn't that results in head of line blocking?
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 5 Apr 2021 14:23:52 +0200

> On 5. Apr 2021, at 14:12, Rick van Rein <[email-masked]> wrote:
> 
> Hi,
> 
Why do to use TLS over SCTP? It has substantial limitations. That is
why DTLS over SCTP was specified.
> 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?
> 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

---

From: Rick van Rein <[email-masked]>
Date: Mon, 05 Apr 2021 18:40:56 +0200

Hello Michael,

Thank you!  I was searching for options, things that should go into
DTLS, but I was unaware of the attempts of mapping it better to SCTP.

> What about using: https://tools.ietf.org/html/draft-westerlund-tsvwg-dtls-over-sctp-bis-01

This looks very good, thank you for the pointer!

-Rick

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 06 Apr 2021 09:37:10 +1000

You could also do SCTP over DTLS, which is what WebRTC uses.