Re: [IPsec] IPsecME WG Adoption call for draft-pwouters-ipsecme-multi-sa-performance

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 10 November 2022 17:20 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 1A0F3C1524A0 for <ipsec@ietfa.amsl.com>; Thu, 10 Nov 2022 09:20:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 7YliZoM56HcS for <ipsec@ietfa.amsl.com>; Thu, 10 Nov 2022 09:20:00 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39934C14F744 for <ipsec@ietf.org>; Thu, 10 Nov 2022 09:19:59 -0800 (PST)
Received: from dyas.sandelman.ca (unknown [IPv6:2001:67c:370:1998:28c9:2b4:698f:aa9d]) by relay.sandelman.ca (Postfix) with ESMTPS id 2C9691F4AF; Thu, 10 Nov 2022 17:19:58 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 64383A0A7D; Thu, 10 Nov 2022 17:19:27 +0000 (GMT)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 61170A0A74; Thu, 10 Nov 2022 17:19:27 +0000 (GMT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Paul Wouters <paul@nohats.ca>, "Pierre Pfister (ppfister)" <ppfister=40cisco.com@dmarc.ietf.org>, Tero Kivinen <kivinen@iki.fi>, "ipsec@ietf.org" <ipsec@ietf.org>
In-reply-to: <20a6e992-49e8-ae88-8d8-35eefd4ffbc@nohats.ca>
References: <25451.58560.690380.833165@fireball.acr.fi> <F82E680F-DA37-4798-87C7-652C3FDF0D82@cisco.com> <20a6e992-49e8-ae88-8d8-35eefd4ffbc@nohats.ca>
Comments: In-reply-to Paul Wouters <paul@nohats.ca> message dated "Thu, 10 Nov 2022 10:26:31 -0500."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 10 Nov 2022 17:19:27 +0000
Message-ID: <569771.1668100767@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/ilgh8k6NEqo0_bQwa22y8Pn_5gQ>
Subject: Re: [IPsec] IPsecME WG Adoption call for draft-pwouters-ipsecme-multi-sa-performance
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, 10 Nov 2022 17:20:01 -0000

Paul Wouters <paul@nohats.ca> wrote:
    > I think this solution is such a small solution and already has running
    > code, that I would prefer the WG to quickly move this on, while also
    > beginning a separate discussion on how to do various different scaling

I think that the multi-SA stuff should be really low impact to IKEv2, and we
should just publish it.
This would be the *interoperable* solution.

    > issues (and multi-cpu) in another way, eg by trying to work on an ESPv4
    > version. But I would be sad if that work, which I expect will take some
    > time, would delay this draft.

ESPv4 is a really good idea.
It will require some experimentation... i.e running code.
To that extent, we might need a WG document (not RFC) that explains how to do
these experiments in a way that does not get in the way of an actual rough
consensus.   The experimental (non-interoperable) solutions might involve
having actual hardware, so it may not as trivial as just changing a few lines
of code.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-