[IPsec] Virtual interim about re-designing ESP?

Steffen Klassert <steffen.klassert@secunet.com> Mon, 21 November 2022 12:47 UTC

Return-Path: <Steffen.Klassert@secunet.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36020C1524DC for <ipsec@ietfa.amsl.com>; Mon, 21 Nov 2022 04:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 U9yYberx-dSm for <ipsec@ietfa.amsl.com>; Mon, 21 Nov 2022 04:47:33 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (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 67D48C152580 for <ipsec@ietf.org>; Mon, 21 Nov 2022 04:47:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 93CEE20185 for <ipsec@ietf.org>; Mon, 21 Nov 2022 13:47:15 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOUE33wtndTT for <ipsec@ietf.org>; Mon, 21 Nov 2022 13:47:14 +0100 (CET)
Received: from mailout2.secunet.com (mailout2.secunet.com [62.96.220.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id B9A4620068 for <ipsec@ietf.org>; Mon, 21 Nov 2022 13:47:14 +0100 (CET)
Received: from cas-essen-01.secunet.de (unknown [10.53.40.201]) by mailout2.secunet.com (Postfix) with ESMTP id ABA3F80004A for <ipsec@ietf.org>; Mon, 21 Nov 2022 13:47:14 +0100 (CET)
Received: from mbx-essen-01.secunet.de (10.53.40.197) by cas-essen-01.secunet.de (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 21 Nov 2022 13:47:14 +0100
Received: from gauss2.secunet.de (10.182.7.193) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 21 Nov 2022 13:47:14 +0100
Received: by gauss2.secunet.de (Postfix, from userid 1000) id 2908231829DB; Mon, 21 Nov 2022 13:47:14 +0100 (CET)
Date: Mon, 21 Nov 2022 13:47:14 +0100
From: Steffen Klassert <steffen.klassert@secunet.com>
To: ipsec@ietf.org
Message-ID: <20221121124714.GA704954@gauss3.secunet.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-ClientProxiedBy: cas-essen-02.secunet.de (10.53.40.202) To mbx-essen-01.secunet.de (10.53.40.197)
X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/6awUHs6J_jVHVcGpuNLrLQsOpHY>
Subject: [IPsec] Virtual interim about re-designing ESP?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2022 12:47:38 -0000

Hi,

at the last working group meeting in London, it was quite
some interest to work on a re-design of ESP to make it fit
to the multi-cpu case, QoS classes, HW offloads etc.

We already have some proposals that try to solve related
problems in different ways:

IETF 108:

https://datatracker.ietf.org/meeting/108/materials/slides-108-ipsecme-proposed-improvements-to-esp-01

IETF 115:

https://www.ietf.org/archive/id/draft-ponchon-ipsecme-anti-replay-subspaces-00.txt

The Google PSP Security Protocol (PSP) is another new 'ESP like'
protocol. There is some interest to standardize PSP, so the issues
that are solved there should also be considered when designing a new
ESP version. Most concepts that are used in PSP are taken from IPsec
ESP, so IMO this should be integrated into the IPsec protocol suite.

Is there interest in doing a virtual interim to discuss an ESP re-design?

First things to clarify would be:

- Does the working group agree to the need of an ESP re-design?

- Who is interested to work on that?

- What are the problems to solve?

- How should the problems be solved?

Please let me know if there is interest,

Steffen