[IPsec] Shepherd review of the draft-ietf-ipsecme-multi-sa-performance
Tero Kivinen <kivinen@iki.fi> Thu, 14 March 2024 17:43 UTC
Return-Path: <kivinen@iki.fi>
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 81E45C14F60A; Thu, 14 Mar 2024 10:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
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 xIUuFaT4z2R9; Thu, 14 Mar 2024 10:43:17 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 EBB11C14F5F7; Thu, 14 Mar 2024 10:43:12 -0700 (PDT)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 4TwZV644L4zyPB; Thu, 14 Mar 2024 19:43:10 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1710438190; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Zh/p5UU3PM4mTDxm0e6I4yxMHcwVsMK2Z8L3c1LSP8Q=; b=azjip4MIW1C4XxW17NK0R333BrVgMLfTy925cIhTGuz5q0/qmzZtPqTEqqj9hXCIAw0Qzf 8ua2xuFCE9etg6NFVQ3wG+M+wCyJxIbrkFRdBvEXVjxRB8f7QQQ5nuMs9FCYH/gEw10tbq Q/dAcq1zs5ERXyX6C8CQcY3FTun/hPE=
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1710438190; a=rsa-sha256; cv=none; b=ePT6y24tu9IrcNy4BQ2omNGrTjTfB9dxZGHLWLFRGt6+sNxVVh/v0P5LSpHC5zzX6TqIdv Iwnx3CMm6hbo2myCZ8C+LtnV3BDYx4sgGBeDOQO6+xelLkQqXSsb00OvTEm+FeKlfprMmd ToBgYsi0qjAjF8Beuu+z8cEXTM3qMGc=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1710438190; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Zh/p5UU3PM4mTDxm0e6I4yxMHcwVsMK2Z8L3c1LSP8Q=; b=aHt/TJ3CKzf4ZUuwkV/gZQCbvzNIZGjBi9NLltvzUkYnFisosq7gy6wa8y3QpMbG2oN3jf 9gIjacUAD3AzJVrS3IJHh3GQo/I24XE32WmdiMkjf0mBuxA1TBjKo6kKvyIl/9wzUznWr+ 4CiVbPIs9wqGPk9LFlvcQS7+Kba+Fw8=
Received: by fireball.acr.fi (Postfix, from userid 15204) id DBBE825C12A7; Thu, 14 Mar 2024 19:43:08 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <26099.14124.656237.213001@fireball.acr.fi>
Date: Thu, 14 Mar 2024 19:43:08 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: draft-ietf-ipsecme-multi-sa-performance@ietf.org
CC: ipsec@ietf.org
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 33 min
X-Total-Time: 41 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/e0n0I1OkKWixc0dESB09O0EVq5g>
Subject: [IPsec] Shepherd review of the draft-ietf-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, 14 Mar 2024 17:43:18 -0000
In section 1 Introduction: While this could be (partially) mitigated by setting up multiple narrowed Child SAs, for example using Populate From Packet (PFP) as specified in [RFC4301], this IPsec feature is not widely implemented. I think it would be better to give better reason why PFP is not that useful, for example because it could cause way too many Child SAs, and/or way too few Child SAs as the number of Child SAs would be depending on the traffic flow patterns. I.e., if you have all traffic in one TCP/IP session (for example running backup), then you will get only one Child SA for all traffic. On the other hand if you have lots of separate short lived TCP connections (like web browser opening multiple connections to different web servers ect), you would have lots of Child SAs, which would be useless after short while. -- In section 1 change: "as specified in [RFC4301]" with "as specifeid in IPsec Architecture [RFC4301]" -- Add section 1.2 Terminology where you say you use terms Child SA, TSi, TSr, Notification Data, Traffic Selectors, CREATE_CHILD_SA, Configuration Payloads, etc defined in the RFC7296. Expand the list to include all terms used from RFC7296. -- Section 2 typo: s/Implementations/implementations/ -- Section 3 typo: s/multple/multiple/ Also you are using Notification Data (as specified n RFC7296), but then in the end of 1st paragraph you use "notify data payload". Changing those to be consistent would be good. -- In section 4 change twice: in [RFC7296] Section 2.9. with in IKEv2 [RFC7296] Section 2.9. also change As per RFC 7296, with As per IKEv2, (the IKEv2 rfc might not stay 7296 forever :) -- In section 5 say that the Notify Payload format is defined in IKEv2 [RFC7296] section 3.10, and are copied only here to make this document easier to read. -- In section 5.1 you say that Protocol id MUST contain either 2 for AH and 3 for ESP, but on the RFC7296 says that "If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt." and as this notify is sent with empty SPI field, then the Protocol ID field MUST be 0 also. -- In section 5.1 add text saying that SPI Size MUST be zero. -- In section 5.1 fix s/opague/opaque/ twice. -- In section 6 there is text saying: If the IKEv2 extension defined in this document is negotiated with the peer, an implementation which does not support receiving per-CPU packet trigger messages MAY initiate all its Child SAs immediately upon receiving the (only) packet trigger message it will receive from the IPsec stack. On the other hand there is no negotiation of the this extension. What is this text trying to say? Perhaps simply remove change to say "If an implementation does not support ... it MAY ..." -- Section 9 the correct heading for the IANA registries 2nd column are Notify Messages - Status Types and Notify Messages - Error Types Currently the figure 2 is using status type header and even that does not match iana registry. -- kivinen@iki.fi
- [IPsec] Shepherd review of the draft-ietf-ipsecme… Tero Kivinen