Re: [tsvwg] Query regarding DTLS over SCTP: Client-Client collision scenario in RFC 6083

[Sidhartha pant <[e-mail]>]

Hi Michael,

Did you get a chance to read the following email.
It would be really helpful if you can provide your valuable views. Looking forward to your response.

Warm Regards,
Sidhartha

VPP Team
Huawei Technologies India Pvt. Ltd
India


From: Sidhartha pant
Sent: 18 November 2019 19:27
To: 'Michael Tuexen' <[e-mail]>; '[e-mail]' <[e-mail]>
Cc: Ashutosh prakash <[e-mail]>; Shweta r <[e-mail]>; Jyoti Ranjan Senapati <[e-mail]>
Subject: Query regarding DTLS over SCTP: Client-Client collision scenario in RFC 6083

Hi Michael,

I wish to discuss and take your opinion on one problem faced regarding Clients based on RFC 6083.

Point of discussion is a Client node based on RFC 6083 (DTLS over SCTP).

We are faced with a scenario which requires 2 nodes acting as Client connecting to each other using DTLS over SCTP.

Hence essentially its Client-Client scenario.

Problem faced :-
How to establish a DTLS over SCTP connection in a Client-Client scenario ?

Since DTLS does not support Client-Client topology, hence to resolve this we have decided to rely on the SCTP collision scenario based on RFC 4960 Section 5.2
Thus in this case SCTP Endpoint A acts as server and responds with INIT-ACK to the "unexpected" INIT received in COOKIE-WAIT state.

SCTP Endpoint A                               SCTP Endpoint B

   INIT----------------------------------------->
<---------------------------------------INIT
INIT-ACK--------------------------------->
<-----------------------------------COOKIE-ECHO
COOKIE-ACK--------------------------->



Hence we can resolve the collision for DTLS ( just call SSL Accept at Endpoint A, instead of SSL Connect). Resolving Endpoint A as a Server in this case.

However, there is still a chance that Endpoint B also receives INIT-ACK after sending INIT-ACK, almost simultaneously), thus due to state of the Endpoint still remaining in COOKIE-WAIT results in both responding with COOKIE-ECHO and COOKIE-ACK subsequently (after moving to COOKIE-ECHOED).

As per RFC 4960 Section 5.2.4.  Handle a COOKIE ECHO when a TCB Exists

"D) When both local and remote tags match, the endpoint should enter the ESTABLISHED state, if it is in the COOKIE-ECHOED state.

   It should stop any cookie timer that may be running and send a COOKIE ACK."



SCTP Endpoint A                               SCTP Endpoint B

      <-------------------------------------- INIT
INIT ------------------------------------>
<----------------------------------INIT-ACK
     INIT-ACK ------------------------------>
                                                     Endpoint B receives INIT-ACK after sending INIT-ACK
     <----------------------------------COOKIE-ECHO
      COOKIE-ECHO----------------------->
      <------------------------------------COOKIE-ACK
COOKIE-ACK--------------------------->


In this scenario, how do we decide to choose the endpoint for initiating the SSL CONNECT ( and SSL ACCEPT on the other) ? Both acted as server here.
How do we create DTLS over SCTP connection in this case. Has someone else also faced this problem in the community, or we are missing something here ?

It will be great if you can throw some light on this.

Warm Regards,
Sidhartha Pant

VPP Team
Huawei Technologies India Pvt. Ltd
India