Re: [tsvwg] DTLS in SCTP solution

[Magnus Westerlund <[e-mail]>]

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 you ask below in 3) there are two independent congestion controls creating data here and when either crypto chunks for the handshake like DTLS 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.

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.

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.

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


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.


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.



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