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

[Michael Tuexen <[e-mail]>]

> On 17. Jul 2023, at 11:18, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi Michael,
>  See inline. I will note at the end of this message we are coming to the very important question. Which direction do we take to resolve the shortcomings of RFC 6083 and which fulfills 3GPP’s requirements?
>  > 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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-f76f495b164e620a&q=1&e=e967b56f-19dd-42d8-9ed7-8e96c492619e&u=https%3A%2F%2Ffreebsdfoundation.org%2Fwp-content%2Fuploads%2F2020%2F07%2FTLS-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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-2274dec5a3301e89&q=1&e=e967b56f-19dd-42d8-9ed7-8e96c492619e&u=https%3A%2F%2Fgithub.com%2FTCP-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.
> 
> MW: Yes there are differences, but nothing major on the architectural level to me. You have an encryption/decryption function that uses a security context 
I'm not sure. Lets focus on the receive direction.
One difference is that you can process the transport information before trying to decrypt. If there is any problem, you just
pass the received data up and the upper layer will do what is necessary.
In the SCTP case, you can't pass things up. You can do the decrypt on top of SCTP, but you can't go down
again to continue SCTP processing. Can this happen?

The handling of keys via the API is crucial. That is why I'm asking about the socket API extension.
For example, in KTLS for FreeBSD you can't do key updates.
> in the kernel that is utilized by the crypto context implementation. The security context needs as you below identify an API to set, when the user land key-management function has run.
> My understanding of KTLS is that you do exactly the same. If I quote https://docs.kernel.org/networking/tls.html#kernel-tls
> Setting the TLS ULP allows us to set/get TLS socket options. Currently only the symmetric encryption is handled in the kernel. After the TLS handshake is complete, we have all the parameters required to move the data-path to the kernel. There is a separate socket option for moving the transmit and the receive into the kernel.
> What might be different in CRYPTO chunk usages with DTLS is that you will run new key-management runs, and then set new security contexts and then switch to them. But some of similar functionality do exist also in KTLS to handle TLS alert messages.
Isn't that at the end of a communication?
>  * 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.
> MW: Yes, but the API is implementation specific. So, if we define an Socket API specification for the crypto that is specific to kernel implementation and 
I don't think so. We have put in the past for the base protocol and the extensions a socket API section.
It is informational. And you don't have to implement it. But it shows how to use the upper layer interface.
In addition to that, the SCTP base protocol (and the TCP one also) contain an abstract API.
Having specified a socket API for the SCTP functionality specified so far is a good feature of
SCTP, I think. However, this is not a formal requirement and the WG might not require it. This
is up to the WG.
> those implementation that thinks Socket API is worth continuing with. From my perspective I think the socket API if wanted is better to be defined by those who implement this specification in such a context where it makes sense to have. From my perspective this is one place where it is more likely we introduce something with errors than make it correctly. Especially as we authors have no implementation experience in this environment. Thus, I think not specifying for example a socket API in our drafts is the right choice for now. If you implement this and have a proposal for an API that you think should be included, then we can consider to add it. What we can consider to do is to write an API consideration section for DTLS, detailing what we see as the identification keys for a security context, and what information is needed in that context. Just to give a start what would be relevant in relation to
I would love to implement this, since I think it makes a lot of sense to have things implemented before they become
an RFC. We did so in the past. But again, this is not a formal requirement for PS and the WG might be happy to proceed.
In this particular case it is problematic due to IPR questions.
> DTLS:
> The security context look up keys are:
>     • SCTP-Association
>     • DCI 
> A security context would contain
> Algorithmic identifier: This would need to be equivalent to the TLS Cipher suit for what is used for the record protection:https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 which also identifies the record format inside the Crypto chunk. So an identifier can be DTLS_AES_128_GCM_SHA256
> Key material for above algorithm: A binary blob of varying size that is algorithmic specific
> Initialization vector (IV): Another binary blob
> Salt: Another binary blob
> Sequence number / replay window: With DTLS each DTLS Connection will have its own replay window state that needs to be part of the crypto context. Initially that only needs the latest received (or start) sequence number when being initialized. So there are some changes on this compared to KTLS due to this being DTLS and the fact that the identification is SCTP association plus DCI value. So a modified API like what is given in https://docs.kernel.org/networking/tls.html#kernel-tls should work.    
> > 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.
> 
> MW: As said above, I don’t think this is a necessary feature. If the implementation experience is in place to include it, yes we can. But, I rather leave it out now, and defines it later than make a mistake prior to actual implementation.  * 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.
> Yes, so there need to be specific code in the kernel for the combination of ciphering algorithms and the protection record format. And which and what can be implemented in an open source kernel is outside of my knowledge as this comes to IPR. 
> * 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?
> MW:  So the main reasons we proposed this solution instead of DTLS over SCTP are the following:
>     • The fact that the rekeying process is robust and mistakes can’t cause association failures, and don’t require trying to figure out state from the SCTP stack to determine when one can drop the previous used keys to not have the association failures.
>     • The fact that we don’t require a DTLS stack that support large record sizes (i.e. 2^14 bytes)
>     • We are not relying on two different security mechanisms where an issue in either can compromise the security. Instead relying only on DTLS that at least have more usage than SCTP-AUTH.  The integration into SCTP needs to occur so that threat surface will be there. 
I was suggesting to use SCTP over DTLS. As used by WebRTC. Only multihoming support needs to be added.
This would allow you to use more than one DTLS connection below it and bring them up and down as you want
to achieve the security goals DTLS is not providing anymore.
> 
> > 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.
> 
> MW: So first of all I don’t think this is restricting it to only user land stacks. We have strong indication that implementing this in the kernel with only the record protection part being implemented in the kerel is possible at least for DTLS. If there exists IPR on the part of the code that needs to go into kernel I understand that is a barrier to some open-source implementations. If that is the case I don’t know, the WG participants will have to do their own evaluations of the situation.   
I can at least say for FreeBSD, this is problematic.
> I am highly interested in feedback on this proposal from the ones that actually will have to implement it. The choice we make in this WG, will with very high probability be directly adopted by 3GPP to fix the known shortcomings of RFC 6083 that currently is a MUST support for any SCTP based 3GPP interface for several releases. Thus, I know what we do here will impact Nokia, Huawei and others that have products in this space. So far I have not seen any indication that there are other users out there of RFC 6083 beyond 3GPP. If there are I would be very happy to here input on this.
I agree completely!
> I would note that we have defined Crypto chunk and its DTLS usage as a modular approach. Frankly I don’t expect anyone to define an additional protection engine for this chunk. However, we didn’t want to define a protection chunk that was locked to a single protection engine, we rather made it modular so if someone would have future needs, would not swear at our shortsightness.  
I understand this. Implementation wise I think implementing them in combination is much simpler...
> So I do hope that we will have a fruitful discussion in San Francisco and that we get more input preferably before that so that we can have a consensus on the direction shortly after IETF. Cheers
Looking forward to seeing you in SFO.

Best regards
Michael
> Magnus