Re: [tsvwg] New Version Notification for draft-westerlund-tsvwg-sctp-crypto-chunk-01.txt

[Michael Tuexen <[e-mail]>]

> On 14. Jul 2023, at 15:16, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Hi Michael,
>  Yes, this is an important question to answer.
>  The intention from us author are to enable this SCTP extension to be possible to implement in both kernel and user land SCTP stacks.
Hi Magnus,

thanks for the clarification.
>  The user land SCTP stack implementation should be straight forward as the Crypto chunk processing on sending and receiving an SCTP packet should be able to easily do a call to an external crypto library implementing the chose protection algorithms, such as DTLS 1.3 for example.
I agree, I do see how this can be implemented in a userland stack.
> When it comes to kernel implementation this will be more challenging but not something that hasn’t been done before. With the changes we have implemented after your questions and suggestions at the last IETF meeting, i.e. sending the key-management messages, like the DTLS handshake over a DATA Chunk.  This is tried approach of splitting the key-management parts from the record protection operation in TLS to minimize the amount of code needed to be implemented in the kernel to just the crypto protection operations and not the handshake. Example of this type of implementation of kernel TLS exists in both Linux https://docs.kernel.org/networking/tls-offload.html, and Freebsd https://man.freebsd.org/cgi/man.cgi?query=ktls&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html for the Freebsd I found this overview of KTLS and the different implementation approaches quite interesting: https://freebsdfoundation.org/wp-content/uploads/2020/07/TLS-Offload-in-the-Kernel.pdf. I would think TCP-AO is another similar example of how the core per packet operations are implemented in the kernel and the key-management done outside. https://github.com/TCP-AO which appear to make good progress in Linux and maybe less so in FreeBSD. Even the SCTP-AUTH implementation is of this type. I would think the main difference here is that the crypto chunk has one more level of indirection compares to SCTP-AUTH. SCTP-AUTH in a kernel SCTP implementation needs the supported crytpo algorithm and the SCTP-AUTH Framing. For DTLS in Crypto chunk, the SCTP stack needs Crypto chunk with DTLS framing of the supported algorithm. The algorithm implemented in kernel can potential be re-used if there would be another protection engine using the same crypto algorithm.
I think there are some differences:
* If you consider KTLS, you run TLS/TCP/IP. Normally you have the userland/kernel boundary
  between TLS and TCP (actually the socket layer). What KTLS does, is it moves the lower part
  of the TLS processing (encrypt/decrypt) down. With your proposal, part of DTLS run below SCTP,
  some runs above. This seems to me more complex.
* If you consider SCTP AUTH, it runs the crypto stuff in the kernel and provides a way of
  key management to the upper layer. It defines an API and it is crucial that the upper layer
  uses this in an appropriate way. I'm missing such an API in your proposal. In my view that
  is needed to understand if and how it can be implemented in kernel land.
> I would also note that there can exist other potential realization to deal with the challenge, like having a user land worker thread performing protection operations be given buffer to process and when that is done continue the processing in the kernel. These are implementation choices after all. Have we done the best possible to enable implementation, and the changes we done is a step forward to simplify implementation. Clearly the improved security of crypto chunk protecting the whole SCTP packet and avoidance in having to do both DTLS encryption and integrity plus SCTP-AUTH integrity requires a different implementation effort. But it also resolves a lot of very clunky issues around synchronization also when rekeying and should have lower amount of per packet processing in the end.
The reason I was asking the above question:
* I think we agree on that the solution must be implementable in userland.
* If the solution must be implementable in kernel land, it should provide a socket API
  extension to demonstrate how to do that.
* I see the generic implementability in kernel land much harder than considering how
  to implement the specific one with DTLS. However, this can't be implemented in
  the open source kernel implementations. So we are left with commercial OSes.
* If the solution is restricted to userland stacks, why not just use SCTP/DTLS.
  The only missing piece is support for multihoming. But defining ADDID/DELIP support
  for SCTP/DTLS should be quite simple. Then you can do everything you want. Or am
  I missing something?
> When it comes to SCTP open source stacks being used by vendors I those vendors will have to answer if this is a concern or not. Ericsson is using its own userland implementation.
Thanks for the clarification. So restricting it to userland stack is not an problem for your side.

