Subject: [tsvwg] DTLS over SCTP: To obsolete RFC 6083 or not?

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Mar 2022 17:37:52 +0000

Hi,

I thought I would prime the discussion we will have on Monday in the WG
session. So the main question here is how to proceed with
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/. There
are two main alternatives that I found realistic that the WG can choose
between.

A.	Obsoleting RFC 6083 when publishing this draft as RFC

B.	Publishing as an alternative RFC to RFC6083 without obsoleting

The reason I don't think other options are on the table is that they would
result that there are no IETF specification for DTLS over SCTP that
addresses 3GPP's clearly stated need per their LS
(https://datatracker.ietf.org/liaison/1723/). It is also clear to me having
now worked on this document a bit more than a year that there are a number
of short comings of RFC 6083. Many of them has actually been caused by RFC
8996 obsoleting DTLS over SCTP usage of prior DTLS version than 1.2. Another
aspect is the general aging of SCTP-AUTH and lack of maintenance update of
that specification to address SHA-1 status of being non-recommend algorithm
in general, but being the mandatory to implement in RFC 4895. 

The main issues due to these aging dependency are:

*	RFC 6083 relies on DTLS to rekey the DTLS connection. 

*	For DTLS 1.2 there exist support for renegotiation with mutual
authentication which is good. However, there are some security risks here
that needs to be mitigated and a number of implementations have simply
disabled the functionality.
*	DTLS 1.2 is limited to 65534 rekeyings which could potentially
affect really long lived associations or with high bandwidth forcing
rekeying. 
*	DTLS 1.3 lacks renegotiation and can only do a key-update. Which has
several impacts: 

*	first of all no mutual re-authentications 
*	secondly key-update does not result in any new master secret which
results in that SCTP-AUTH will have a single key for the whole SCTP
association life time. Which will limit the SCTP association life-time.
*	Third, no forward secrecy is provided

*	SCTP-AUTH may use SHA-1 unless individual implementation ensure to
move it into less preferred status, but none of the current in force RFCs
recommend to do this.
*	Lack of updated security considerations for the protocol with either
DTLS versions. Where especially DTLS 1.2 really can benefit from
recommendations for crypto algorithms to use etc.

The other reason why an new DTLS over SCTP specification is need has to do
with the properties and features that the WG draft provides compared to RFC
6083. To summarize the high level differences:

1.	User message sizes of at least 2^64-1 bytes are supported. Some
senders may be more limited due to their SCTP API, but still significantly
more that 16384 bytes that RFC 6083 provides.
2.	The usage of DTLS/SCTP is negotiated during the SCTP association
handshake with makes it clearer that DTLS/SCTP want to be used. It also
allow us to ensure that all user messages are protected.
3.	The impact on the ULP's usage of SCTP when protecting user messages
with DTLS has been further reduced:

a.	We have removed the requirement to use stream 0 and that this stream
is configured to send in-order reliable user messages.
b.	The rekeying mechanism also can avoid the need draining all user
messages from the SCTP association before changing key, i.e. the ULP does
not need to pause its usage until the key has sent.

4.	A rekeying mechanism that provides mutual authentication, forward
secrecy, SCTP-AUTH rekeying, and no practical limitation on SCTP association
life span. It also is substantially more independent of DTLS version than
RFC 6083 in its core mechanism. 

The document also clarifies a couple of interactions that might not have
been completely described in RFC 6083. For example the shutdown procedure
for the peer to the one initiating the shutdown.

So I hope it is fairly clear that not producing a new specification for DTLS
over SCTP would be bad. Thus, we are back to the two reasonable options I
see:

A.	Obsoleting RFC 6083 when publishing this draft as RFC

B.	Publishing as an alternative RFC to RFC6083 without obsoleting

The WG can come to consensus to leave a RFC 6083 in place for those use
cases that can live with the limitations stated above including message
size. However, it also leaves those users with some pitfalls when it comes
to security. I would strongly recommend if there are a proponent for B, that
they should actually make an update to RFC 6083 to address at least the
security considerations for how to safely use it.

I personally think the only reason for not picking A. is the IPR
declarations made (https://datatracker.ietf.org/ipr/5195/ and
https://datatracker.ietf.org/ipr/5218/). I hope any proponent for B are
either currently using RFC 6083 in a solution where it works for them, or
are planning to use it, and see the IPR as a significant hurdle.

So please provide your opinion. Also don't hesitate to ask for clarification
on any aspect of the above.

Cheers

Magnus Westerlund

Co-author of draft-ietf-tsvwg-dtls-over-sctp

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 17 Mar 2022 16:07:13 +0000

Thanks Magnus,

I think this is really useful input to the WG, and it would be useful to 
have people's feedback via the mailing list - or at the TSVWG  meeting 
next week.

On 16/03/2022 17:37, Magnus Westerlund wrote:
>
> Hi,
>
> I thought I would prime the discussion we will have on Monday in the 
> WG session. So the main question here is how to proceed with 
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/. 
> There are two main alternatives that I found realistic that the WG can 
> choose between.
>
>      1. Obsoleting RFC 6083 when publishing this draft as RFC
>
>      2. Publishing as an alternative RFC to RFC6083 without obsoleting
>
> The reason I don’t think other options are on the table is that they 
> would result that there are no IETF specification for DTLS over SCTP 
> that addresses 3GPP’s clearly stated need per their LS 
> (https://datatracker.ietf.org/liaison/1723/). It is also clear to me 
> having now worked on this document a bit more than a year that there 
> are a number of short comings of RFC 6083. Many of them has actually 
> been caused by RFC 8996 obsoleting DTLS over SCTP usage of prior DTLS 
> version than 1.2. Another aspect is the general aging of SCTP-AUTH and 
> lack of maintenance update of that specification to address SHA-1 
> status of being non-recommend algorithm in general, but being the 
> mandatory to implement in RFC 4895.
>
>       o For DTLS 1.2 there exist support for renegotiation with mutual
>         authentication which is good. However, there are some security
>         risks here that needs to be mitigated and a number of
>         implementations have simply disabled the functionality.
>       o DTLS 1.2 is limited to 65534 rekeyings which could potentially
>         affect really long lived associations or with high bandwidth
>         forcing rekeying.
>       o DTLS 1.3 lacks renegotiation and can only do a key-update.
>         Which has several impacts:
>           + first of all no mutual re-authentications
>           + secondly key-update does not result in any new master
>             secret which results in that SCTP-AUTH will have a single
>             key for the whole SCTP association life time. Which will
>             limit the SCTP association life-time.
>           + Third, no forward secrecy is provided
>     move it into less preferred status, but none of the current in
>     force RFCs recommend to do this.
>   * Lack of updated security considerations for the protocol with
>     either DTLS versions. Where especially DTLS 1.2 really can benefit
>     from recommendations for crypto algorithms to use etc.
>
> The other reason why an new DTLS over SCTP specification is need has 
> to do with the properties and features that the WG draft provides 
> compared to RFC 6083. To summarize the high level differences:
>
>     senders may be more limited due to their SCTP API, but still
>     significantly more that 16384 bytes that RFC 6083 provides.
>     handshake with makes it clearer that DTLS/SCTP want to be used. It
>     also allow us to ensure that all user messages are protected.
>  3. The impact on the ULP’s usage of SCTP when protecting user
>     messages with DTLS has been further reduced:
>      1. We have removed the requirement to use stream 0 and that this
>         stream is configured to send in-order reliable user messages.
>      2. The rekeying mechanism also can avoid the need draining all
>         user messages from the SCTP association before changing key,
>         i.e. the ULP does not need to pause its usage until the key
>         has sent.
>     secrecy, SCTP-AUTH rekeying, and no practical limitation on SCTP
>     association life span. It also is substantially more independent
>     of DTLS version than RFC 6083 in its core mechanism.
>
> The document also clarifies a couple of interactions that might not 
> have been completely described in RFC 6083. For example the shutdown 
> procedure for the peer to the one initiating the shutdown.
>
> So I hope it is fairly clear that not producing a new specification 
> for DTLS over SCTP would be bad. Thus, we are back to the two 
> reasonable options I see:
>
>  1. Obsoleting RFC 6083 when publishing this draft as RFC
>
>  2. Publishing as an alternative RFC to RFC6083 without obsoleting
>
> The WG can come to consensus to leave a RFC 6083 in place for those 
> use cases that can live with the limitations stated above including 
> message size. However, it also leaves those users with some pitfalls 
> when it comes to security. I would strongly recommend if there are a 
> proponent for B, that they should actually make an update to RFC 6083 
> to address at least the security considerations for how to safely use it.
>
> https://datatracker.ietf.org/ipr/5218/). I hope any proponent for B 
> are either currently using RFC 6083 in a solution where it works for 
> them, or are planning to use it, and see the IPR as a significant hurdle.
>
> So please provide your opinion. Also don’t hesitate to ask for 
> clarification on any aspect of the above.
>
> Cheers
>
> Magnus Westerlund
>
To me this seems a great summary, and possibilities could indeed include 
also a minor update to RFC603.bis to solve pitfalls.  I hope we can make 
progress on this topic over the next week.

Gorry

(TSVWG Co-Chair)

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 18 Mar 2022 17:43:31 +0100

> On 16. Mar 2022, at 18:37, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 
> Hi,
Hi,

some non-technical comments in-line.

Best regards
Michael
>  
> I thought I would prime the discussion we will have on Monday in the WG session. So the main question here is how to proceed with https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/. There are two main alternatives that I found realistic that the WG can choose between.
>  
> 		• Obsoleting RFC 6083 when publishing this draft as RFC
>  
> 		• Publishing as an alternative RFC to RFC6083 without obsoleting

>  
> The reason I don’t think other options are on the table is that they would result that there are no IETF specification for DTLS over SCTP that addresses 3GPP’s clearly stated need per their LS (https://datatracker.ietf.org/liaison/1723/). It is also clear to me having now worked on this document a bit more than a year that there are a number of short comings of RFC 6083. Many of them has actually been caused by RFC 8996 obsoleting DTLS over SCTP usage of prior DTLS version than 1.2. Another aspect is the general aging of SCTP-AUTH and lack of maintenance update of that specification to address SHA-1 status of being non-recommend algorithm in general, but being the mandatory to implement in RFC 4895. 
>  
> 	• RFC 6083 relies on DTLS to rekey the DTLS connection. 
> 		• For DTLS 1.2 there exist support for renegotiation with mutual authentication which is good. However, there are some security risks here that needs to be mitigated and a number of implementations have simply disabled the functionality.
> 		• DTLS 1.2 is limited to 65534 rekeyings which could potentially affect really long lived associations or with high bandwidth forcing rekeying. 
> 		• DTLS 1.3 lacks renegotiation and can only do a key-update. Which has several impacts: 
> 			• first of all no mutual re-authentications 
> 			• secondly key-update does not result in any new master secret which results in that SCTP-AUTH will have a single key for the whole SCTP association life time. Which will limit the SCTP association life-time.
> 			• Third, no forward secrecy is provided
> 	• SCTP-AUTH may use SHA-1 unless individual implementation ensure to move it into less preferred status, but none of the current in force RFCs recommend to do this.

> 	• Lack of updated security considerations for the protocol with either DTLS versions. Where especially DTLS 1.2 really can benefit from recommendations for crypto algorithms to use etc.
>  
> The other reason why an new DTLS over SCTP specification is need has to do with the properties and features that the WG draft provides compared to RFC 6083. To summarize the high level differences:
> 	• User message sizes of at least 2^64-1 bytes are supported. Some senders may be more limited due to their SCTP API, but still significantly more that 16384 bytes that RFC 6083 provides.
> 	• The usage of DTLS/SCTP is negotiated during the SCTP association handshake with makes it clearer that DTLS/SCTP want to be used. It also allow us to ensure that all user messages are protected.
> 	• The impact on the ULP’s usage of SCTP when protecting user messages with DTLS has been further reduced:
> 		• We have removed the requirement to use stream 0 and that this stream is configured to send in-order reliable user messages.
> 		• The rekeying mechanism also can avoid the need draining all user messages from the SCTP association before changing key, i.e. the ULP does not need to pause its usage until the key has sent.
> 	• A rekeying mechanism that provides mutual authentication, forward secrecy, SCTP-AUTH rekeying, and no practical limitation on SCTP association life span. It also is substantially more independent of DTLS version than RFC 6083 in its core mechanism. 
>  
> The document also clarifies a couple of interactions that might not have been completely described in RFC 6083. For example the shutdown procedure for the peer to the one initiating the shutdown.
>  
> So I hope it is fairly clear that not producing a new specification for DTLS over SCTP would be bad. 
I agree that it is good to have a document updating RFC 6083.
Especially since the services provided by DTLS 1.2 and DTLS 1.3 are not backwards compatible,
which was assumed when we wrote RFC 6083.
> Thus, we are back to the two reasonable options I see:
>  
> 	• Obsoleting RFC 6083 when publishing this draft as RFC
>  
> 	• Publishing as an alternative RFC to RFC6083 without obsoleting
>  
> The WG can come to consensus to leave a RFC 6083 in place for those use cases that can live with the limitations stated above including message size. However, it also leaves those users with some pitfalls when it comes to security. I would strongly recommend if there are a proponent for B, that they should actually make an update to RFC 6083 to address at least the security considerations for how to safely use it.
>  
> I personally think the only reason for not picking A. is the IPR declarations made (https://datatracker.ietf.org/ipr/5195/ and https://datatracker.ietf.org/ipr/5218/). I hope any proponent for B are either currently using RFC 6083 in a solution where it works for them, or are planning to use it, and see the IPR as a significant hurdle.
>  
> So please provide your opinion. Also don’t hesitate to ask for clarification on any aspect of the above.
I consider using DTLS over SCTP the best method specified in the IETF to secure user
messages over SCTP (compared to using IPSec or TLS).
If 3GPP needs an improved version, Ericsson provides an IPR protected solution,
and states that having the IPR does not limit the deployment related to the use case
relevant for 3GPP, I have no problem with such a solution being developed within 3GPP.

However, specifying DTLS over SCTP within the IETF in a way that a license from Ericsson
is needed, seems suboptimal to me and is worse than RFC 6083.

I would prefer an update to RFC 6083 without relying on IPR from Ericsson (and other companies)
to allow it to be implemented in Open Source. If it is not possible to deliver all features
requested by 3GPP, then 3GPP can publish an extended version.

I would not have voted for WG adoption of the document, if the IPRs would have been declared
at that point of time. Why should spend the WG resources to strengthen the IPR portfolio of
Ericsson?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 18 Mar 2022 17:55:08 +0100

> On 16. Mar 2022, at 18:37, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
Hi Magnus,

some technical comments in-line.

Best regards
Michael
> 		• For DTLS 1.2 there exist support for renegotiation with mutual authentication which is good. However, there are some security risks here that needs to be mitigated and a number of implementatio…
I don't think we should argue with implementations, since implementing it now
requires a license from Ericsson, or am I wrong?
> 		• DTLS 1.2 is limited to 65534 rekeyings which could potentially affect really long lived associations or with high bandwidth forcing rekeying. 
That was not expected when we wrote RFC 6083.
> 			• Third, no forward secrecy is provided
That was not expected when we wrote RFC 6083.
> 	• SCTP-AUTH may use SHA-1 unless individual implementation ensure to move it into less preferred status, but none of the current in force RFCs recommend to do this.
An end-point negotiates the algorithm being used and indicates which ones it prefers. HMAC-SHA1
is the only mandatory to implement algorithm and is, as far as I know, not broken. Some implementations
(like the Linux kernel) only support this, others (like the FreeBSD one) support also others and
also prefer them. However, what is preferred is a local matter.
> 	• Lack of updated security considerations for the protocol with either DTLS versions. Where especially DTLS 1.2 really can benefit from recommendations for crypto algorithms to use etc.
Is that specific to DTLS/SCTP? If not, shouldn't it be in a generic document?
> 		• We have removed the requirement to use stream 0 and that this stream is configured to send in-order reliable user messages.
I don't understand this. Neither reliability nor in-order delivery is a property of a stream.
I don't think this limitation exists in RFC 6083.
> 		• The rekeying mechanism also can avoid the need draining all user messages from the SCTP association before changing key, i.e. the ULP does not need to pause its usage until the key has sent.
I don't see how you can *avoid* the draining. I do see how you can make it occur less likely
happening by keeping key material longer alive in the SCTP stack than it is necessary for RFC 6083,
but I don't see a way around it.
> The document also clarifies a couple of interactions that might not have been completely described in RFC 6083. For example the shutdown procedure for the peer to the one initiating the shutdown.
Not sure what is unclear. We have explicit text:
https://datatracker.ietf.org/doc/html/rfc6083#section-4.9
>  
> So I hope it is fairly clear that not producing a new specification for DTLS over SCTP would be bad. Thus, we are back to the two reasonable options I see:
>

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 20 Mar 2022 20:27:06 +0000

Hi Michael,

Please see inline. I hope I didn't miss any of your comments as your responses got very much mixed in with my original message in my email client. 

> > 		• For DTLS 1.2 there exist support for
> renegotiation with mutual authentication which is good. However, there are
> some security risks here that needs to be mitigated and a number of
> I don't think we should argue with implementations, since implementing it
> now requires a license from Ericsson, or am I wrong?

First of all, the underlying issue is that DTLS 1.2 renegotiation have proven hard to implement securely resulting in vulnerabilities. 

That leads to the observation that it has affected the availability of DTLS implementations with this feature. 

> > 		• DTLS 1.2 is limited to 65534 rekeyings which
> could potentially affect really long lived associations or with high bandwidth
> forcing rekeying.

Fully understood as DTLS 1.0 has unlimited renegotiations. 

> > 			• secondly key-update does not
> result in any new master secret which results in that SCTP-AUTH will have a
> single key for the whole SCTP association life time. Which will limit the SCTP
> association life-time.

Agreed but now the reality of what RFC 6083 combined with DTLS 1.3 will result in. 

> > 	• SCTP-AUTH may use SHA-1 unless individual implementation
> ensure to move it into less preferred status, but none of the current in force
> RFCs recommend to do this.
> An end-point negotiates the algorithm being used and indicates which ones it
> prefers. HMAC-SHA1 is the only mandatory to implement algorithm and is, as
> far as I know, not broken. Some implementations (like the Linux kernel) only
> support this, others (like the FreeBSD one) support also others and also
> prefer them. However, what is preferred is a local matter.

Yes, I think you are correct that HMAC-SHA1 is not broken. However, it is an aging algorithm that if not yet past its best before date, it is getting close to it. And updating the recommendations for secure algorithms to use and support to ensure secure deployments for a number of coming years that are interoperable. 

> > 	• Lack of updated security considerations for the protocol with
> either DTLS versions. Where especially DTLS 1.2 really can benefit from

Some may be specific, or at least DTLS/SCTP are using quite a lot of the functionality of DTLS. But, other are likely generic. Is there a point in writing a generic document maybe not due to that other applications may not require the same set of features, and for some the recommendation is simply go to DTLS 1.3 that solves them. 

> > 	• The usage of DTLS/SCTP is negotiated during the SCTP
> association handshake with makes it clearer that DTLS/SCTP want to be used.
> It also allow us to ensure that all user messages are protected.
> > 	• The impact on the ULP’s usage of SCTP when protecting user
> > 		• We have removed the requirement to use
> stream 0 and that this stream is configured to send in-order reliable user
> messages.

>From RFC 6083: 

4.4.  Stream Usage

   All DTLS messages of the ChangeCipherSpec, Alert, or Handshake
   protocol MUST be transported on stream 0 with unlimited reliability
   and with the ordered delivery feature.

Sorry if express myself unclear that all these message needs to delivered in-order and full reliability. 

> > 		• The rekeying mechanism also can avoid the
> need draining all user messages from the SCTP association before changing
> key, i.e. the ULP does not need to pause its usage until the key has sent.

> I don't see how you can *avoid* the draining. I do see how you can make it
> occur less likely happening by keeping key material longer alive in the SCTP
> stack than it is necessary for RFC 6083, but I don't see a way around it.

There is no need to drain the association completely. Instead it is a matter of knowing when all DTSL Records and all SCTP packets protected using the SCTP-auth key derived from that DTLS connection has been ACKed in a non-renegable way, then you close the old DTLS connection. While this data is being delivered any new data is protected using the new connection. Thus, you never need to stop transmitting ULP user messages when doing a rekeying. Maybe using the word avoiding drain here is a poor choice, as we in some sense are draining data related to the old keys. 

> been completely described in RFC 6083. For example the shutdown

So, if endpoint A initiates a shutdown, how does endpoint B now that it needs to perform the process described in Section 4.9? There are no message or defined porcess, it appears that it assumes that there must be an ULP message for preparing to do SCTP association shutdown?

Cheers

Magnus

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 20 Mar 2022 22:18:30 +0100

> On 20. Mar 2022, at 21:27, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 
> Hi Michael,
> 
Hmm. I'm sorry. I think I did nothing special when responding, just providing
comments in-line.
> Sorry if express myself unclear that all these message needs to delivered in-order and full reliability. 
This only affects the messages listed. And I guess you want to do
the same, since it doesn't make sense to make use of the DTLS
reordering and retransmission methods when SCTP can provide them,
most like in a better way.
In DTLS 1.0, you want to keep the messages of a handshake in sequence
and also you don't want to interleave the messages of different handshakes.
So using one stream for them seem appropriate. Stream 0 does always
exist, but you could use any. Not sure what you would gain.
> There is no need to drain the association completely. Instead it is a matter of knowing when all DTSL Records and all SCTP packets protected using the SCTP-auth key derived from that DTLS connection has been ACKed in a non-renegable way, then you close the old DTLS connection. While this data is being 
But you don't want to keep the old keys in the DTLS layer forever.
So you need some way of draining, you only can make the probability
it actually needs to trigger small.
> delivered any new data is protected using the new connection. Thus, you never need to stop transmitting ULP user messages when doing a rekeying. Maybe using the word avoiding drain here is a poor choice, as we in some sense are draining data related to the old keys. 
Are you saying that you can have an unlimited number of DTLS connections
being active? How do you map these to the limited number of AUTH keys?
> So, if endpoint A initiates a shutdown, how does endpoint B now that it needs to perform the process described in Section 4.9? There are no message or defined porcess, it appears that it assumes th…
Assume endpoint A decides to perform a SHUTDOWN. The following steps need to happen:
1. A wait until all user messages have been acked (draining).
2. A send the CloseNotify.
3. When B receives the CloseNotify, it reads all messages from the SCTP stack and
   processes them, before processing the CloseNotify.
4. Now B drains and send the CloseNotify.
5. When A receives the CloseNotify, it reads all messages from the SCTP stack and
   processes them.
6. A initiates the SCTP Shutdown procedure.
7. B responds with a SHUTDOWN-ACK.
8. A responds with a SHUTDOWN-COMPLETE.
I think this is what is described in https://datatracker.ietf.org/doc/html/rfc6083#section-4.9.

Best regards
Michael

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Mar 2022 10:35:55 +0000

Hi,

Please see inline. 

> -----Original Message-----
> From: Michael Tuexen <[email-masked]>
> Sent: den 20 mars 2022 22:19
> To: Magnus Westerlund <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tsvwg] DTLS over SCTP: To obsolete RFC 6083 or not?
> 
> > On 20. Mar 2022, at 21:27, Magnus Westerlund
> <magnus.westerlund=[email-masked]> wrote:
> >
> > Hi Michael,
> >
> > Please see inline. I hope I didn't miss any of your comments as your
> responses got very much mixed in with my original message in my email
> client.

I think it is Outlook that screw up, I think it may be the lack of an empty line between quoted text and your response. 

> >> stream 0 and that this stream is configured to send in-order reliable
> >> user messages.
> This only affects the messages listed. And I guess you want to do the same,
> since it doesn't make sense to make use of the DTLS reordering and
> retransmission methods when SCTP can provide them, most like in a better
> way.
> In DTLS 1.0, you want to keep the messages of a handshake in sequence and
> also you don't want to interleave the messages of different handshakes.
> So using one stream for them seem appropriate. Stream 0 does always exist,
> but you could use any. Not sure what you would gain.

There might not be a large gain here. However, due to DTLS 1.3 the DTLS/SCTP is anyway unable to separate out the DTLS Control messages due to all being sent with the same content type. So the reality is that any transmission will be possible and being clear that this is okay avoids restricting implementation in an unnecessary way. I believe there are also some cases of stream level head of line blocking that could be avoided by not mixing DTLS control messages and ULP messages. 

> >> need draining all user messages from the SCTP association before
> >> changing key, i.e. the ULP does not need to pause its usage until the key
> has sent.
> >
> >> I don't see how you can *avoid* the draining. I do see how you can
> >> make it occur less likely happening by keeping key material longer
> >> alive in the SCTP stack than it is necessary for RFC 6083, but I don't see a
> way around it.
> >
> > There is no need to drain the association completely. Instead it is a
> > matter of knowing when all DTSL Records and all SCTP packets protected
> > using the SCTP-auth key derived from that DTLS connection has been
> > ACKed in a non-renegable way, then you close the old DTLS connection.
> > While this data is being
> So you need some way of draining, you only can make the probability it
> actually needs to trigger small.
> > delivered any new data is protected using the new connection. Thus, you
> never need to stop transmitting ULP user messages when doing a rekeying.
> Maybe using the word avoiding drain here is a poor choice, as we in some
> sense are draining data related to the old keys.

No, we allow only 2 DTLS connection. But, the ULP never have to stop sending user messages as the sender will use DTLS connection N+1 while N is being "drained" out of the SCTP Association in the background. The question is really about how one knows that all SCTP packets containing data protected by N has been acked in a non-renegable way. We believe we have a way now to do it and thanks to your ideas we can clarify them so that one can actually key this draining completion to when the SCTP stack has received ACKS (non-renegable) for packets protected using the SCTP-AUTH key derived from DTSL Connection N. 

With the exception of the last how this should work should be clear in the draft. 

> >>> have
> > So, if endpoint A initiates a shutdown, how does endpoint B now that it
> needs to perform the process described in Section 4.9? There are no
> message or defined porcess, it appears that it assumes that there must be an
> ULP message for preparing to do SCTP association shutdown?
> I think this is what is described in
> https://datatracker.ietf.org/doc/html/rfc6083#section-4.9.

Okay, that expansion is significantly more detailed than what is in the text. I would also note that this has some DTLS version issues. 

With DTLS 1.2 as soon as B process the Close_notify it will be closed for additional sending. So you need an addition step of actually closing the ULP from sending more messages, and ensure that it has committed all data to the SCTP Level before processing the Close_notify. 

With DTLS 1.3 step 3 can't work as the DTLS/SCTP layer in B can't identify the Close_notify as it will look just like any other application data DTLS record. 
The upside is that this only results in the closing the DTLS Stack in B from receiving more data from A, and B can still send. 

Cheers

Magnus Westerlund

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 21 Mar 2022 12:50:57 +0100

> On 21. Mar 2022, at 11:35, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 
> Hi,
> 
> Please see inline. 
> 

OK, that is possible, don't have any experience with Outlook.

> There might not be a large gain here. However, due to DTLS 1.3 the DTLS/SCTP is anyway unable to separate out the DTLS Control messages due to all being sent with the same content type. So the real…

Correct. But you want to send the control messages on the same stream, ordered, realiable,
if they have some ordering constraints.

> No, we allow only 2 DTLS connection. But, the ULP never have to stop sending user messages as the sender will use DTLS connection N+1 while N is being "drained" out of the SCTP Association in the b…

Correct. But my point is: you need a way of draining. Using 2 connections you most likely
can continue to send, but you can't guarantee for it.

> Okay, that expansion is significantly more detailed than what is in the text. I would also note that this has some DTLS version issues. 

I don't think it so:
The first paragraph in Section 4.9 tells you to do 1 before 2, the second tells you to
do 3 after 2.
4 and 5 are just the other end point. 6,7,8 is the normal SCTP level teardown. It does
not need to be described in a document for DTLS/SCTP.

> With DTLS 1.2 as soon as B process the Close_notify it will be closed for additional sending. So you need an addition step of actually closing the ULP from sending more messages, and ensure that it…

But that is DTLS 1.2 stuff, it should not be in a document describing how to use
DTLS over SCTP.

> With DTLS 1.3 step 3 can't work as the DTLS/SCTP layer in B can't identify the Close_notify as it will look just like any other application data DTLS record. 

That is not true. The DTLS layer knows this after decryption. So it can do what it needs to do.
This is similar to DTLS 1.0. You won't do anything until DTLS has verified the MAC.

> The upside is that this only results in the closing the DTLS Stack in B from receiving more data from A, and B can still send. 

Not sure I understand this sentence.

Best regards
Michael