Re: [IPsec] Discussion about solving ESP limitations with parallel processing, handling QoS classes etc.

Christian Hopps <chopps@chopps.org> Thu, 27 October 2022 11:27 UTC

Return-Path: <chopps@chopps.org>
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 E21B4C1527AF for <ipsec@ietfa.amsl.com>; Thu, 27 Oct 2022 04:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 noJ-TPHITJ6w for <ipsec@ietfa.amsl.com>; Thu, 27 Oct 2022 04:27:15 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 24826C1524D2 for <ipsec@ietf.org>; Thu, 27 Oct 2022 04:27:15 -0700 (PDT)
Received: from ja.int.chopps.org.chopps.org (172-222-113-012.res.spectrum.com [172.222.113.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 55E107D069; Thu, 27 Oct 2022 11:27:14 +0000 (UTC)
References: <20221026122119.GA2602992@gauss3.secunet.de>
User-agent: mu4e 1.8.5; emacs 28.0.92
From: Christian Hopps <chopps@chopps.org>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: ipsec@ietf.org
Date: Thu, 27 Oct 2022 07:26:16 -0400
In-reply-to: <20221026122119.GA2602992@gauss3.secunet.de>
Message-ID: <m2tu3pcxri.fsf@ja.int.chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Nmjt5RJ5Gd9PrpOZBWKa8CrppY4>
Subject: Re: [IPsec] Discussion about solving ESP limitations with parallel processing, handling QoS classes etc.
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: Thu, 27 Oct 2022 11:27:19 -0000

I'm interested and would attend.

Thanks,
Chris.

Steffen Klassert <steffen.klassert@secunet.com> writes:

> Hi,
>
> over the last years, quite some work was done from different parties
> to overcome some limitations of ESP to handle parallel datapaths,
> QoS classes etc.
>
> Chronologically ordered, we have:
>
> November 2019:
>
> https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-multiple-child-sa-00
>
> That was replaced in November 2020 by:
>
> htpps://datatracker.ietf.org/doc/draft-pwouters-multi-sa-performance/
>
> At IETF 108 in July 2020 there was this proposal:
>
> https://datatracker.ietf.org/meeting/108/materials/slides-108-ipsecme-proposed-improvements-to-esp-01
>
> October 2022:
>
> https://www.ietf.org/archive/id/draft-ponchon-ipsecme-anti-replay-subspaces-00.txt
>
> Aditionally, Google published the PSP Security Protocol (PSP) for
> datacenters in April 2022:
>
> https://github.com/google/psp
>
> All these proposals try to solve related problems in different ways.
> They all have pros and cons, but the number of proposals shows that
> there is a real need to solve these problems better sooner than later.
>
> So instead of creating even more proposals, we maybe should take a
> step back and try to do a clear problem statement. Based on that
> we then can rethink about possible solutions.
>
> The next possibiltiy to sit together for an 'in person' discussion
> would be at the IETF Meeting in London. Is there anyone interested
> in a sidemeeting about that topic?
>
> Steffen
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec