Re: [tsvwg] DTLS in SCTP solution

[Michael Tuexen <[e-mail]>]

> On 30. Mar 2023, at 03:37, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Hi Michael and WG,
>  Pruning the message to where there are questions. The summary are:
>  
>     • Bundling of crypto chunk will be reconsidered and may be impacted by 3)
>     • The text on sending errors and aborts will be fixed
>     • Currently handshakes messages etc are not path handled by SCTP. By using short HB intervals (<=2 seconds) one can ensure that the currently used path works, but an alternative was proposed by Michael that will be further considered and discussed.
Hi Magnus,

while thinking about your proposed usage of DTLS, two additional points came
up, which I'm not sure about:
1. Handling of restart
   Since you only accept CRYPTO chunks in ESTABLISHED state, I guess you don't support
   the restart procedure. Is that correct?
2. Support of Dynamic Address Reconfiguration (RFC 5061)
   The ASCONF chunk contains an address parameter the receiver uses to lookup the
   association. Since this is needed before doing the decryption, I guess you don't
   support this either.
If the above statements are not wrong, than the limitations should be documented.
>  
> > > 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.
> > > 
> 
> <Snipped>
> > MW: So lets start with an important thought from our perspective. We want to use a security mechanism that is well used and implemented with an active community to avoid the fate of having to few eyes looking at it and finding security flaws. Thus, we would like to use DTLS as it is.
> > From a specification perspective what the current proposal results in are an API between the crypto chunk and the protection engine that will have to be invoked for each sent or received packet after the association has been established. How one implements this can be debated and depends also if one has a kernel or userland SCTP implementation. One thought we have here when it comes to DTLS is that one can do the same optimization as for example Netflix did for TLS over TCP, where one keeps the handshake in user space and moves the per record processing into kernel or even HW acceleration. I don’t see that HW acceleration of SCTP is needed for the use case we have, but a kernel implementation likely want to have the DTLS record processing in the kernel. This would look similar to what this page has in its image under the “OpenSSL Module” heading: https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-d0b951f46effb220&q=1&e=da5f6591-ef92-44df-b52a-35db44877ead&u=https%3A%2F%2Fwhisperlab.org%2Fintroduction-to-hacking%2Fnotes%2Fopenssl
> > From my perspective splitting DTLS into two parts implementation wise does not change the relationship for outer input, it only creates the need for an internal API in the implementation. But I think this shows how one can reduce the impact of this structuring.
> 
> This is what I'm trying to understand. I do see no problem in doing the encryt/decrypt part inside the SCTP stack, I'm just
> wondering what function split is needed and how an API would need to look like.
> 
> Let me ask this explicitly: Do you envision that your proposal can be implemented in a kernel stack using some extensions
> of the socket API? Or are you focussing on userland stacks.
> 
> MW: I do envision that it can be implemented by kernels. However, I am not certain that the Socket API is sufficient. I think another API is likely needed to support either a per packet call out to user land for the crypto transformation, or for a split implementation with the DTLS record processing in the kernel on would need one API part that for SCTP stack to Crypto engine part in kernel, and another part of the API that is for configuring keys. 
I think we are tied to the socket API, although we can extend it. Doing an upcall per packet does not sound
like a good idea. Doing the encrypt/decrypt part in the kernel is not a problem. We just need an API for
controlling that and the necessary information like keys and sequence numbers. Putting down the control
at one point is simple, not sure about handling changes of the keys. At least for DTLS/SCTP this was the
part which required some steps like the draining of messages.
> Your statement above "we would like to use DTLS as it is" kills running DTLS conceptually on top of SCTP, since the services
> just don't match. The only way is to run it below SCTP, since the services of DTLS match the ones of IP. But you need to
> touch DTLS implementations to generate the packets you want. If you want to use existing DTLS implementations, you need to
> use SCTP over DTLS. The only problem is supporting multihoming there, which comes down to running a single SCTP association
> over multiple DTLS connections.
> MW: I think here is where we might differ from perspective. When I say DTLS as is I do mean that DTLS operates on either plain text payloads (datagrams) and produces protected payloads (datagrams). In our proposal the plain text is the set of chunks intended for one SCTP packet. The protection operation will produce a DTLS record that is the payload of the CRYPTO chunk. So yes there are a bit of wrapper code around DTLS stack, a stack built for FOO/DTLS/UDP would just not just work. But the most relevant in that the crypto operations are fully defined by DTLS not by CRYPTO chunk. This to avoid a specification that rots. Instead by keeping up with DTLS security issues and patching these and almost all the attack surface stays with that implementation.  
I understand that argument. This basically sounds like "Running SCTP over DTLS". The only difference is that
the payload of DTLS is the list of chunks, not the SCTP packet.

Best regards
Michael
> 
> Cheers
> Magnus Westerlund