Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
Valery Smyslov <smyslov.ietf@gmail.com> Tue, 14 November 2023 08:53 UTC
Return-Path: <smyslov.ietf@gmail.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 248EAC151076 for <ipsec@ietfa.amsl.com>; Tue, 14 Nov 2023 00:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 80H55ByWzTep for <ipsec@ietfa.amsl.com>; Tue, 14 Nov 2023 00:53:03 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 E3A5DC15107F for <ipsec@ietf.org>; Tue, 14 Nov 2023 00:53:02 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2c6b30aca06so70695271fa.3 for <ipsec@ietf.org>; Tue, 14 Nov 2023 00:53:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699951981; x=1700556781; darn=ietf.org; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:to:from :from:to:cc:subject:date:message-id:reply-to; bh=+bsdktTYu7Xtk1mGDOCfFIRikcIhvLAklIQt16pc0rA=; b=g2w9qweo3G2D6RKD7tLK+mUaGxxelYOQGMK5UJ38woVWavfF0nFSqVkfXsKWlIfpIs T4qNNOyzF5mp1Dx0W9dW7ucAm6SI9IqQrJ9nefUe+2TSfo/0uB6296zbAoBqxosF0Aiu NuYoAiO8JjC8dloZsRJTUZ7A939rjt+z9ZotiqbkZTgkwPjhbeqrvuZtbWF7aphSXTAU B844JY9Cm04FDiLKGJQ3YNGi6J3p1E9QHMhn5RYV7l47jenhCMOi0E+l9rqAQqS1HKnb tyL08nDh0Zhso4vKjGjkXCIjYrhjv7ESiNaYjW3dd7E4ufyLyeODEjJTGVOjb5oYnyyd YAAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699951981; x=1700556781; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+bsdktTYu7Xtk1mGDOCfFIRikcIhvLAklIQt16pc0rA=; b=L2GfL0jvz5dQm6Z76bZystZfXJuo7v0xzT1lU7eiIZ8MazYu9H1wPMdIqivsWMo4Te 66xHeoUFLPUgpeOJfJR+HvOcF5sOUBASRKZp33KWrruFnGFpnoxbkUBUL+hLtppPHDif 0pTmd1qal6TFVWae15cYRNlHKMudXQ6d/bOWTjHWh6vlv+ejmYjjJjw6zz6JESAtZ7lL zDlm5DH3eJWihXcqf3J4wGt1niJ4C56vEZVymMAddVCqLKoDD6ULAepIr+BFAmLBt+p5 zq56Gd2kWG3sBj3YnByQtqkYSav6q+uZ0M6K6rxM2Vo/pzRQrWCSp1THHWkEJaHdzelL hqDQ==
X-Gm-Message-State: AOJu0Yx6C68xgiCaR36dB+P29sAPgWQvjC1IR8thMNGvwRHSy2/Im1ii SHTjtOPKaL4ou+WIi6GaTBqaShW7OHQ=
X-Google-Smtp-Source: AGHT+IFhHVvlfRHm0/Hj5dgaDncjZCjfRUh2ThccYaiAj6iYW+yDs8hi4NjgXOC9VkYnvTNibEDHHg==
X-Received: by 2002:a05:651c:2c4:b0:2c5:f8e:35cf with SMTP id f4-20020a05651c02c400b002c50f8e35cfmr1132455ljo.20.1699951980222; Tue, 14 Nov 2023 00:53:00 -0800 (PST)
Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id r8-20020a2e8e28000000b002b47a15a2eesm1260770ljk.45.2023.11.14.00.52.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2023 00:52:59 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tero Kivinen' <kivinen@iki.fi>, ipsec@ietf.org
References: <25912.18413.748999.323996@fireball.acr.fi>
In-Reply-To: <25912.18413.748999.323996@fireball.acr.fi>
Date: Tue, 14 Nov 2023 11:53:01 +0300
Message-ID: <04b101da16d7$f9421c10$ebc65430$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHKU10JL1+d2T+4V+QjI0HzVVzOT7CXyiUg
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/88YoOq5KKt3d0dtei_8Pu4EVH3k>
Subject: Re: [IPsec] WGLC of 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: Tue, 14 Nov 2023 08:53:08 -0000
Hi, I support publication of this draft. I'm glad authors took my points into consideration while preparing the latest version. I do have some comments though. 1. Section 1 IKEv2 [RFC7296] already allows installing multiple Child SAs with identical Traffic Selectors, but it offers no method to indicate that the additional Child SA is being requested for performance increase reasons and is restricted to some resource (queue or CPU). Without this indication, the peer might not accept multi Child SAs with identical Traffic Selectors and might delete one of the Child SAs it considered an unwanted duplicate. There is some inconsistency here. You first say that IKEv2 allows creating multiple identical Child SAs and then say that implementations would delete them as unwanted duplicates. Clearly these implementations violate RFC 7296, and we don't consider broken implementations, do we? :-) I suggest to remove the last sentence, or to add a clarification. 2. Section 2 There are a number of practical reasons why most Implementations have to limit a Child SA to only one specific hardware resource, but a key limitation is that sharing the crypto state, counters and sequence numbers between multiple CPUs is not feasible without a significant performance penalty. Shouldn't it be clarified, that the performance problems arise if you use an SA by several CPUs at the same time? I don't think there are problems if you use the SA by several CPUs at different time. Consider you have an SA with a traffic one packet per hour. Each time it is processed up by a different CPU, then the resulted state is stored in the shared memory. So, perhaps s/one specific hardware resource/one specific hardware resource at any given time 3. Section 3 If multiple Child SAs with the same Traffic Selectors are desired, the initiator will add the SA_RESOURCE_INFO notify payload to the Exchange negotiating the Child SA (eg IKE_AUTH or CREATE_CHILD_SA). If this initial Child SA will be tied to a specific resource, it MAY indicate this by including an identifier in the Notification Data. A responder that is willing to have multple Child SAs for the same Traffic Selectors will respond by also adding the SA_RESOURCE_INFO notify payload in which it MAY add a non-zero notify data payload. This text is a bit inconsistent with IKEv2 specification. In my reading the text implies that unless you exchange SA_RESOURCE_INFO, you cannot initiate multiple SAs with same selector, which is wrong - you can do it at any time if you follow RFC 7296. Only if you want to follow this draft (i.e. - associate each Child SA with some resource, and be able to limit their number with TS_MAX_QUEUE) you have to negotiate. I think that this subtle thing should be expressed more accurately. 4. Section 3 These resource- specific Child SAs MUST be negotiated with identical Child SA properties that were negotiated for the initial Child SA. This includes cryptographic algorithms, Traffic Selectors, Mode (e.g. transport mode), compression usage, etc. However, each Child SA does have its own keying material that is individually derived according to the regular IKEv2 process. I think that MUST is over-restrictive if we talk about crypto algorithms. For crypto algorithms herhaps something along the lines: SHOULD be negotiated with the same crypto algorithms; if they differ, then they MUST provide identical level of protection. (I agree that Mode and Traffic Selectors MUST be the same, not sure about compression). 5. Section 3 During the CREATE_CHILD_SA rekey for the Child SA, the SA_RESOURCE_INFO notification MAY be included, but regardless of whether or not it is included, the rekeyed Child SA MUST be bound to the same resource(s) as the Child SA that is being rekeyed. Isn't binding a local matter? Doesn't peer bother to what resource you bound your end of an SA? Then why is there this MUST? What happens if I bound new SA to a different CPU - peer never know this, so how it will check that you follow this MUST? I think that instead of this requirement there should be just a recommendation for implementers (with no BCP14 language). 6. Section 4 A simple distribution could be to install one additional Child SA on each CPU. An implementation MAY ensure that one Child SA can be used by all CPUs ... I believe it should be "can" instead of "MAY", since it is a local matter. 7. Section 4 When the number of queue or CPU resources are different between the peers, the peer with the least amount of resources MAY decide to not install a second outbound Child SA for the same resource as it will never use it to send traffic. Again, I think it should be "can" instead of "MAY", since it is a local matter. 8. Section 4 If per-CPU SADB_ACQUIRE messages are implemented (see Section 6), the Traffic Selector (TSi) entry containing the information of the trigger packet SHOULD be included in the TS set. This information MAY be used by the peer to select the most optimal target CPU to install the additional Child SA on. The conditional part of the first sentence is too implementation specific: the SADB_REQUIRE is specific to PF_KEYv2 API and not all implementations use it (and this specification doesn't depend on it). Just replace it with some more generic text, like "dynamic creating of per-CPU Child SAs" providing a single a reference to an SADB_ACQUIRE as an example. This is true for Section 6 too, where SADB_ACQUIRE should only be used as an example and not as prescribed mechanism. Then, this SHOULD is already specified in RFC 7296, Section 2.9: To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request. Why repeat this requirement there? Perhaps just reference Section 2.9 of RFC 7296? And finally, "MAY" should be "can", since it is a local matter of responder. 9. Section 5.1, Section 5.2 * Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0. * SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0. What "MUST be ignored if not 0"? The value of the field or the notify message itself? If the non-zero value must be ignored, then why specify that it MUST be 0? And how the receiver should interpret the notify message in this case? I think there is an inconsistency. I suggest to remove the second MUSTs, thus the receiver will reject the notify if it is has non-zero protocol and SPI, as it should do with any other such notifications. 10. Section 5.1 * Optional Payload Data. This value MAY be set to convey the local identity of the resource. The value SHOULD be a unique identifier and the peer SHOULD only use it for debugging purposes. This is an optional field used for debugging purposes. Why any BCP14 language here? And if this is a value, associated with a resource, then how it may be unique in a situation when peer associates several SAs with a single resource (e.g. if it has fewer resources then its peer, but doesn't mind creating as many SAs as its peer wants)? Another consideration - if it is used only for debugging, and its format is not specified, then it is meaningful only for the peer that sends it and thus it should be an opaque blob with no defined semantics (like association with a resource) and no requirements on its value. 11. Section 6 As I pointed out before, this section is too implementation-specific. I think that SADB_ACQUIRE should be mentioned only as an example and the operational considerations should be provided in API-neutral language. 12. Section 6 Implementations supporting per-CPU SAs SHOULD extend their local SPD selector, and the mechanism of on-demand negotiation that is triggered by traffic to include a CPU (or queue) identifier in their SADB_ACQUIRE message from the SPD to the IKE daemon. I think that using BCP14 language is not justified here (it is not protocol behavior). It should be "should" instead. 13. Section 6 And bringing the deleted per-CPU Child SA up again immediately after receiving the Delete Notify might cause an infinite loop between the peers. Another issue of not bringing up all its per-CPU Child SAs is that if the peer acts similarly, the two peers might end up with only the first Child SA without ever activating any per-CPU Child SAs. I think more should be said about this situation and how to avoid it. Perhaps advising such implementations to not delete per-CPU Child SAs if they have not been rekeyed. Then the second case will never happen. As for the first case, perhaps advise all implementations to not delete SAs immediately once they are created... 14. Section 6 Implementations might support dynamically moving a per-CPU Child SAs from one CPU to another CPU. If this method is supported, implementations must be careful to move both the inbound and outbound SAs. If this is done "on the fly", then the data in SA_RESOURCE_INFO (if it is provided) would become invalid, killing its usefulness for debugging. If it is done as a result of SA rekey, then it contradicts to the last sentence in Section 3 (well, I already suggested to remove it, see comment 5). 15. Section 6 If this method is supported, implementations must be careful to move both the inbound and outbound SAs. Is it justified? Why inbound and outbound SAs cannot be bound to a different resources? 16. Section 6 If the IPsec endpoint is a gateway, it can move the inbound SA and outbound SA independently from each other. This contradict to the previous sentence. 17. Section 6 If the IPsec endpoint is the same host responsible for generating the traffic, the inbound and outbound SAs SHOULD remain as a pair on the same CPU. Using BCP14 language is not justified here (it is a local matter and not a protocol behavior, so this is just a recommendation for implementers). And some justification for this recommendation would be helpful. 18. Section 6 If a host previously skipped installing an outbound SA because it would be an unused duplicate outbound SA, it will have to create and add the previously skipped outbound SA to the SAD with the new CPU ID. This sentence unclear for me. First, I fail to understand why this is needed. Then, I fail to understand how to do this, in particular - how to get SPIs and keying material of the skipped (i.e. deleted) SA. I believe this piece of text should be elaborated. 19. Section 6 The inbound SA may not have CPU ID in the SAD. I fail to understand what this sentence is related to? 20. Section 6 To support this, the IKE software might have to hold on to the key material longer than it normally would, as it might actively attempt to destroy key material from memory that the IKE daemon no longer needs access to. In my opinion this requirement is problematic. It highly depends on concrete architecture. In some cases IKE daemon has never access to the Child SA keying material - it only provides values for its generating, which is done in a HSM. And in this case IKE daemon has no control over this material (and it never needs to have an access to it or control over it). So, I think that this should be elaborated, in particular justifying why do you need to re-create outbound SA which you have already deemed unneeded. 21. Section 6 An implementation that does not accept any further resource specific Child SAs MUST NOT return the NO_ADDITIONAL_SAS error because this can be interpreted by the peer that no other Child SAs with different TSi/TSr are allowed either. Instead, it MUST return TS_MAX_QUEUE. I wonder whether TS_MAX_QUEUE is a permanent or temporary error. 22. Section 7 Similar to how an implementation should limit the number of half-open SAs to limit the impact of a denial of service attack, an implementation SHOULD limit the maximum number of additional Child SAs allowed per unique TSi/TSr. In section 6 you said: Peers SHOULD be lenient with the maximum number of Child SAs they allow for a given TSi/TSr combination to account for corner cases. and later As additional Child SAs consume little additional overhead, ... So, some wordsmithing to make these pieces of text in concert would be helpful. 23. Section 7 This trust relationship is usually not present for the Remote Access VPN type deployments, and allowing per-CPU Child SA's is NOT RECOMMENDED in these scenarios. Therefor, it is also NOT RECOMMENDED to allow per-CPU Child SAs per default. Typo: s/Therefor/Therefore In general, I don't think that this statement is universally true. If it is a corporate Remote Access scenario, then clients are administered by the same people as gateways. Thus, I don't think that advising not use this extension in Remote Access scenario due to the lack of trust to clients is always justified. 24. Section 7 The SA_RESOURCE_INFO notify contains an optional data payload that can be used by the peer to identify the Child SA belonging to a specific resource. The notify data SHOULD NOT be an identier that can be used to gain information about the hardware. For example, using the CPU number itself as identier might give an attacker knowledge which packets are handled by which CPU ID and it might optimize a brute force attack against the system. Isn't it protected by IKE SA? I believe this is only possible with MitM attack (only initiator is affected) or when CRQC is used with RFC 8784 scenario for the initial SA. In the first case the SA won't be created. The second case is currently unrealistic. Am I missing something? If not, then I suggest to just describe this threat giving no advices (i.e. remove SHOULD NOT), since it seems to be theoretical threat. Just let the implementers know that this is possible. Typo: s/identier/identifier (2 instances) 25. Section 9 This document defines two new IKEv2 Notify Message Type payloads for the IANA "IKEv2 Notify Message Types - Status Types" registry. This is a leftover from the previous version of the draft - the current version defines only one status type notification. 26. Section 10 Why RFC2367 is a normative reference? Why one cannot implement this specification without using PF_KEY? Actually, this seems to be already done by Linux XFRM. From Section 8.1: Coverage: Implements a general Child SA and per-CPU Child SAs. It only supports the NETLINK API. The PFKEYv2 API is not supported. Regards, Valery. > This will start three week working group laste call for > draft-ietf-ipsecme-multi-sa-performance. The working group last call > will end at 2023-11-15. > > Please review the document and send comments to the list if you think > it is ready for publication. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec
- [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-perfo… Tero Kivinen
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Christian Hopps
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Yoav Nir
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Michael Richardson
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Daniel Xu
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Sahana Prasad
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Daniel Migault
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Yoav Nir
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Valery Smyslov
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Michael Richardson
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Yoav Nir
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Paul Wouters
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Paul Wouters
- Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-p… Valery Smyslov