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

[Sidhartha pant <[e-mail]>]

Hi Michael,

Thanks a lot for your response. Appreciate it.

I think we can solve our problem with the contention resolution as suggested by you ( 1. IP 2. Port).

Is there a standard for this? Since we would need to do this at both the ends of the association so this would need to be an Open standard ( to resolve any interoperability issues with Third party) ?

Also we have thought of resolving this contention with Initiate Tag ( since this is known at the initial Handshake), the larger one can be chosen as either Client or Server. Do you have any thoughts on that? This has a chance of failure when both Tag are same though (1 out of 2^32).

Thanks again.

Warm Regards,
Sidhartha

VPP Team
Huawei Technologies India Pvt. Ltd
India


-----Original Message-----
From: Michael Tuexen [mailto:[e-mail]] 
Sent: 21 November 2019 22:54
To: Sidhartha pant <[e-mail]>
Cc: [e-mail]; Ashutosh prakash <[e-mail]>; Shweta r <[e-mail]>; Jyoti Ranjan Senapati <[e-mail]>
Subject: Re: Query regarding DTLS over SCTP: Client-Client collision scenario in RFC 6083

> On 18. Nov 2019, at 14:57, Sidhartha pant <[e-mail]> wrote:
> 
> 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 ?
As you noted correctly, SCTP can deal with this (called INIT collision case) and results in a single SCTP association.
DTLS does NOT have this feature. Trying to use some features of the SCTP handshake to resolve the DTLS client/server role isn't architecturally not the right way and might even not work at all. It definitely doesn't work using the socket API.

I would suggest to use some data of the SCTP association to resolve it.
For example, you could use:
1. Compare the set of addresses of both sides and figure out if one side has a smallest (by some
   ordering (compare them in host byte order as uint32_t (IPv4) or uint128_t (IPv6).
   Then the side with the smallest address is the client (or server).
2. If the smallest address is the same, compare the port numbers. Then the side with the smallest port
   is the client (or server).
This only doesn't work if the smallest address is the same on both sides and the port numbers are the same. This means an end-point is talking to itself. I think this does not occur in your setup.

Would this solve your problem in a portable way?

Best regards
Michael
 
> 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