Re: [tsvwg] DTLS in SCTP solution

[Michael Tuexen <[e-mail]>]

> On 28. Mar 2023, at 09:43, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Hi Michael,
>  Thanks for the comment and discussion. This has enabled me to focus the slide on clarifying things not clear enough and bring up what needs more thought and discussion. See inline for more comments and motivations.  > On 23. Mar 2023, at 10:16, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> > 
> > Hi Michael,
> >  Many thanks for the review. Comments inline.
> >  
> > 1. Why is not not allowed to bundle chunks with the CRYPTO chunk? I can understand that
> >    in ESTABLISHED, but not in the other states.
> > 
> > MW: So this is to keep things simpler, avoid any synchronization needs and not force a MTU handling of the bundling onto the crypto chunk handler. It is clearly possible to allow it, but it would mean that you have two independent process that creates chunks and bundling them. As
> I don't see the complexity of MTU handling. When putting together a packet, you iterate
> through the chunk queues and add the next chunk if it fits. For that check you would
> need to check if it needs to be protected by an CRYPTO chunk and whether you have already
> added a CRYPTO chunk or not. If a CRYPTO needs to be added, you just have to take that
> into account. A similar mechanism is already implemented for AUTH chunks.
>  MW: Sure, the main point from my perspective is that there are so few packets where bundling would be possible that there is little point to add any code for it to accomplish. There, are as you say nothing that would prevent bundling from happening. We where explicitly forbidding just to not have to deal with it.  
I see. An SCTP implementation is not required to support bundling on the sending side. Only the
handling on the receiver side is required. So as an implementer, you are always free to not
implement this, if you think this is simpler and acceptable. You do not need to disallow this
explicitly.
>  
> 
> > you ask below in 3) there are two independent congestion controls creating data here and when either crypto chunks for the handshake like DTLS
> I missed any statement about running multiple congestion controllers and its interaction
> with the congestion controllers existing in SCTP.
> 
> And this is sort of highly unexpected: SCTP runs a congestion controller for each
> remote address controlling the amount of DATA/I-DATA being sent. The defined
> congestion controllers can go down to one PMDCS/RTT, but not smaller. It was
> acceptable to live with this limitation. Some additional control chunks (like
> ASCONF or RE-CONFIG chunks) are controller by allowing only 1 per RTT. This
> increases the overall minimum rate SCTP can go downto, but it was acceptable.
> But they all share the same retransmission timer handling.
> MW: To be very clear we are stating that any need for any congestion control is just in case you one really need one. In the case of DTLS it has recommendation for limiting flight sizes to below 10 packets. So it is not congested controlled but rate limited, see 5.8.3 of rfc 9147.
> I don’t expect that most protection engines would actually need anything more than basic rate limitation. I think most handshakes etc. will fall under the same considerations that makes SCTP control traffic to be okay without congestion control or maybe even more appropriate the same as any transport protocols initial handshake. My expectation here are a relative small number of packet in very few flights and this just happening every few hours. 
> Therefore, I was not expecting additional congestion controls for control chunks.
I see. So, in particular, you don't want to couple the congestion controllers...
> Please note that the AUTH chunk is not congestion controlled at all.
> > handshake, and the ones carrying SCTP control chunks are independent and neither expect any additional delays. Thus, this non-bundling minimizes the code, allows minimal extra latency in the encapsulation into SCTP packets.  
> >  Any specific chunks you expect to benefit from bundling? I would note that the expected protection engine traffic is basically a 3-way or 5-way handshake with each flight being at most a couple of kbytes initially, and then a 3-way for rekeying, like every 2 hours or so. So there is not a lot of efficiency loss here for long lived associations.
> 
> I'm not having any particular use case in mind. I just want to put in constraints I right
> not don't understand and which might be restrictive in the future.
> 
> MW: Noted, and as I said above we forbid it to make life easy. If you think that would potentially have negative impact we can change this. The actual receiving of bundled crypto chunks I would basically already exist in the implementation anyway, so that only if one need to bundle in the future one could implement it. So maybe allowing it has minor impact, but I would not mandate supporting it.  
See my above comments.
> Let us think a bit more about if there are additional issues with this. I have added an issue. https://github.com/gloinul/draft-westerlund-tsvwg-sctp-crypto-chunk/issues/6
> >  2. Why are you sending ABORT chunks followed by ERROR chunks? This does not make any
> >    sense to me. The receiver will process the ABORT chunk, kill the association, report
> >    that to the upper layer and then can't really process the ERROR chunk anymore.
> >  MW: This is clearly a mistake in the text in regards to ordering, it should of course be the reverse. Thanks for noticing it we will correct this.
> Sorry, I wasn't clear enough. For me, neither ABORT and ERROR or ERROR after ABORT makes sense.
> Whenever I see this on the wire, I get the impression that there is a bug.
> Both the ERROR and the ABORT chunk are containers for error causes. The difference
> between then is the action on the receiver side. For most error causes, the
> only action is to report the error causes to the user. But the association is
> not affected. In case of an ABORT chunk, the association is terminated and the
> error causes are reported to the user.
> MW: Yes, I realize the error I made here. Yes, this should be an ABORT with the right error causes included.
OK, great. Thanks for the clarification.
> 
> > 
> > 3. I do understand how you use the CRYPTO chunk to protect an SCTP packet. It is
> >    similar to the AUTH chunk, just doing encryption. However, I do not understand how
> >    to use the CRYPTO chunk for DTLS messages. If I understand your proposal correctly,
> >    you will use DTLS retransmissions in case of packet loss, since you don't run
> >    a timer and loss recovery for CRYPTO chunks. But how is the path been chosen?
> >    How can you make use of multi-homing? DTLS does not know about this.
> >  MW: So on a general level crypto chunks using a particular protection engine can generate packets from two sources. One is the packets coming from the SCTP stack. The second one is what is necessary for any in-band initialization and other management in the protection engine. We allow the protection engine to send what it needs to do as crypto chunks, and it is up to the protection engine to be able to separate its in-band messages between the two protection engine instances in the two peers from protected SCTP packet payloads. Thus, in the case in DTLS the DTLS handshake, any error messages and termination i.e. DTLS Alerts are sent as such generated messages.
> 
> I guess this applies also the key update messages. The above description reads more like an
> implementation of SCTP over DTLS with an SCTP packet format on the wire.
> MW: I can see why you might think so. However, the integration do result in that neither crypto engine nor protection engine need to take care of path handling or MTU for the vast majority of the traffic. And if the discussion concludes that having the handshake etc being generated by the protection engine and not go through the SCTP main machinery then we can address that with your idea to send. I have included this aspect into the slides for Thursday. 
> >  When it comes to the path I do realize that we failed to describe this. Our intention was to have these messages use the path that SCTP stack currently has as an active path. So what SCTP thinks is a viable path will be used. We didn’t think this would normally result in any significant issue, only some additional delay as SCTP detects the failure. However, I do realize depending on configuration maybe some triggering of an SCTP level check of the path so they are updated might be needed.  
I see. You let SCTP supervise the paths at a high rate (possibly tweaking HB.interval) and use on the working
paths of SCTP for the crypto engine.
> 
> This is not what I would expect. The design of SCTP and its extensions all allow for using multihoming and
> its failover as soon as it is possible. In particular, if the initiator provides multiple addresses of 
> the peer, already the sending of the INIT would perform failover.
> MW: Yes, as said above this might be one aspect which we haven’t thought through sufficiently. I would note that for example in the mobile network we have been using a heart beat period of every two second. Thus, a path failure would be addressed within the time frame before we would timeout the handshake. But, I think this aspect is one that we should continue to discuss make the best choice.
Understood.
> 
> >  
> > 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.
> > 
> > MW: Yes this clearly needs an API between the SCTP stack (Kernel or user land) and the protection engine. As OS are different and different requirements applies to this, I think this is something that do need to be implementation specific. We could add an abstract API focusing on what needs to exist but with no details on how to actually implement it.  
> 
> Not sure if I follow here. Up to now, we have described what functionality we expect inside an
> SCTP implementation and how it can be used by an upper layer when a socket based API is used.
> This does not force any implementation do implement a socket API, since the section is always
> informational, but it allows definitely for portable application programs.
> 
> In principle when considering a transport protocol, I think it is important to describe how
> it interacts with its lower layer, its upper layer and how it handles timers. So an API
> description is kind of important in my view.
> 
> It is still unclear to me which part of the protection engine you consider as part of the
> SCTP stack and which part is considered part of the upper layer.
> 
> 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://whisperlab.org/introduction-to-hacking/notes/openssl
> 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.

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.
> 
> > I really like the idea of an CRYPTO chunk. However, I would think of it more in the
> > lines of the AUTH chunk. You let the SCTP stack to the encrypt/decrypt stuff and
> > specify a socket API for delegating the credentials. This could be similar to kernel
> > TLS. However, I would also prefer to run the DTLS handshake messages as normal user
> > messages in DATA/I-DATA chunks and not change the SCTP state engine.
> > This way you can make use of the SCTP loss recovery and retransmission strategies
> > including multihoming.
> >  MW: I am happy to discuss this choice for the handshake and control messages. So a couple of reasons for not doing this is that then you have the ULP and the protection engine control messages interact with each other in the user message interface of the SCTP stack. For example a reliable message on stream 0 for DTLS handshake message for a “rekeying” can interfere with the transmission of a ULP message on stream 0. We also thought the state management with protection pending protected -> established ensures that the ULP can’t send. With your proposal you will have to allow some PPID or what ever you use to identify the protection engine traffic through the upper interface of the SCTP stack but not the ULP. But, maybe this can be done in a dedicated upper API anyway.  
> 
> Yes, I think this stuff is doable. Think about this like DTLS/SCTP. You use DTLS in the upper layer to do
> the key management for SCTP-AUTH. The computation of the AUTH crypto is done by the SCTP stack. Doing a
> similar thing for a CRYPTO chunk fits more in the principles for SCTP, I think.
> MW: For clarity you mean that the equivalent of the DTLS record processing be in the CRYPTO chunk and defined by the CRYPTO chunk. As I said above we want to avoid having the crypto chunk contain crypto parts as it makes it harder to maintain and verify its security properties. But, as indicated having a split implementation where the DTLS record processing is done in the kernel and the handshake is done in user land would make this very similar in reality but are clearly different from a specification perspective.
> 
> >  
> > 
> > If I'm reading section 1.3.1 of you DTLS document, I'm wondering why you do not consider
> > SCTP over DTLS. You can use that with an unmodified DTLS stack, you need to tweak the
> > SCTP stack a bit. The only thing which is missing right now is the support of multihoming.
> > But this can be worked on...
> >  MW: So solving the multihoming aspect of IP/UDP/DTLS/SCTP is one challenge here. The other is that that would impact the O&M systems where we need to deploy this security solution. Making deploying it much harder.  Cheers  Magnus
> Yes, I know. I'm not saying that the solution is already there. But one could use ASCONF to
> "add" new DTLS connections to an existing SCTP association to get multihoming and use
> "delete"/"add" to replace older DTLS connections by new ones, if they get to the limits of
> they key usages.
> 
> I do not have any experience with Q&M and can't therefore comment on that.
> 
> I'm still in the phase of understanding you proposal from an architectural point.
> When looking at https://www.ietf.org/archive/id/draft-westerlund-tsvwg-sctp-crypto-chunk-00.html#sctp-Crypto-chunk-layering
> 
>            +---------------------+
>            |                     |
>            |        ULP          |
>            |                     |
>            +---------------------+ <-- User Level Messages
>            |                     |
>            | SCTP Chunks Handler | +-- SCTP Unprotected Payload
>            |                     |/
>            +---------------------+    +--------------------+
>            |        CRYPTO       +--->| Protection Engine  |
>            |        Chunk        |    +--------------------+
>            |       Handler       |<---+   Key Management   |
>            +---------------------+    +--------------------+
>            |                     |\
>            | SCTP Header Handler | +-- SCTP Protected Payload
>            |                     |
>            +---------------------+
> 
> 
> I would say that you assume that below 'SCTP Header Handler' there is IP, and the interface between
> ULP and 'SCTP Chunks Handler' the API to the user, for example, the socket API.
> In a kernel implementation, everything below ULP is in the kernel. Wouldn't that imply that
> * the protection engine runs in the kernel
> So we have the protection engine on the side our thought would be that it also enables having the kernel
> 
> * if the protection engine needs any information from the ULP, there must be some API extensions
> 
> In the case of DTLS, I would see some interactions with the ULP, for example related to certificate
> handling. But I also think that running DTLS in the kernel is a bad idea.
> > MW: Yes, there will be need for an API towards the ULP/application for the protection engine to configure certificates and either to dynamically accept peer identities or have them being configured. About the DTLS below SCTP, isn’t that equally problematic with having DTLS in the kernel as to have to make per packet call to a user space protection engine?
Just to be clear: I do see running SCTP over DTLS as a userland only solution. We did this for WebRTC, since
the browser is running in userland anyway.

Best regards
Michael
> Cheers
> Magnus