< draft-pwouters-ipsecme-multi-sa-performance-01.txt		draft-pwouters-ipsecme-multi-sa-performance-02.txt >
	Network A. Antony		Network A. Antony
	Internet-Draft secunet		Internet-Draft secunet
	Intended status: Standards Track T. Brunner		Intended status: Standards Track T. Brunner
	Expires: 1 April 2022 codelabs		Expires: 16 April 2022 codelabs
	S. Klassert		S. Klassert
	secunet		secunet
	P. Wouters		P. Wouters
	Aiven		Aiven
	28 September 2021		13 October 2021
	IKEv2 support for per-queue Child SAs		IKEv2 support for per-queue Child SAs
	draft-pwouters-ipsecme-multi-sa-performance-01		draft-pwouters-ipsecme-multi-sa-performance-02
	Abstract		Abstract
	This document defines two Notify Message Type Payloads for the		This document defines three Notify Message Type Payloads for the
	Internet Key Exchange Protocol Version 2 (IKEv2) indicating support		Internet Key Exchange Protocol Version 2 (IKEv2) indicating support
	for the negotiation of multiple identical Child SAs to optimize		for the negotiation of multiple identical Child SAs to optimize
	performance.		performance.
	The CPU_QUEUES notification indicates support for multiple queues or		The CPU_QUEUES notification indicates support for multiple queues or
	CPUs. The CPU_QUEUE_INFO notification are used to confirm and		CPUs. The CPU_QUEUE_INFO notification is used to confirm and
	optionally convey information about the specific queue, such as QoS		optionally convey information about the specific queue. The
	level.		TS_MAX_QUEUE notify conveys that the peer is unwilling to create more
			additional Child SAs for this particular Traffic Selector set.
	Using multiple identical Child SAs has the benefit that each stream		Using multiple identical Child SAs has the benefit that each stream
	has its own Sequence Number Counter, ensuring that CPUs don't have to		has its own Sequence Number Counter, ensuring that CPUs don't have to
	synchronize their crypto state or disable their packet replay		synchronize their crypto state or disable their packet replay
	protection.		protection.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 49 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 1 April 2022.		This Internet-Draft will expire on 16 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Performance bottlenecks . . . . . . . . . . . . . . . . . . . 3		2. Performance bottlenecks . . . . . . . . . . . . . . . . . . . 3
	3. Negotiation of CPU specific Child SAs . . . . . . . . . . . . 3		3. Negotiation of CPU specific Child SAs . . . . . . . . . . . . 3
	4. Implementation Considerations . . . . . . . . . . . . . . . . 5		4. Implementation Considerations . . . . . . . . . . . . . . . . 5
	5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 7		5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. CPU_QUEUES Notify Message Payload . . . . . . . . . . . . 7		5.1. CPU_QUEUES Notify Status Message Payload . . . . . . . . 6
	5.2. CPU_QUEUE_INFO Notify Message Payload . . . . . . . . . . 7		5.2. CPU_QUEUE_INFO Notify Status Message Payload . . . . . . 7
			5.3. TS_MAX_QUEUE Notify Error Message Payload . . . . . . . . 7
	6. Operational Considerations . . . . . . . . . . . . . . . . . 8		6. Operational Considerations . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Implementation Status . . . . . . . . . . . . . . . . . . . . 9		8. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
	8.1. Linux XFRM . . . . . . . . . . . . . . . . . . . . . . . 10		8.1. Linux XFRM . . . . . . . . . . . . . . . . . . . . . . . 9
	8.2. Libreswan . . . . . . . . . . . . . . . . . . . . . . . . 10		8.2. Libreswan . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.3. strongSwan . . . . . . . . . . . . . . . . . . . . . . . 11		8.3. strongSwan . . . . . . . . . . . . . . . . . . . . . . . 11
	8.4. iproute2 . . . . . . . . . . . . . . . . . . . . . . . . 11		8.4. iproute2 . . . . . . . . . . . . . . . . . . . . . . . . 11
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	IPsec implementations are currently limited to using one queue or CPU		IPsec implementations are currently limited to using one queue or CPU
	per Child SA. The result is that a machine with many queues/CPUs is		per Child SA. The result is that a machine with many queues/CPUs is
	limited to only using one of these per Child SA. This severely		limited to only using one of these per Child SA. This severely
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	for this, but a key limitation is that sharing the crypto state,		for this, but a key limitation is that sharing the crypto state,
	counters and sequence numbers between multiple CPUs is not feasible		counters and sequence numbers between multiple CPUs is not feasible
	without a significant performance penalty. There is a need to		without a significant performance penalty. There is a need to
	negotiate and establish multiple Child SAs with identical TSi/TSr on		negotiate and establish multiple Child SAs with identical TSi/TSr on
	a per-queue or per-CPU basis.		a per-queue or per-CPU basis.
	3. Negotiation of CPU specific Child SAs		3. Negotiation of CPU specific Child SAs
	When negotiating CPU specific Child SAs, the first SA negotiated		When negotiating CPU specific Child SAs, the first SA negotiated
	either in an IKE_AUTH exchange or CREATE_CHILD_SA is called Fallback		either in an IKE_AUTH exchange or CREATE_CHILD_SA is called Fallback
	SA. This Child SA is similar to a regular Cgild SA in that it is not		SA. This Child SA is similar to a regular Child SA in that it is not
	bound to a single CPU. This Fallback Child SA (or its rekeyed		bound to a single CPU. This Fallback Child SA (or its rekeyed
	successors) MUST remain active for the lifetime of the IPsec session		successors) MUST remain active for the lifetime of the IPsec session
	to ensure that there is always a Child SA that can be selected to		to ensure that there is always a Child SA that can be selected to
	send traffic over, in case a per-resource Child SA is not available.		send traffic over, in case a per-resource Child SA is not available.
	Additional Child SAs are installed bound to a specific CPU. These		Additional Child SAs are installed bound to a specific CPU. These
	Child SAs are responsible for the bulk of the traffic.		Child SAs are responsible for the bulk of the traffic.
	The CPU_QUEUES notification payload is sent in the IKE_AUTH or		The CPU_QUEUES notification payload is sent in the IKE_AUTH or
	CREATE_CHILD_SA Exchange indicating the negotiated Child SA is a		CREATE_CHILD_SA Exchange indicating the negotiated Child SA is a
	Fallback SA.		Fallback SA.
	The CPU_QUEUES notification value refers to the number of additional		The CPU_QUEUES notification value refers to the number of additional
	resource-specific Child SAs that may be installed for this particular		resource-specific Child SAs that may be installed for this particular
	TSi/TSr combination excluding the Fallback Child SA. Both peers send		TSi/TSr combination excluding the Fallback Child SA. Both peers send
	the preferred minimum number of additional Child SAs to install.		the preferred minimum number of additional Child SAs to install.
	Both peers pick the maximum of the two numbers (within reason). That		Both peers pick the maximum of the two numbers (within reason). That
	is, if the initiator prefers 16 and the responder prefers 48, then		is, if the initiator prefers 16 and the responder prefers 48, then
	the number negotiated is 48. The responder may at any time reject		the number negotiated is 48. The responder may at any time reject
	additional Child SAs by returning TS_UNACCEPTABLE. It should not		additional Child SAs by returning TS_MAX_QUEUE. It should not return
	return NO_ADDITIONAL_SAS, as there might be another Child SAs with		NO_ADDITIONAL_SAS, as there might be another Child SAs with different
	different Traffic Selectors that would still be allowed by the peer.		Traffic Selectors that would still be allowed by the peer.
	[Antony: Valery's feedback was not to use TS_UNACCEPTABLE. instead
	create a new notify or use TEMPORARY_FAILURE. TEMPORARY_FAILURE
	because the situation may change again if you try again. I have
	preference to define new NO_CPU_QUEUE_INFO_SA]
	CPU-specific Child SAs are negotiated as regular Child SAs using the		CPU-specific Child SAs are negotiated as regular Child SAs using the
	CREATE_CHILD_SA exchange and are identified by a CPU_QUEUE_INFO		CREATE_CHILD_SA exchange and are identified by a CPU_QUEUE_INFO
	notification. Upon installation, each Child SA is associated with an		notification. Upon installation, each Child SA is associated with an
	additional local selector, such as CPU or queue. These additional		additional local selector, such as CPU or queue. These additional
	Child SAs MUST be negotiated with identical Child SA properties that		Child SAs MUST be negotiated with identical Child SA properties that
	were negotiated for the Fallback SA. This includes cryptographic		were negotiated for the Fallback SA. This includes cryptographic
	algorithms, Traffic Selectors, Mode (e.g. transport mode),		algorithms, Traffic Selectors, Mode (e.g. transport mode),
	compression usage, etc. However, the Child SAs do have their own		compression usage, etc. However, the Child SAs do have their own
	individual keying material that is derived according to the regular		individual keying material that is derived according to the regular
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 5 ¶
	different from the rekeyed Child SA with respect to cryptographic		different from the rekeyed Child SA with respect to cryptographic
	algorithms and MUST cover the original Traffic Selector ranges.		algorithms and MUST cover the original Traffic Selector ranges.
	If a CREATE_CHILD_SA exchange request containing both a		If a CREATE_CHILD_SA exchange request containing both a
	CPU_QUEUE_INFO and a CPU_QUEUES notification is received, the		CPU_QUEUE_INFO and a CPU_QUEUES notification is received, the
	responder MUST ignore the CPU_QUEUE_INFO payload. If a		responder MUST ignore the CPU_QUEUE_INFO payload. If a
	CREATE_CHILD_SA exchange reply is received with both CPU_QUEUE_INFO		CREATE_CHILD_SA exchange reply is received with both CPU_QUEUE_INFO
	and CPU_QUEUES notifications, the initiator MUST ignore the		and CPU_QUEUES notifications, the initiator MUST ignore the
	notification that it did not send in the request.		notification that it did not send in the request.
	[Steffen: I tend to tread these cases as an error.]
	[Tobias: That's currently how I implemented it (being lenient on what
	I accept). But we could also treat those cases as errors. The
	question would just be what we should return (NO_PROPOSAL_CHOSEN and
	keep IKE and other Child SAs or even INALID_SYNTAX and kill the whole
	IKE_SA - and as initiator we either have to terminate the Child or
	the IKE_SA actively if we receive both notifies).]
	The CPU_QUEUES notification, even when it is sent in the IKE_AUTH		The CPU_QUEUES notification, even when it is sent in the IKE_AUTH
	exchange, is not an attribute of the IKE peer. It is an attribute of		exchange, is not an attribute of the IKE peer. It is an attribute of
	the Child SA, similar to the USE_TRANSPORT notification. That is, an		the Child SA, similar to the USE_TRANSPORT notification. That is, an
	IKE peer can have multiple Child SAs covering different traffic		IKE peer can have multiple Child SAs covering different traffic
	selectors and selectively decide whether or not to enable additional		selectors and selectively decide whether or not to enable additional
	per-resource Child SAs for each of these Child SAs covering different		per-resource Child SAs for each of these Child SAs covering different
	Traffic Selectors.		Traffic Selectors.
	4. Implementation Considerations		4. Implementation Considerations
	skipping to change at page 6, line 13 ¶		skipping to change at page 5, line 34 ¶
	or network queue.		or network queue.
	Performing per-CPU Child SA negotiations can result in both peers		Performing per-CPU Child SA negotiations can result in both peers
	initiating additional Child SAs at once. This is especially likely		initiating additional Child SAs at once. This is especially likely
	if per-CPU Child SAs are triggered by individual SADB_ACQUIRE		if per-CPU Child SAs are triggered by individual SADB_ACQUIRE
	[RFC2367] messages. Responders should install the additional Child		[RFC2367] messages. Responders should install the additional Child
	SA on a CPU with the least amount of additional Child SAs for this		SA on a CPU with the least amount of additional Child SAs for this
	TSi/TSr pair. It should count outstanding SADB_ACQUIREs as an		TSi/TSr pair. It should count outstanding SADB_ACQUIREs as an
	assigned additional Child SA. It is still possible that when the		assigned additional Child SA. It is still possible that when the
	peers only have one slot left to assign, that both peers send a		peers only have one slot left to assign, that both peers send a
	CREATE_CHILD_SA request at the same time. [Paul: Is there anything		CREATE_CHILD_SA request at the same time.
	we can do at the protocol level to terminate one of these without
	race conditions?] [Antony: if CPU_QUEUE_INFO is a MUST, that info
	could be used for better one-to-one mapping, as well as delete the
	extra SAs. Also, keep in mind the general case IKE window > 1]
	As an optimization, additional Child SAs that see little traffic MAY		As an optimization, additional Child SAs that see little traffic MAY
	be deleted. The Fallback Child SA MUST NOT be deleted when idle, as		be deleted. The Fallback Child SA MUST NOT be deleted when idle, as
	it is likely to be idle if enough per-CPU Child SAs are installed.		it is likely to be idle if enough per-CPU Child SAs are installed.
	However, if one of those per-CPU child SAs is deleted because it was		However, if one of those per-CPU child SAs is deleted because it was
	idle, and subsequently that CPU starts to generate traffic again,		idle, and subsequently that CPU starts to generate traffic again,
	that traffic does not have a per-CPU Child SA and will be encrypted		that traffic does not have a per-CPU Child SA and will be encrypted
	using the Fallback Child SA. Meanwhile, the IKE daemon might be		using the Fallback Child SA. Meanwhile, the IKE daemon might be
	negotiating to bring up a new per-CPU Child SA.		negotiating to bring up a new per-CPU Child SA.
	skipping to change at page 7, line 11 ¶		skipping to change at page 6, line 28 ¶
	negotiated via Configuration Payloads (CP) such as		negotiated via Configuration Payloads (CP) such as
	INTERNAL_IP4_ADDRESS which may use the original wide TS set or use		INTERNAL_IP4_ADDRESS which may use the original wide TS set or use
	the narrowed TS set.		the narrowed TS set.
	5. Payload Format		5. Payload Format
	All multi-octet fields representing integers are laid out in big		All multi-octet fields representing integers are laid out in big
	endian order (also known as "most significant byte first", or		endian order (also known as "most significant byte first", or
	"network byte order").		"network byte order").
	5.1. CPU_QUEUES Notify Message Payload		5.1. CPU_QUEUES Notify Status Message Payload
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-----------------------------+-------------------------------+		+-+-----------------------------+-------------------------------+
	! Next Payload !C! RESERVED ! Payload Length !		! Next Payload !C! RESERVED ! Payload Length !
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	! Protocol ID ! SPI Size ! Notify Message Type !		! Protocol ID ! SPI Size ! Notify Message Type !
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	! Minimum number of IPsec SAs !		! Minimum number of IPsec SAs !
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	* Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0.		* 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.		* SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0.
	* Notify Message Type (2 octets) - set to [TBD1]		* Notify Status Message Type (2 octets) - set to [TBD1]
	* Minimum number of per-CPU IPsec SAs (4 octets). MUST be greater		* Minimum number of per-CPU IPsec SAs (4 octets). MUST be greater
	than 0. If 0 is received, it MUST be interpreted as 1.		than 0. If 0 is received, it MUST be interpreted as 1.
	Note: The Fallback Child SA that is not bound to a single CPU is not		Note: The Fallback Child SA that is not bound to a single CPU is not
	counted as part of these numbers.		counted as part of these numbers.
	5.2. CPU_QUEUE_INFO Notify Message Payload		5.2. CPU_QUEUE_INFO Notify Status Message Payload
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-----------------------------+-------------------------------+		+-+-----------------------------+-------------------------------+
	! Next Payload !C! RESERVED ! Payload Length !		! Next Payload !C! RESERVED ! Payload Length !
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	! Protocol ID ! SPI Size ! Notify Message Type !		! Protocol ID ! SPI Size ! Notify Message Type !
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	! !		! !
	~ Optional queue identifier ~		~ Optional queue identifier ~
	! !		! !
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	* Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0.		* 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.		* SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0.
	* Notify Message Type (2 octets) - set to [TBD3]		* Notify Status Message Type (2 octets) - set to [TBD2]
	* Optional Payload Data. This value MAY be set to convey the local		* Optional Payload Data. This value MAY be set to convey the local
	identity of the queue. The value SHOULD be a unique identifier		identity of the queue. The value SHOULD be a unique identifier
	and the peer SHOULD only use it for debugging purposes.		and the peer SHOULD only use it for debugging purposes.
			5.3. TS_MAX_QUEUE Notify Error Message Payload
			1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-----------------------------+-------------------------------+
			! Next Payload !C! RESERVED ! Payload Length !
			+---------------+---------------+-------------------------------+
			! Protocol ID ! SPI Size ! Notify Message Type !
			+---------------+---------------+-------------------------------+
			* 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.
			* Notify Error Message Type (2 octets) - set to [TBD3]
			* Optional Payload Data. Must be 0.
	6. Operational Considerations		6. Operational Considerations
	Implementations supporting per-CPU SAs SHOULD extend their local SPD		Implementations supporting per-CPU SAs SHOULD extend their local SPD
	selector, and the mechanism of on-demand negotiation that is		selector, and the mechanism of on-demand negotiation that is
	triggered by traffic to include a CPU (or queue) identifier in their		triggered by traffic to include a CPU (or queue) identifier in their
	SADB_ACQUIRE message from the SPD to the IKE daemon. If the IKEv2		SADB_ACQUIRE message from the SPD to the IKE daemon. If the IKEv2
	extension defined in this document is negotiated with the peer, a		extension defined in this document is negotiated with the peer, a
	node which does not support receiving per-CPU SADB_ACQUIRE messages		node which does not support receiving per-CPU SADB_ACQUIRE messages
	MAY initiate all its Child SAs immediately upon receiving the (only)		MAY initiate all its Child SAs immediately upon receiving the (only)
	SADB_ACQUIRE it will receive from the IPsec stack. Such		SADB_ACQUIRE it will receive from the IPsec stack. Such
	implementations also need to be careful when receiving a Delete		implementations also need to be careful when receiving a Delete
	Notify request for a per-CPU Child SA, as it has no method to detect		Notify request for a per-CPU Child SA, as it has no method to detect
	when it should bring up such a per-CPU Child SA again later. And		when it should bring up such a per-CPU Child SA again later. And
	bringing the deleted per-CPU Child SA up again immediately after		bringing the deleted per-CPU Child SA up again immediately after
	receiving the Delete Notify might cause an infinite loop between the		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		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		that if the peer acts similarly, the two peers might end up with only
	the Fallback SA without ever activating any per-CPU Child SAs. It is		the Fallback SA without ever activating any per-CPU Child SAs. It is
	there for RECOMMENDED to implement per-CPU SADB_ACQUIRE messages. [		there for RECOMMENDED to implement per-CPU SADB_ACQUIRE messages.
	Antony: It would be nice to add manual/scripts for starting of
	connection and bringing up per-CPU SAs. It could be very simple, a
	external program decides to start a per-CPU SA. ]
	The minimum number of Child SAs negotiated should not be treated as		The minimum number of Child SAs negotiated should not be treated as
	the maximum number of allowed Child SAs. Peers SHOULD be lenient		the maximum number of allowed Child SAs. Peers SHOULD be lenient
	with this number to account for corner cases. For example, during		with this number to account for corner cases. For example, during
	Child SA rekeying, there might be a large number of additional Child		Child SA rekeying, there might be a large number of additional Child
	SAs created before the old Child SAs are torn down. Similarly, when		SAs created before the old Child SAs are torn down. Similarly, when
	using on-demand Child SAs, both ends could trigger multiple Child SA		using on-demand Child SAs, both ends could trigger multiple Child SA
	requests as the initial packet causing the Child SA negotiation might		requests as the initial packet causing the Child SA negotiation might
	have been transported to the peer via the Fallback SA where its reply		have been transported to the peer via the Fallback SA where its reply
	packet might also trigger an on-demand Child SA negotiation to start.		packet might also trigger an on-demand Child SA negotiation to start.
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 6 ¶
	is the same host responsible for generating the traffic, the inbound		is the same host responsible for generating the traffic, the inbound
	and outbound SAs SHOULD remain as a pair on the same CPU. If a host		and outbound SAs SHOULD remain as a pair on the same CPU. If a host
	previously skipped installing an outbound SA because it would be an		previously skipped installing an outbound SA because it would be an
	unused duplicate outbound SA, it will have to create and add the		unused duplicate outbound SA, it will have to create and add the
	previously skipped outbound SA to the SAD with the new CPU ID. The		previously skipped outbound SA to the SAD with the new CPU ID. The
	inbound SA may not have CPU ID in the SAD. Adding the outbound SA to		inbound SA may not have CPU ID in the SAD. Adding the outbound SA to
	the SAD requires access to the key material, whereas for updating the		the SAD requires access to the key material, whereas for updating the
	CPU selector on an existing outbound SAs. access to key material		CPU selector on an existing outbound SAs. access to key material
	might not be needed. To support this, the IKE software might have to		might not be needed. To support this, the IKE software might have to
	hold on to the key material longer than it normally would, as it		hold on to the key material longer than it normally would, as it
	might actively attempt to destroy key material from memorya that it		might actively attempt to destroy key material from memory that it no
	no longer needs access to.		longer needs access to.
	7. Security Considerations		7. Security Considerations
	[TO DO]		[TO DO]
	8. Implementation Status		8. Implementation Status
	[Note to RFC Editor: Please remove this section and the reference to		[Note to RFC Editor: Please remove this section and the reference to
	[RFC6982] before publication.]		[RFC6982] before publication.]
	skipping to change at page 12, line 7 ¶		skipping to change at page 11, line 45 ¶
	Level of maturity: Alpha		Level of maturity: Alpha
	Licensing: GPLv2		Licensing: GPLv2
	Implementation experience: TBD		Implementation experience: TBD
	Contact: Antony Antony antony.antony@secunet.com		Contact: Antony Antony antony.antony@secunet.com
	9. IANA Considerations		9. IANA Considerations
	This document defines four new IKEv2 Notify Message Type payloads for		This document defines two new IKEv2 Notify Message Type payloads for
	the IANA "IKEv2 Notify Message Types - Status Types" registry.		the IANA "IKEv2 Notify Message Types - Status Types" registry.
	Value Notify Type Messages - Status Types Reference		Value Notify Type Messages - Status Types Reference
	----- ------------------------------ ---------------		----- ------------------------------ ---------------
	[TBD1] CPU_QUEUES [this document]		[TBD1] CPU_QUEUES [this document]
	[TBD3] CPU_QUEUE_INFO [this document]		[TBD2] CPU_QUEUE_INFO [this document]
	Figure 1		Figure 1
			This document defines one new IKEv2 Notify Message Type payloads for
			the IANA "IKEv2 Notify Message Types - Error Types" registry.
			Value Notify Type Messages - Status Types Reference
			----- ------------------------------ ---------------
			[TBD3] TS_MAX_QUEUE [this document]
			Figure 2
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key		[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
End of changes. 23 change blocks.
	49 lines changed or deleted		56 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/