Re: [tsvwg] DTLS 1.3 over SCTP

[Michael Tuexen <[e-mail]>]

> On 20. Jul 2023, at 11:44, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Hi Michael,
>  Please see inline.
>  From: Michael Tuexen <[e-mail]>
> Date: Wednesday, 19 July 2023 at 11:58
> To: Magnus Westerlund <[e-mail]>
> Cc: tsvwg IETF list <[e-mail]>
> Subject: Re: [tsvwg] DTLS 1.3 over SCTP
> > 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?
> MW: So Rel 18 stage 3 closes at the end of this year. (Stage 3 is detailed technical specification.) If we have a draft for SCTP in DTLS that meets 3GPP requirements and are far along in the process it can be adopted into a specification as place holder, and then be updated in later change request (CR) to the final RFC number later. This to indicate that this is what you need to implement towards. However, as this is a critical bug fix that will likely affect the older specifications all the way back to Rel 15, which is when RFC 6083 was introduced into 3GPP TS 33.501 it can be done at any time. But we want to get this done as soon as possible as not having a solution delays the implementation and deployment of this security feature. 
OK, thanks for the clarification. Since Rel 15 sounds older than Rel 18, does this mean that RFC 6083 is deployed?
Are you aware of any implementations?
> >  
> > 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.
> MW: So this is a critique against the SCTP spec that I have, in that it actually don’t track paths as defined by source and destination, it only tracks destination. For a DTLS connection to function well and avoid any reordering issue, I strongly believe that one needs one DTLS connection per source + destination pair. Our implementation do track paths in this way, but if it required to define a usage of DTLS you are lacking a term in the SCTP spec to reference for what it is. 
When running SCTP over DTLS, SCTP doesn't see the IP addresses anymore. You can establish any number of DTLS connections,
like a full mesh, and SCTP would just use them. At least in the way SCTP over DTLS is implemented in the userland stack
of the BSD stack.
> >     • 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?
> MW: The issue is that 3GPP already have defined the interfaces, these are interfaces that in some cases have existed a long time. Thus, you need an easy upgrade path from what existed before and what you are going to use. One reasons RFC 6083 was chosen was that you easily could start using it in some nodes and have those that have been upgraded negotiate usage of DTLS when it was possible. Then when you have upgraded a set of nodes and see that it works then you apply to policy that it shall be required to use DTLS among those nodes. Thus RFC 6083 didn’t have widespread impact on the management system in 3GPP. Your proposal for running DTLS under SCTP will create need for other mechanism and thus have more widespread impact on the system when it comes to deploying this.
You would need some happy eyeballing approach... 
> I should also point out that many of the SCTP using interfaces are what we usually refer to as multi-vendor interfaces, i.e. interfaces where one expects that implementations from Ericsson, Nokia, Huawei, Samsung etc will need to communicate and interop. Deploying changes to intra vendor interfaces, i.e. interfaces where an Ericsson implementation would talk to an Ericsson implementation are simpler. There can then also be vendor specific configuration options to handle cases like this. 
OK.
> 
> >     • 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.
> MW: Well, that is if you support dynamic address reconfiguration. Which to my understanding there are no requirement to support for 3GPP implementation. Thus, it is yet another thing that would need to be changed in the 3GPP system. To summarize for us as a vendor an issue is that DTLS under SCTP has much
That is true. However, it is a very old extension. Open Source implementations support this, although it is
not enabled when used in a Telco environment. Not sure about proprietary implementations.

Best regards
Michael
> more wide spread impact on more nodes and functions in the system than just the SCTP using interface nodes. Cheers
> Magnus