Best regards
Michael
> Cheers
> Magnus
>   From: Michael Tuexen <[e-mail]>
> Date: Friday, 14 July 2023 at 12:05
> To: Magnus Westerlund <[e-mail]>
> Cc: tsvwg IETF list <[e-mail]>
> Subject: Re: [tsvwg] New Version Notification for draft-westerlund-tsvwg-sctp-crypto-chunk-01.txt
> > On 28. Jun 2023, at 14:41, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> > 
> > Hi TSVWG,
> >  We have now produced an updated version of the two drafts descripting crypto chunk and how DTLS is used to secure it. The main change in this version was to send any key-management as SCTP user messages as suggested by Michael Tüxen. This has several good benefits as the reliability, path handling etc utilizes SCTP.
> >  Please review and consider if you agree with us that this solution is better than the one in https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/we would like to come to a decision in the near time so we can progress this to fulfill 3GPP’s need for a solution.  Cheers
> Hi Magnus,
> 
> some time ago I raised a couple of questions. Since John replied that
> we can't get an answer from 3GPP, would it be possible to get an
> answer from the authors of the document what they think or what their
> design goals are in relation the questions?
> 
> 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 SCTP stacks are
> being used. Is it expected that this is also possible in the future?
> 
> I'll review the crypto document in the upcoming week and will provide comments.
> 
> Best regards
> Michael
> >  Magnus
> >  
> > A new version of I-D, draft-westerlund-tsvwg-sctp-crypto-chunk-01.txt
> > has been successfully submitted by Magnus Westerlund and posted to the
> > IETF repository.
> > 
> > Name:           draft-westerlund-tsvwg-sctp-crypto-chunk
> > Revision:       01
> > Title:          Stream Control Transmission Protocol (SCTP) CRYPTO Chunk
> > Document date:  2023-06-28
> > Group:          Individual Submission
> > Pages:          31
> > URL:            https://www.ietf.org/archive/id/draft-westerlund-tsvwg-sctp-crypto-chunk-01.txt
> > Status:         https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-crypto-chunk/
> > Html:           https://www.ietf.org/archive/id/draft-westerlund-tsvwg-sctp-crypto-chunk-01.html
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-westerlund-tsvwg-sctp-crypto-chunk
> > Diff:           https://author-tools.ietf.org/iddiff?url2=draft-westerlund-tsvwg-sctp-crypto-chunk-01
> > 
> > Abstract:
> >    This document describes a method for adding cryptographic protection
> >    to the Stream Control Transmission Protocol (SCTP).  The SCTP CRYPTO
> >    chunk defined in this document is intended to enable communications
> >    privacy for applications that use SCTP as their transport protocol
> >    and allows applications to communicate in a way that is designed to
> >    prevent eavesdropping and detect tampering or message forgery.
> > 
> >    The CRYPTO chunk defined here in is one half of a complete solution.
> >    Where a companion specification is required to define how the content
> >    of the CRYPTO chunk is protected, authenticated, and protected
> >    against replay, as well as how key management is accomplished.
> > 
> >    Applications using SCTP CRYPTO chunk can use all transport features
> >    provided by SCTP and its extensions but with some limitations.
> > 
> > 
> > Name:           draft-westerlund-tsvwg-sctp-crypto-dtls
> > Revision:       01
> > Title:          Datagram Transport Layer Security (DTLS) in the Stream Control Transmission Protocol (SCTP) CRYPTO Chunk
> > Document date:  2023-06-28
> > Group:          Individual Submission
> > Pages:          27
> > URL:            https://www.ietf.org/archive/id/draft-westerlund-tsvwg-sctp-crypto-dtls-01.txt
> > Status:         https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-crypto-dtls/
> > Html:           https://www.ietf.org/archive/id/draft-westerlund-tsvwg-sctp-crypto-dtls-01.html
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-westerlund-tsvwg-sctp-crypto-dtls
> > Diff:           https://author-tools.ietf.org/iddiff?url2=draft-westerlund-tsvwg-sctp-crypto-dtls-01
> > 
> > Abstract:
> >    This document defines a usage of Datagram Transport Layer Security
> >    (DTLS) 1.2 or 1.3 to protect the content of Stream Control
> >    Transmission Protocol (SCTP) packets using the framework provided by
> >    the SCTP CRYPTO chunk which we name DTLS in SCTP.  DTLS in SCTP
> >    provides encryption, source authentication, integrity and replay
> >    protection for the SCTP association with mutual authentication of the
> >    peers.  The specification is also targeting very long-lived sessions
> >    of weeks and months and supports mutual re-authentication and
> >    rekeying with ephemeral key exchange.  This is intended as an
> >    alternative to using DTLS/SCTP (RFC 6083) and SCTP-AUTH (RFC 4895).