Practical user message limitations due to renegotiation and key-update about draft-westerlund-tsvwg-dtls-over-sctp-bis

[gloinul]

We discussed some alternative for this issue as potential direction we can continue. So this issue is only impacting very large user messages. For example an attempt to use a single user message as a continuous byte stream that is long lived will have issues.

1. Accept the limitations and that user messages of sizes that are close to take the magnitude of the rekeying interval in transferring or the AEDA key byte limit in size will not work well with this. Continue to track the DTLS rekeying events based on SCTP-AUTH keys on the user level.

2. That one require another API than the currently defined one. Then one can both use multiple different SCTP-Auth keys for a single user message. However, one would need to track which key(s) are using in which packets for a user messages so that one can determine when all packets with an older key have been delivered to the receiver so that one can rekey.

3. Change the mapping between ULP user messages and its DTLS records to underlying SCTP user messages. If one track the fragmentation over SCTP user messages and when an ULP user messages is at its end then one can continue to use SCTP API as currently defined and enable rekeying in the middle of ULP user messages.

Based on the known applications and API limitations in existing implementations, we think that alternative 1 is the one to recommend. However, if you have an SCTP using application that would have issues with the limitations: User messages can't be as long as the AEAD single key value limiations. The transfer of these uses messages must complete within a key-update period.

We will discuss this design choice with the WG.

[gloinul]

With #70 the limitation is SCTP-AUTH API only. So for an API that does not allow one to change the SCTP-AUTH key for a message the maximum length is what can be transferred in the period between each periodic rekeying.

[gloinul]

So if one uses RFC 6458 defined API for setting the SCTP-AUTH key. Then one can only set it on the start of the user message. That means that the rekeying using multiple DTLS connections will be affected. The impact to enable this to function are:

• Allow that one continue to use old SCTP-Auth key ID after having created a new one for user messages that started with the old key.
• The shutdown of the old DTLS connection will be delayed until all user messages using the corresponding SCTP-auth key have been sent. Then apply the normal hold period to avoid issues.
• The above leads to recommendations that user message sizes should be kept short enough to avoid blocking rekeying, i.e. user messages must be completed within a small fraction of the expected rekeying interval.

[gloinul]

PR #93 notes the API limitation and notes the fact that message sizes needs to be such that transfer complete in short time frame after rekeying to not block future rekeying.