IETF Logo Mail Archive

Re: [IPsec] Questions for draft-ponchon-ipsecme-anti-replay-subspaces

Michael Rossberg <michael.rossberg@tu-ilmenau.de> Mon, 21 August 2023 07:13 UTC

Return-Path: <michael.rossberg@tu-ilmenau.de>
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 DF06EC15107A; Mon, 21 Aug 2023 00:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5FVpm3flhIIh; Mon, 21 Aug 2023 00:13:18 -0700 (PDT)
Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1CBC14F736; Mon, 21 Aug 2023 00:13:17 -0700 (PDT)
Received: from smtpclient.apple (olous.prakinf.tu-ilmenau.de [141.24.212.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id 44FEE580083; Mon, 21 Aug 2023 09:10:41 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_52161D31-01B6-4DED-9B1A-3F7EFC12188A"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\))
From: Michael Rossberg <michael.rossberg@tu-ilmenau.de>
In-Reply-To: <5b9bbcd1-58fa-d6aa-04b9-f96142ecea1e@nohats.ca>
Date: Mon, 21 Aug 2023 09:10:41 +0200
Cc: "draft-ponchon-ipsecme-anti-replay-subspaces.authors@ietf.org" <draft-ponchon-ipsecme-anti-replay-subspaces.authors@ietf.org>, "ipsec@ietf.org" <ipsec@ietf.org>
Message-Id: <AF243040-90AE-471B-B6D4-CF815680AAB0@tu-ilmenau.de>
References: <MW3PR11MB4697F948E5F548FE4A1E6590AB17A@MW3PR11MB4697.namprd11.prod.outlook.com> <DM6PR11MB453129152AC683BA4AE8464FCB17A@DM6PR11MB4531.namprd11.prod.outlook.com> <MW3PR11MB46974F028FF777DBB7549E80AB17A@MW3PR11MB4697.namprd11.prod.outlook.com> <5b9bbcd1-58fa-d6aa-04b9-f96142ecea1e@nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3696.120.41.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/hwT0oARYRB2-JclDEjvlaqzTpR4>
Subject: Re: [IPsec] Questions for draft-ponchon-ipsecme-anti-replay-subspaces
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 Aug 2023 07:13:22 -0000

> On 14. Aug 2023, at 20:45, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Mon, 14 Aug 2023, Aseem Choudhary wrote:
> 
>> 1. Yes, you're correct there is still reordering potentially happening between the endpoints of the tunnel. However, the intention
>> behind using the subspace is to limit the potential reordering of packets at the tunnel endpoints. By assigning packets to specific
>> subspaces based on factors such as CPU core or QoS, the aim is to manage and mitigate the reordering within each subspace, thereby
>> improving the utilisation of multiple cores and QoS classes at the endpoint. The reordering happening in between the endpoint is
>> less easily controllable and just like with using an SA today, would be handled by the replay window of each subspaces but they
>> don’t need to be very big.
> 
> But if you already bind subspaces to a CPU/core, why not just a whole IPsec SA per core :-)

You can find some reasons in https://datatracker.ietf.org/doc/draft-mrossberg-ipsecme-multiple-sequence-counters/. For me the largest advantage
is having a simpler failure semantic (either all sub-SAs fail or none), lower overhead and the clear strategy of SPI allocation, which eases NIC steering.

Michael

v2.23.0 | Report a Bug | By Email