Arbitrary DTLS record, arbitrary stream

[martinthomson]

https://gloinul.github.io/draft-westerlund-tsvwg-dtls-over-sctp-bis/draft-ietf-tsvwg-dtls-over-sctp-bis.html#section-4.4-2 says:

DTLS records of other types MAY be sent on any stream.

...except that not always:

However, DTLS messages of other types than protected user message MUST be sent reliable, so the DTLS record can only be interleaved in case the ULP user message is sent as reliable.

("protected user message" is not a thing in DTLS)

Why allow this? This creates a real challenge for managing DTLS connection state if messages that affect it might appear anywhere.

You could instead mandate this:

A simple solution avoiding any protocol issue are to send all DTLS messages that are not protected user message fragments is to pick a stream not used by the ULP, send the DTLS messages in their own user messages with in order delivery. That mimics the RFC 6083 behavior without impacting the ULP. However, it assumes that there are available streams to be used based on the SCTP association handshake allowed streams (Section 5.1.1 of [RFC9260]).

I don't understand the caveat here, but I don't think that it is unreasonable to reserve one stream for handshakes. The ULP can just allocate one extra stream. It would be even better if there was a parallel construct (like QUIC's CRYPTO frames) that didn't result in impinging on ULP stream limits, but I can see how that might be considered "too hard".

[gloinul]

So the issue is that when you retrofitting DTLS security on to SCTP with an ULP that also is well established we want to to avoid changing either in any significant way, only slot in our adaptation layer. Therefore we can't be expect to dictate that we can dictate that stream 0 for example is always used for DTLS messages.

So we can't really mandate the good recommendation as that caveat can be real. SCTP negotiates a maximum number of streams. In worst case someone sits on a very purpose built SCTP stack that will negotiate two streams and really only support that because the ULP only needs two streams. So I think mandating using an additional stream may cause issues.

It might also be that this looks unnecessary complex. If one disregards any head of line blocking issues and simply ensures to send the DTLS messages not carrying ULP data in individual in-order delivered individual SCTP messages they will be processed in the right order. The DTLS/SCTP implementation simply will get SCTP user message with a DTLS message and process it with DTLS and that will either result in data or some other DTLS stack API result. But it will not really know this when using DTLS 1.3 prior to submitting the data.

It was this anyway black box behaviour so from a receiver perspective it doesn't matter on which stream a DTLS Handshake arrive or a DTLS Close_alert. For these control messages all streams are the same stream. It is only for protected user data that the stream and particular user message matters as that maintain the API between DTLS/SCTP and SCTP for the ULP.

So any specific reason you think that allowing it to be on any stream creates more headache than having them on a singular stream @martinthomson?

[gloinul]

@martinthomson we plan to close this by draft deadline if no additional feedback is provided.

[martinthomson]

Specific reasons that I can think of:

1. Stream level flow control with just data + DTLS overheads tends to be fairly predictable in terms of the cost you pay for DTLS protection. However, if large DTLS messages are send on a stream, like handshakes with certificates, the accounting for that overhead becomes entirely unpredictable.

2. Processing of DTLS handshake state requires centralized processing, but the processing of the record layer does not. For an endpoint that distributes processing load for streams, this adds a new sort of overhead. Rather than engaging with just decryption logic, it has to either engage the centralized DTLS infrastructure for every record (which affects performance) or include logic to manage record protection and then route non-application_data records for further processing. The first has high contention, the latter requires that you break your DTLS implementation down in new ways.

There is an alternative that doesn't consume streams: describe a new message/chunk type to carry DTLS handshake (or non-application_data) records. The DTLS handshake already supports the fragmentation necessary to avoid the reassembly, retransmission, and other features that streams might provide.

[gloinul]

Thanks for elaboration. I think we could go the PPID route here also for separation. But, independently what you are asking for is in facto to make the DTLS control messages explicitly visible where they currently will not be when using DTLS 1.3. This would have not been an issue if DTLS 1.3 hadn't dropped the type field as plain text field, so we are talking about reversing that choice by the TLS WG in this application.