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

[Michael Tuexen <[e-mail]>]

> On 22. Nov 2019, at 07:41, Sidhartha pant <[e-mail]> wrote:
> 
> 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).
Please note that you must ensure that both sides see the same IP-addresses and port numbers. So there MUST NOT
be a NAT involved.
> 
> 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) ?
No.

I would expect that the specification which requires the use of DTLS/SCTP also specifies the client/server role
for DTLS. What specification are you using for the scenario you are describing?
> 
> 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).
I don't like solutions which work conceptually only most of the times. The verification tags are also not exposed to the
application via the socket API, which is specified in https://tools.ietf.org/html/rfc6458.

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