Re: [tsvwg] 3GPP SA3 reply LS on SCTP-AUTH and DTLS

Michael Tuexen <> Wed, 31 May 2023 14:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BE38C151093 for <>; Wed, 31 May 2023 07:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id boepRHq98_SW for <>; Wed, 31 May 2023 07:02:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFC8EC151078 for <>; Wed, 31 May 2023 07:02:43 -0700 (PDT)
Received: from (unknown [IPv6:2a02:8109:1140:c3d:e422:dc49:497b:89]) (Authenticated sender: lurchi) by (Postfix) with ESMTPSA id AB0D47C607C2D; Wed, 31 May 2023 16:02:39 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Michael Tuexen <>
In-Reply-To: <>
Date: Wed, 31 May 2023 16:02:39 +0200
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: John Mattsson <>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <>
Subject: Re: [tsvwg] 3GPP SA3 reply LS on SCTP-AUTH and DTLS
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 May 2023 14:02:49 -0000

> On 30. May 2023, at 17:54, John Mattsson <> wrote:
> Hi,
> 3GPP SA3 (Security) had a meeting last week and sent a Reply LS to TSVWG regarding SCTP-AUTH and DTLS. The LS will appear in the IETF LS tracker at a later date when the 3GPP and IETF secretariats has processed the LS.
> SA3 discussed the discovered vulnerabilities, DTLS over SCTP, DTLS in SCTP, the importance of this work, and agreed on the following text:
> "SA3 would like to thank IETF Transport Area Working Group (TSVWG) for notifying SA3 of the vulnerabilities related to SCTP-AUTH and DTLS over SCTP.
> SA3 agrees that the vulnerabilities are serious – they are affecting confidentiality, integrity, replay, and availability. Supporting DTLS over SCTP in N2, Xn, F1, and E1 interfaces has been made mandatory from Release 15 onwards. Therefore, SA3’s understanding is that it is important to solve all the security vulnerabilities, including the availability vulnerabilities. Since the problem is related to the use of DTLS with SCTP, SA3’s understanding is that the solution should be based on DTLS, and the solution should not rely on unsupported DTLS features.
> SA3 kindly asks TSVWG to work on and publish a solution as soon as possible."
Hi John,

thanks for the information. Where you able to also get some feedback related to the questions
I raised in my e-mail sent on May 14th?
> We need to progress the work in TSVWG fulfilling 3GPP requirements of fixing the availability vulnerabilities, not relying on unsupported DTLS features, and to publish a solution as soon as possible. DTLS in SCTP seems like the only solution as it solves the availability vulnerabilities and do not rely on unsupported DTLS features.
This conclusion is not clear to me. It highly depends on the architecture of the SCTP you are using.
Therefore, my questions above. However, up to know we have not made any particular requirements on
whether you use a userland or kernel SCTP stack. We just specified a socket API and ensured that
you can implement it in kernel land. Implementing it in userland is then not a problem.

Best regards
> Cheers,
> John