DTLS 1.2 rengegotation: Implementation challenges to follow recommendation. about draft-westerlund-tsvwg-dtls-over-sctp-bis

[gloinul]

We discussed this today and the text may need minor tweaks to be as clear as possible. However, there is a receiver side tracking issue. And @tuexen will write an API extension proposal for a receiver side tracking of when all user messages that hasn't been completed are no longer on the previous key, so that the DTLS layer can determine that it can process the key-update without stranding any data in its receiver buffer that was protected with the old key (n-1) when it generates key n+1.

[gloinul]

So with #70 the implementation issues have changed. Now we use the close_notify alert to tell the receiver that the key is no longer needed. But, it is up to the sender to verify reception of the packet. Under some API implementations this might be a challenge to do fully reliable.

[gloinul]

So I am closing this issue as the DTLS parallel connection rekeying can be implemented to my understanding on top of a RFC 6458 API. The issue of knowing when one have drained the old DTLS connection properly can be implemented with a timer based that is equal to the time it would take to consider the SCTP Association failing due to lack of progress on the TSN.

The shutdown procedure described in #94 deals with shutdown in a way using the API's drained indication.

So to my understanding this issue is resolved.

[tuexen]

So I am closing this issue as the DTLS parallel connection rekeying can be implemented to my understanding on top of a RFC 6458 API. The issue of knowing when one have drained the old DTLS connection properly can be implemented with a timer based that is equal to the time it would take to consider the SCTP Association failing due to lack of progress on the TSN.

There is no such timer. It is completely valid that the peer closes its rwnd for an unlimited amount of time.

The shutdown procedure described in #94 deals with shutdown in a way using the API's drained indication.

So to my understanding this issue is resolved.

[gloinul]

There is no such timer. It is completely valid that the peer closes its rwnd for an unlimited amount of time.

@tuexen doesn't a call of sendmsg actually have to have receiver window available for the call to succeed? Or there is this assumption that the kernel will have buffer space that is beyond what is available in receiver window?

And the timer doesn't exist I agree, but an upper bound can be calculated for making progress on a TSN or the association fails prior to this. The time is Association.Max.Retrans * RTO.max and it will be minutes per default.
But, if you can commit data to the kernel per RFC6458 API without it making it into a transmission buffer that fits within the Receiver window then I agree this doesn't work. But, then the API description appears incomplete.

[tuexen]

There is no such timer. It is completely valid that the peer closes its rwnd for an unlimited amount of time.

@tuexen doesn't a call of sendmsg actually have to have receiver window available for the call to succeed? Or there is this assumption that the kernel will have buffer space that is beyond what is available in receiver window?

Whether a sendmsg() call succeeds depends on the size of the send buffer, if the atomic operations are used. But it does not depend on the size of the receive buffer of the peer. You can actually send user messages larger what fits in the receive buffer of the peer. That is why a partial delivery API is needed. WIthout that, the association would end up in a deadlock. This is described in RFC 4960:

Note: If the data receiver runs out of buffer space while still
waiting for more fragments to complete the reassembly of the message,
it should dispatch part of its inbound message through a partial
delivery API (see [Section 10]), freeing some of its receive buffer
space so that the rest of the message may be received.

And the timer doesn't exist I agree, but an upper bound can be calculated for making progress on a TSN or the association fails prior to this. The time is Association.Max.Retrans * RTO.max and it will be minutes per default. But, if you can commit data to the kernel per RFC6458 API without it

That is not true. That limit applies, if the peer does not respond anymore; you can provide an upper limit for detecting a dead peer. But don't you want to limit the time a user message is processed within the SCTP stack (time between it was provided by a sendmsg() call and it the last DATA chunk of it is acknowledged in a non-renegable way)? I do not see any way to provide an upper limit for that.

making it into a transmission buffer that fits within the Receiver window then I agree this doesn't work. But, then the API description appears incomplete.

Not sure what is incomplete. Just to be clear:

• sendmsg() calls are atomic unless explicit end of record marking is enabled. See SCTP_EXPLICIT_EOR. Please note that this is an optional API feature and is not always implemented and it is only specified in the socket API, not in the generic API defined in RFC 4960 This feature allows sending user messages larger than the send buffer size.

• recvmsg() calls are not atomic, you always have to check the MSG_EOR flag. This is a mandatory feature and allows in particular handling user messages larger than the receive buffer size. This is mandatory since it is required to avoid deadlocks. That is why the partial delivery API is already covered in RFC 4960, and not only in the Socket API specification, which is informational.

[gloinul]

Okay sorry for unclear formulations. I believe I understand the difference here between sender buffer and the receiver buffer you are noting. So in this case we are back to the issue that unless you have an richer API that allows you to either query the stack specifically in relation to a user message, or some other abstraction that determines if user messages has been delivered you will not be certain that all messages has been delivered.

This will work in a very large percentage of the cases as it is such a long hold over time beyond when the last data sent with the old keys where committed to the SCTP association and when one closes the DTLS connection. However, it is not certain, and that requires the above API extensions.

[gloinul]

So the new PR corrects the text in the draft to not make false claims. So this is clearly implementable by even an RFC 6458 API assuming tracking user messages sent prior to key change for SCTP-AUTH, although draining will be required.

[gloinul]

What I can judge now this issue is resolved. There are no claims on the timer based methods. There are API requirements and also a way for the sender to ensure that all has been delivered by draining the SCTP association. And for better performance you are going to need more advanced API. There are a potential for an SCTP-AUTH key drained API extension for the RFC 6458 API.