Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 and SA3
Michael Tuexen <michael.tuexen@lurchi.franken.de> Wed, 02 August 2023 09:21 UTC
Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AD1C14CE5E for <tsvwg@ietfa.amsl.com>; Wed, 2 Aug 2023 02:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYsT4RfOLIAN for <tsvwg@ietfa.amsl.com>; Wed, 2 Aug 2023 02:21:30 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343A2C14CF0D for <tsvwg@ietf.org>; Wed, 2 Aug 2023 02:21:29 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:7151:b57:f163:85e1]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 88BE47567D570; Wed, 2 Aug 2023 11:21:24 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <DU0PR07MB89705E710A4E3F9E3DFFEE98950BA@DU0PR07MB8970.eurprd07.prod.outlook.com>
Date: Wed, 02 Aug 2023 11:21:24 +0200
Cc: Marten Seemann <martenseemann@gmail.com>, Peter Schmitt <Peter.Schmitt@huawei.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <580A6A01-5F6C-47E9-BFBF-9E0EBA45D64B@lurchi.franken.de>
References: <DU0PR07MB897090B712BC51017B2EEA739506A@DU0PR07MB8970.eurprd07.prod.outlook.com> <C3AC7B3F-0A80-4052-885B-F479E7CDBE9F@lurchi.franken.de> <DU0PR07MB89705080A3E66F729062849E9505A@DU0PR07MB8970.eurprd07.prod.outlook.com> <274194A8-9813-4091-91C7-0D359AC31EBE@lurchi.franken.de> <F0894847-F9D5-4A51-AC3B-44DB5122AC38@cisco.com> <DU0PR07MB89708CC2CCE437377B4EFBAE950AA@DU0PR07MB8970.eurprd07.prod.outlook.com> <CB502946-7645-4996-90A8-11B53521FCB3@lurchi.franken.de> <DU0PR07MB89706369D0FEDB653B647B1D950AA@DU0PR07MB8970.eurprd07.prod.outlook.com> <834BC539-E797-482E-8164-A1C5F8AA7B1F@lurchi.franken.de> <DU0PR07MB89705E710A4E3F9E3DFFEE98950BA@DU0PR07MB8970.eurprd07.prod.outlook.com>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/fEl2kycPm65SlTLrz_V-2enuTmU>
Subject: Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 and SA3
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 02 Aug 2023 09:21:34 -0000
> On 2. Aug 2023, at 10:28, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote: > > Hi, > Lets, add this proposed text which means that the whole LS text now reads > I would really request that people review this today. I would really like Marten as chair to be able to decide to send it no later then tomorrow Thursday so that we can meet this document deadline on Friday for SA3. Hi Magnus, thanks for adding this text. I'm fine with it. Thanks for editing the document in a timely manner! Best regards Michael > Cheers > Magnus > Title: DTLS for SCTP next steps and request for input > Response to: Reply LS on SCTP-AUTH and DTLS (S3-233355) > Source: IETF Transport Area Working Group (TSVWG) > To: 3GPP SA WG3, and 3GPP RAN WG3 > To Contacts: Peter Schmitt Peter.Schmitt@huawei.com > 3GPPLiaison@etsi.org > CC: Charles Eckel eckelcu@cisco.com > TSVWG tsvwg@ietf.org > Submitted Date: 2023-09-02Send any reply LS to: statements@ietf.org > Purpose: For action > Deadline: 2023-09-11 Action Needed > 1. Description > IETF’s Transport Working Group (TSVWG) thanks 3GPP SA3 for “Reply LS on SCTP-AUTH and DTLS” [1]. This LS is a follow up to inform 3GPP SA3 and RAN3 that TSVWG continues its work on a DTLS based security solution for SCTP that should be suitable to the needs of 3GPP for the N2, Xn, F1, and E1 interfaces. TSVWG would like to inform 3GPP how input from 3GPP and its participants can help ensure that the time plan is met. > In the development work of a replacement as reported in the previous liaison statement (Titled: Updated LS to 3GPP regarding SCTP-AUTH and DTLS) [2] the work had run into some security issues. In the continued work to address these security issues there are now two different proposals that TSVWG is attempting to choose between. The first is to continue with the previous solution with DTLS on top of SCTP [3] and relying on an updated version of SCTP-AUTH [4] to ensure the DTLS records are in order per message and no records can be injected into protected message. The second solution is to create an encryption chunk [5] that encapsulates all the payload of SCTP packets, where each SCTP packet’s content can be protected by DTLS [6] ensuring confidentiality, source authenticity, and integrity. > These two solutions appear to both to fulfill the security and functional requirements to address 3GPP’s needs as understood by TSVWG. The interpretation of the requirements is the following: > • Support message size of larger than 500 kb, which appear to be the approximate theoretical maximum size of Xn (3GPP TS 48.423) messages. Although we note that the original liaison statement from RAN3 [7] refers to SCTP’s unlimited message size. > • Enable long lived SCTP association with lifetimes of many weeks. > • Periodic mutual re-authentication of the peers. > • Periodic rekeying with forward secrecy and enable Diffie-Hellman Exchanges forcing an attacker to perform dynamic key-exfiltration after each rekeying. > • Security solution should not be vulnerable to SCTP association availability attacks based on injecting or prevention of delivery of a small number of packets by an on- or off-path attacker. > • Rekeying or re-authentication may not interrupt the SCTP using applications message delivery for any extended time, such as multiple RTTs to drain all transport messages to perform the rekeying. > We also have noted the wording in the reply liaison statement [1], “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”. The two proposed solutions have different properties when it comes to robustness (i), requirements on the DTLS implementation (ii), implementation effort in the SCTP stack (iii). There has been IPR disclosures on both proposed solutions [3] and [6], details available in links from referenced web pages. These differences are summarized in this presentation (Slides [8], Recording [9]) to the TSVWG meeting at IETF’s 117th Meeting. As many of the differences are related to implementation and requirements on the SCTP and DTLS implementation it would really help if either of the 3GPP WG’s or at least its participants would provide input to the TSVWG work on which of the solutions that it would be preferable to pursue by TSVWG. It is requested that SA3 and RAN3 would confirm if implementation possibilities in both userland and kernel implementations of SCTP are required for the solution? And if any additional concerns with implementation of either of the solutions are perceived. > TSVWG’s meeting at IETF 117 was unable to make a choice at this time on which solution to pursue due to lack of sufficient breath of input and time for participants to prepare and discuss the differences. To address this and make progress as quickly as possible an online interim meeting of TSVWG has been scheduled on the 19th of September 2023 at 16:00-18:00 CEST where this can be discussed in more depth. TSVWG would like to invite interested parties to participate in this interim meeting which is open to anyone. No registration will be required, however an IETF Datatracker account (https://datatracker.ietf.org/accounts/create/) will be needed to join the session. The session details and a join link will be available from this page:https://datatracker.ietf.org/meeting/interim-2023-tsvwg-01/session/tsvwg > In the discussion at IETF 117 TSVWG meeting, it was requested that 3GPP clarified which SCTP message sizes that a solution is required to support. In other words, are the theoretical maximum message size mentioned above relevant to be supported, or would it be sufficient that a smaller message size is supported? In general, it would be good to have SA3 and RAN3 confirm that the interpretation of the requirements is correct. TSVWG plans to make a consensus decision on its mailing list after the interim meeting. If a rough consensus is achieved on which solution to pursue, TSVWG should be able to finish its work within a year. Meaning that approved for publication by IESG specifications could be available by the end of 2024, with published RFC within one to two months. However, for this time plan to hold it is necessary that sufficient level of review is achieved. Thus, interested parties needs to be involved in the remaining process in TSVWG. > In case the requirements are not correct, or if either SA3 or RAN3 conclude that the proposed solutions’ properties are not usable for 3GPP purposes, TSVWG needs to learn what are those issues. With that input the WG could reconsider the desired properties and requirements, its participant propose alternative solutions, and discuss the proposals on the table. It will also likely delay the work significantly. 2. Actions > For both SA3 and RAN3: > > • TSVWG would like to invite interested to participate in the TSVWG Interim meeting on the 19th of September 2023 at 16:00-18:00 CEST. > > • TSVWG would like to request that any input on the choice of solution is provided in an LS by 2023-09-11. > > • TSVWG would like to request answers to questions given above and confirmation if the interpretation TSVWG has made on requirements are correct to 3GPP. > 3. Upcoming Meetings > 2023-09-17: Online interim meeting of TSVWG 16:00-18:00 CEST. Details for this meeting: https://datatracker.ietf.org/meeting/interim-2023-tsvwg-01/session/tsvwg > 2023-11-03 to 2023-11-10: IETF’s 118th Meeting in Prague. > 4. References > [1] 3GPP Liaison, “Reply LS on SCTP-AUTH and DTLS”, 3GPP doc nr: S3-233355 > [2] https://datatracker.ietf.org/liaison/1806/ > [3] https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/ > [4] https://datatracker.ietf.org/doc/draft-tuexen-tsvwg-rfc4895-bis/ > [5] https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-crypto-chunk/ > [6] https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-crypto-dtls/ > [7] https://datatracker.ietf.org/liaison/1723/ > [8] https://datatracker.ietf.org/meeting/117/materials/slides-117-tsvwg-71-dtls-in-sctp-00 > [9] https://youtu.be/HcjKkhYn08Q?t=2484
- [tsvwg] Draft Liaison statement to 3GPP RAN3 and … Magnus Westerlund
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Gorry Fairhurst
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Michael Tuexen
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Magnus Westerlund
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Michael Tuexen
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Charles Eckel (eckelcu)
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Charles Eckel (eckelcu)
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Magnus Westerlund
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Magnus Westerlund
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Michael Tuexen
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Michael Tuexen
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Michael Tuexen
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Magnus Westerlund
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Michael Tuexen
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Magnus Westerlund
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Michael Tuexen
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Zaheduzzaman Sarker
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Charles Eckel (eckelcu)
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Charles Eckel (eckelcu)
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Magnus Westerlund
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Charles Eckel (eckelcu)
- Re: [tsvwg] Draft Liaison statement to 3GPP RAN3 … Magnus Westerlund