DTLS behavior on received closure alert

[emanjon]

In RFC6083bis (DTLS/SCTP) we are discussing when to terminate DTLS connections.

RFC8446 says:

"close_notify: This alert notifies the recipient that the sender will not send any more messages on this connection. Any data received after a closure alert has been received MUST be ignored."

As far as I can see, the DTLS 1.3 draft does not say anything about closure alerts, which according to my understanding means that the above RFC 8446 text apply to DTLS 1.3 as well. However, this behaviour does not seem to make much sense for DTLS 1.3. As DTLS records can be received out of order, shouldn't the DTLS behavior be:

"Any data sent after a closure alert MUST be ignored."

[tuexen]

I do understand that ignoring data is a valid option for DTLS/UDP, which provides an unreliable server. However, when providing a reliable service like DTLS/SCTP, I don't think this is an option. Shouldn't you fail the connection under that condition?

[gloinul]

@tuexen so we found this while working on clarifying the shutdown procedure. So the whole point is to ensure that data that has been committed to the DTLS/SCTP layer will be delivered in a controlled shutdown. We are targeting to have DTLS/SCTP behave like SCTP in regards to shutdown when the upper layer protocol request shutdown. For the improved procedure in DTLS/SCTP see https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis/issues/87 and PR https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis/pull/94

The point of needing this is so that when a peer has requested shutdown, and the DTLS/SCTP has learnt of that by receiving an DTLS close_notify, all data that was sent prior to that must be possible to process and not prevented by this TLS formulation. The DTLS connection state removal can in this case be triggered by the SCTP association shutdown completion or an SCTP abort. We want to be able to use the SCTP shutdown pending mechanism to catch any reordered data requested to be sent prior to DTLS close notify. This avoids new complex SCTP API to learn if the stack has ACKed all data prior to the transmission of the DTLS close notify. So if the SCTP stack fails to deliver the reordered data in time fashion then we will end up in an SCTP abort that the ULP can be informed of.

[gloinul]

To try to generalize the behavior I expect to be possible with DTLS that is different from TLS.

• DTLS records may arrive after close notify due to reordering. These needs to be processed assuming that their sequence number indicate they being earlier than close notify.
• DTLS connection is not automatically terminated and keys discarded by having sent and received close notify. Instead either default timers or additional mechanism indicate that DTLS connection can be safely terminated and its stated deleted. For example for DTLS/SCTP a SCTP shutdown or SCTP Abort is such an additional indicator that state can be removed. Application termination is also such an additional indicator.

[tuexen]

@tuexen so we found this while working on clarifying the shutdown procedure. So the whole point is to ensure that data that has been committed to the DTLS/SCTP layer will be delivered in a controlled shutdown. We are targeting to have DTLS/SCTP behave like SCTP in regards to shutdown when the upper layer protocol request shutdown. For the improved procedure in DTLS/SCTP see gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis#87 and PR gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis#94

The point of needing this is so that when a peer has requested shutdown, and the DTLS/SCTP has learnt of that by receiving an DTLS close_notify, all data that was sent prior to that must be possible to process and not prevented by this TLS formulation. The DTLS connection state removal can in this case be triggered by the SCTP association shutdown completion or an SCTP abort. We want to be able to use the SCTP shutdown pending mechanism to catch any reordered data requested to be sent prior to DTLS close notify. This avoids new complex SCTP API to learn if the stack has ACKed all data prior to the transmission of the DTLS close notify. So if the SCTP stack fails to deliver the reordered data in time fashion then we will end up in an SCTP abort that the ULP can be informed of.

You could do the normal dance of delay the sending of the close_notify until all prior data has been acked at the SCTP level on the sender side and on the receiver side ensure that you process all data being buffered before processing the close_notify.

Of course, you can rely on the SCTP SHUTDOWN procedure, but doesn't this only work if you have a one to one relation ship between the DTLS connection and the SCTP association? If I remember it correctly, you suggested to multiplex several DTLS connections on a single SCTP association. Maybe I misunderstood this.

