Re: [tsvwg] DTLS in SCTP solution

[Magnus Westerlund <[e-mail]>]

Hi Michael and WG,

Pruning the message to where there are questions. The summary are:


  1.  Bundling of crypto chunk will be reconsidered and may be impacted by 3)
  2.  The text on sending errors and aborts will be fixed
  3.  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.


> > 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.

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.

Cheers
Magnus Westerlund