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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