[gloinul]

So I want to make clear that this issue is a general one even if we realized it due to DTLS/SCTP work. TLS has an assumption of single stream in order delivery which doesn't hold for DTLS. Thus, DTLS spec needs to change that normative statement to something that makes sense for DTLS where out of order delivery of DTLS records has to be assumed to occur. Thus, I support John's proposal for reformulation because it makes sense and can be judged based on sequence numbers in the DTLS records.

In relply to @tuexen "You could do the normal dance of delay the sending of the close_notify until all prior data has been acked at the SCTP level on the sender side and on the receiver side ensure that you process all data being buffered before processing the close_notify."

Yes, but as you know the documented API to SCTP does not support determining when each user message has been non-renegable ACKed by the peer. Thus, API extensions are needed, or we for this use case to have a shutdown procedure that mimics STCP's behavior at shutdown with minimal extra delay, i.e. waiting for ACKs. So that is what we are targeting if that is impossible we will find another solution including requiring API extensions.

"Of course, you can rely on the SCTP SHUTDOWN procedure, but doesn't this only work if you have a one to one relation ship between the DTLS connection and the SCTP association? If I remember it correctly, you suggested to multiplex several DTLS connections on a single SCTP association. Maybe I misunderstood this."

We don't see that as an issue. As the DTLS/SCTP implementation that owns the DTLS sessions in cases there are two DTLS Connections open, the shutdown on SCTP level happens only when both of the DTLS connections have entered the necessary. But please review the PR for the DTLS/SCTP details: https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis/pull/94

[tuexen]

So I want to make clear that this issue is a general one even if we realized it due to DTLS/SCTP work. TLS has an assumption of single stream in order delivery which doesn't hold for DTLS. Thus, DTLS spec needs to change that normative statement to something that makes sense for DTLS where out of order delivery of DTLS records has to be assumed to occur. Thus, I support John's proposal for reformulation because it makes sense and can be judged based on sequence numbers in the DTLS records.

In relply to @tuexen "You could do the normal dance of delay the sending of the close_notify until all prior data has been acked at the SCTP level on the sender side and on the receiver side ensure that you process all data being buffered before processing the close_notify."

Yes, but as you know the documented API to SCTP does not support determining when each user message has been non-renegable ACKed by the peer. Thus, API extensions are needed, or we for this use case to have a shutdown procedure that mimics STCP's behavior at shutdown with minimal extra delay, i.e. waiting for ACKs. So that is what we are targeting if that is impossible we will find another solution including requiring API extensions.

You can use the sender dry event, it was specified for that purpose.

"Of course, you can rely on the SCTP SHUTDOWN procedure, but doesn't this only work if you have a one to one relation ship between the DTLS connection and the SCTP association? If I remember it correctly, you suggested to multiplex several DTLS connections on a single SCTP association. Maybe I misunderstood this."

We don't see that as an issue. As the DTLS/SCTP implementation that owns the DTLS sessions in cases there are two DTLS Connections open, the shutdown on SCTP level happens only when both of the DTLS connections have entered the necessary. But please review the PR for the DTLS/SCTP details: gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis#94

So you will keep all DTLS connections alive until you shutdown the transport?

[tuexen]

Just wondering... On the sender side you already have reference counting for keys to implement SCTP_AUTH_FREE_KEY in the SCTP_AUTHENTICATION_EVENT. So wouldn't it be a simple extension to add a SCTP_AUTH_DRY_KEY way?

[tuexen]

Regarding the suggested text change: How does the receiver now that a message received was sent after the close_notify was sent?

[gloinul]

Regarding the suggested text change: How does the receiver now that a message received was sent after the close_notify was sent?

To my understanding that would be based on epoch + sequence number of the DTLS record. So any record with a lower extended sequence number than the close_notify alert message should be processed, with a higher discarded.