Re: [tsvwg] DTLS in SCTP solution

[Michael Tuexen <[e-mail]>]

> 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.
> 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.
Therefore, I was not expecting additional congestion controls for control chunks.
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.
>  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.
> 
> 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.
>  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.  https://github.com/gloinul/draft-westerlund-tsvwg-sctp-crypto-chunk/issues/5
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.
>  
> 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.
>  
> 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.
>  
> 
> 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
* 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. 

Best regards
Michael