Re: [tsvwg] DTLS in SCTP solution

[Michael Tuexen <[e-mail]>]

> On 16. Feb 2023, at 10:36, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Hi,
>  We authors of DTLS/SCTP https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/ have worked on two drafts that together forms what we consider a much better alternative for how to use DTLS to the current proposed solution that is based on SCTP.
>  The first draft is a general crypto chunk that can be used to protect the rest of the SCTP packet using a negotiated protection engine.https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-crypto-chunk/
>  Then we have written a draft that defines how to use the above crypto chunk to integrate DTLS as the protection engine. Targeting the same goals as in DTLS/SCTP. Like mutual authentication, support for very long lived sessions. But in addition we get a lot of other benefits including a much lower bar on the DTLS implementation that is integrated. https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-crypto-dtls/
>  The benefits as we see it are listed here: https://www.ietf.org/archive/id/draft-westerlund-tsvwg-sctp-crypto-dtls-00.html#name-benefits-compared-to-dtls-s
> The main benefits we see are the following:
>     • No dependency on SCTP-AUTH
>     • Much lower requirements on DTLS implementations when it comes to support of functionality
>     • Protection of the whole SCTP packet, preventing attacks on SCTP as well, not only on the user messages
>     • Much robuster when rekeying
>     • No limitation on user message size from this mechanism as it functions below SCTP’s DATA chunk message fragmentation mechanism.
>  We are working on getting our IPR disclosures submitted on draft-westerlund-tsvwg-sctp-crypto-dtls. We authors are currently not aware of any IPR that would apply on draft-westerlund-tsvwg-sctp-crypto-chunk.
>  We would like to ask the WG to consider this proposal as a replacement for DTLS/SCTP.
Hi Magnus,

I have read the two IDs you are referring to. I have a couple of questions/remarks/comments:

1. Why is not not allowed to bundle chunks with the CRYPTO chunk? I can understand that
   in ESTABLISHED, but not in the other states.
2. Why are you sending ABORT chunks followed by ERROR chunks? This does not make any
   sense to me. The receiver will process the ABORT chunk, kill the association, report
   that to the upper layer and then can't really process the ERROR chunk anymore.
3. I do understand how you use the CRYPTO chunk to protect an SCTP packet. It is
   similar to the AUTH chunk, just doing encryption. However, I do not understand how
   to use the CRYPTO chunk for DTLS messages. If I understand your proposal correctly,
   you will use DTLS retransmissions in case of packet loss, since you don't run
   a timer and loss recovery for CRYPTO chunks. But how is the path been chosen?
   How can you make use of multi-homing? DTLS does not know about this.
4. I can see how you can implement this using a userland SCTP stack and a DTLS stack.
   However, I have a hard time to see how to implement this in a kernel SCTP stack.
   I guess one would do the encrypt/decrypt part in the kernel and the DTLS negotiation
   in userland, but the required socket API is not clear to me.
   In my opinion, whatever solution is been worked on, it should work for userland and
   kernel stacks.

I really like the idea of an CRYPTO chunk. However, I would think of it more in the
lines of the AUTH chunk. You let the SCTP stack to the encrypt/decrypt stuff and
specify a socket API for delegating the credentials. This could be similar to kernel
TLS. However, I would also prefer to run the DTLS handshake messages as normal user
messages in DATA/I-DATA chunks and not change the SCTP state engine.
This way you can make use of the SCTP loss recovery and retransmission strategies
including multihoming.

If I'm reading section 1.3.1 of you DTLS document, I'm wondering why you do not consider
SCTP over DTLS. You can use that with an unmodified DTLS stack, you need to tweak the
SCTP stack a bit. The only thing which is missing right now is the support of multihoming.
But this can be worked on...

Best regards
Michael
>  Cheers
>  Magnus, John and Claudio.