Re: [TLS] DTLS/SCTP and fragmentation
You could also do SCTP over DTLS, which is what WebRTC uses. On Tue, Apr 6, 2021, at 02:40, Rick van Rein wrote: > 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 > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS/SCTP and fragmentation
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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS/SCTP and fragmentation
> On 5. Apr 2021, at 14:12, Rick van Rein 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS/SCTP and fragmentation
> On 2. Apr 2021, at 23:46, Rick van Rein wrote: > > 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. Doesn't that results in head of line blocking? > > 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. 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS/SCTP and fragmentation
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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] DTLS/SCTP and fragmentation
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
