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

Sidhartha pant <sidhartha.pant@huawei.com> Mon, 18 November 2019 13:57 UTC

Return-Path: <sidhartha.pant@huawei.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 80EF51208F0 for <tsvwg@ietfa.amsl.com>; Mon, 18 Nov 2019 05:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id agsLCl-7Wo0u for <tsvwg@ietfa.amsl.com>; Mon, 18 Nov 2019 05:57:20 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08FB12084B for <tsvwg@ietf.org>; Mon, 18 Nov 2019 05:57:19 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 952A789D7F326222290F; Mon, 18 Nov 2019 13:57:17 +0000 (GMT)
Received: from BLREML701-CAH.china.huawei.com ( by LHREML712-CAH.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Nov 2019 13:57:17 +0000
Received: from BLREML503-MBX.china.huawei.com ([]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Mon, 18 Nov 2019 19:27:05 +0530
From: Sidhartha pant <sidhartha.pant@huawei.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, "tsvwg@ietf.org" <tsvwg@ietf.org>
CC: Ashutosh prakash <ashutosh.prakash@huawei.com>, Shweta r <shweta.k.r@huawei.com>, Jyoti Ranjan Senapati <jyotiranjans@huawei.com>
Thread-Topic: Query regarding DTLS over SCTP: Client-Client collision scenario in RFC 6083
Thread-Index: AdWeFlMjpRKS5riqTy+mIM3CiiwOEg==
Date: Mon, 18 Nov 2019 13:57:04 +0000
Message-ID: <67CF347253A4874C8F2A2A8CD1D9460B72D526DC@BLREML503-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_67CF347253A4874C8F2A2A8CD1D9460B72D526DCBLREML503MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-PKUYo-Ko9KUMfRRXJD6xK0nF24>
Subject: [tsvwg] Query regarding DTLS over SCTP: Client-Client collision scenario in RFC 6083
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 13:57:23 -0000

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


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 ------------------------------>
                                                     Endpoint B receives INIT-ACK after sending INIT-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