Re: [tsvwg] DTLS 1.3 over SCTP

[Michael Tuexen <[e-mail]>]

> On 18. Jul 2023, at 16:58, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Hi,
> 
> > MW: Sorry, I think you need expand on your reasoning here. We are working on an integration of a security solution with a transport protocol. This requires combing the security mechanism with the transport protocol such that both the desired security properties and the transport protocol functionality is fulfilled. In this case 3GPP’s applications using SCTP are such that we have security requirements that exists in other works like IPsec but haven’t been in the forefront in other work such as QUIC, HTTP and DTLS.   
> 
> My point was that the usage policies are not limited to SCTP, but to a use of (D)TLS on long living connections.
> This is not related to a specific transport protocol.
> MW: Yes, I think it would be good look into addressing this within TLS, but I don’t see that being resolved in a time frame that makes it possible to delivery anything to 3GPP within the current release, maybe not even the next. So I don’t see this being the solution in the near time. It might be a solution for the future if needed.
Unfortunately I'm not aware with 3GPP timing. Could you state that in years or so? Also do
these milestones refer to the time when specifications should be ready or implementations
should be ready?
>  
> Repeating a question: Why can't we use SCTP over DTLS? It supports arbitrary large messages, you can control the DTLS properties.
> The only thing missing (from what I see) is the support of multihoming and dynamic reconfiguration. That isn't that hard.
> Then you can use multiple DTLS connections to get multihoming and change them over time to get the properties of renegotiation
> back. It would even run over UDP allowing legacy NAT traversal.
> 
> So there are multiple reasons for this that I so far thought about:
>     • Multihoming support which may require a coordination layer for handling the multiple DTLS connections. Multihoming is in use by some that deploy SCTP for the relevant 3GPP solutions. There appear to be some complex protocol interactions here when it comes to path handling. Basically each path would need its own DTLS connection, and you need machinery to establish it and how it interacts with the SCTP stack. For example these DTLS connections need to exist per tuple pairs, not only SCTP notation of path of destinations. 
I agree that you need multiple DTLS connections when using multihoming. I don't see the point regarding tuple pairs.
That is up to the configuration.
>     • It will require a completely different change to 3GPP, which might be possible, but it comes to agree to IP/UDP/DTLS/SCTP and the configuration of that rather than how SCTP is configured. These applications are interoperability points, which requires not only a solution for configuring, but also to figure out which of the multiple solutions one would run. This compared to DTLS for SCTP that would be negotiated in-band and possibly compared against policy configuration.
I don't understand this. I thought that the IETF has to come up with a solution fulfilling
the requirements of 3GPP and then 3GPP will specify interfaces based on this. So why is
negotiation necessary? Why are there multiple protocol stacks being used?

>     • There would still be a need for a solution for replacing the DTLS connections that encapsulate the SCTP packets. The re-authentication and rekeying problem would not be solved.
It does solve this. You can bring up and down DTLS connections as you want. Dynamic address reconfiguration
will take care of this.

Best regards
Michael
> It is interesting question but which appears to have its set of challenges. I will continue to pursue a DTLS for SCTP solution based on either of the two proposals we have put on the table that do fulfill the 3GPP requirements.
> Cheers
> Magnus