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
Hi Magnus,

I'm still trying to understand which approach might be better.
> The main benefits we see are the following:
>     • No dependency on SCTP-AUTH
While that is true, fixing the issues with AUTH requires some
code changes in the SCTP stack, but
* they are observable via the API. So the DTLS implementation can check
  if the SCTP is uses has them.
* the required code changes to the SCTP stack are smaller then the ones
  for the CRYPTO chunk.
>     • Much lower requirements on DTLS implementations when it comes to support of functionality
Which is the other way around at the SCTP level.
>     • Protection of the whole SCTP packet, preventing attacks on SCTP as well, not only on the user messages
I would like to understand this point. What attacks do you have in mind? What is the threat model you are using?
>     • Much robuster when rekeying
>     • No limitation on user message size from this mechanism as it functions below SCTP’s DATA chunk message fragmentation mechanism.
Isn't the user message handling almost the same for both solutions?

Since we are doing this work for 3GPP. I would like to understand if the intended
SCTP stack
* only needs to be run in kernel land
* only needs to be run in user land
* should run in kernel land or user land, depending on the use case.

I would also be interested if there is any expectation regarding support
of open source stacks. I have only a limited view in the stacks being used,
but, correct me if I'm wrong, right now open source kernel stacks are being
used. Is it expected by 3GPP that this is also possible in the future?

Best regards
Michael
>  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.
>  Cheers
>  Magnus, John and Claudio.