rfc9838v2.txt		rfc9838.txt
	Internet Engineering Task Force (IETF) V. Smyslov		Internet Engineering Task Force (IETF) V. Smyslov
	Request for Comments: 9838 ELVIS-PLUS		Request for Comments: 9838 ELVIS-PLUS
	Obsoletes: 6407 B. Weis		Obsoletes: 6407 B. Weis
	Category: Standards Track Independent		Category: Standards Track Independent
	ISSN: 2070-1721 September 2025		ISSN: 2070-1721 October 2025
	Group Key Management Using the Internet Key Exchange Protocol Version 2		Group Key Management Using the Internet Key Exchange Protocol Version 2
	(IKEv2)		(IKEv2)
	Abstract		Abstract
	This document presents an extension to the Internet Key Exchange		This document presents an extension to the Internet Key Exchange
	Protocol Version 2 (IKEv2) for the purpose of group key management.		Protocol Version 2 (IKEv2) for the purpose of group key management.
	The protocol is in conformance with the Multicast Security (MSEC)		The protocol is in conformance with the Multicast Security (MSEC)
	Group Key Management architecture, which contains two components:		Group Key Management architecture, which contains two components:
	skipping to change at line 141 ¶		skipping to change at line 141 ¶
	Authors' Addresses		Authors' Addresses
	1. Introduction and Overview		1. Introduction and Overview
	This document presents an extension to IKEv2 [RFC7296] called		This document presents an extension to IKEv2 [RFC7296] called
	G-IKEv2, which accommodates group key management. A group key		G-IKEv2, which accommodates group key management. A group key
	management protocol provides IPsec keys and policy to a set of IPsec		management protocol provides IPsec keys and policy to a set of IPsec
	devices that are authorized to communicate using a Group Security		devices that are authorized to communicate using a Group Security
	Association (GSA) defined in Multicast Group Security Architecture		Association (GSA) defined in Multicast Group Security Architecture
	[RFC3740]. The data communications within the group (e.g., IP		[RFC3740]. The data communications within the group (e.g., IP
	multicast packets) are protected by a key pushed to the GMs by the		multicast packets) are protected by a key pushed to the Group Members
	Group Controller/Key Server (GCKS).		(GMs) by the Group Controller/Key Server (GCKS).
	G-IKEv2 conforms to "The Multicast Group Security Architecture"		G-IKEv2 conforms to "The Multicast Group Security Architecture"
	[RFC3740], "Multicast Extensions to the Security Architecture for the		[RFC3740], "Multicast Extensions to the Security Architecture for the
	Internet Protocol" [RFC5374], and "Multicast Security (MSEC) Group		Internet Protocol" [RFC5374], and "Multicast Security (MSEC) Group
	Key Management Architecture" [RFC4046]. G-IKEv2 replaces "The Group		Key Management Architecture" [RFC4046]. G-IKEv2 replaces "The Group
	Domain of Interpretation" [RFC6407], which defines a similar group		Domain of Interpretation" [RFC6407], which defines a similar group
	key management protocol using IKEv1 [RFC2409] (since deprecated by		key management protocol using IKEv1 [RFC2409] (since deprecated by
	IKEv2). When G-IKEv2 is used, group key management use cases can		IKEv2). When G-IKEv2 is used, group key management use cases can
	benefit from the simplicity, increased robustness, and cryptographic		benefit from the simplicity, increased robustness, and cryptographic
	improvements of IKEv2 (see Appendix A of [RFC7296]).		improvements of IKEv2 (see Appendix A of [RFC7296]).
	skipping to change at line 184 ¶		skipping to change at line 184 ¶
	Refreshing the group keys can be performed either in a unicast mode		Refreshing the group keys can be performed either in a unicast mode
	via the GSA_INBAND_REKEY exchange (Section 2.4.2) performed over a		via the GSA_INBAND_REKEY exchange (Section 2.4.2) performed over a
	specific IKE SA between a GM and a GCKS or in a multicast mode with		specific IKE SA between a GM and a GCKS or in a multicast mode with
	the GSA_REKEY pseudo-exchange (Section 2.4.1) when new keys are being		the GSA_REKEY pseudo-exchange (Section 2.4.1) when new keys are being
	distributed to all GMs.		distributed to all GMs.
	Large and small groups may use different sets of these mechanisms.		Large and small groups may use different sets of these mechanisms.
	When a large group of devices are communicating, the GCKS is likely		When a large group of devices are communicating, the GCKS is likely
	to use the GSA_REKEY message for efficiency. This is shown in		to use the GSA_REKEY message for efficiency. This is shown in
	Figure 1, where multicast communications are indicated with a double		Figure 1, where multicast communications are indicated with a double
	line. (Note: For clarity, IKE_SA_INIT is omitted from Figures 1 and		line.
	2.)
			| Note: For clarity, IKE_SA_INIT is omitted from Figures 1 and 2.
	+--------+		+--------+
	+----IKEv2---->| GCKS |<----IKEv2----+		+----IKEv2---->| GCKS |<----IKEv2----+
	| +--------+ |		| +--------+ |
	| || ^ |		| || ^ |
	| || | |		| || | |
	| || GSA_AUTH |		| || GSA_AUTH |
	| || or |		| || or |
	| || GSA_REGISTRATION |		| || GSA_REGISTRATION |
	| || | |		| || | |
	skipping to change at line 237 ¶		skipping to change at line 238 ¶
	| GCKS/GM | | GM | | GM | | GM |		| GCKS/GM | | GM | | GM | | GM |
	+---------+ +----+ +----+ +----+		+---------+ +----+ +----+ +----+
	|| || || ||		|| || || ||
	*==ESP/AH==**=====ESP/AH====**===ESP/AH===*		*==ESP/AH==**=====ESP/AH====**===ESP/AH===*
	Figure 2: G-IKEv2 Used in Small Groups		Figure 2: G-IKEv2 Used in Small Groups
	A combination of these approaches is also possible. For example, the		A combination of these approaches is also possible. For example, the
	GCKS may use more robust GSA_INBAND_REKEY to provide keys for some		GCKS may use more robust GSA_INBAND_REKEY to provide keys for some
	GMs (for example, those acting as senders in the group) and GSA_REKEY		GMs (for example, those acting as senders in the group) and GSA_REKEY
	for the rest. Also note that GCKS may be a GM (as shown in		for the rest.
	Figure 2).
			| Note: GCKS may also be a GM (as shown in Figure 2).
	IKEv2 message semantics are preserved in that all communications		IKEv2 message semantics are preserved in that all communications
	consist of message request-response pairs. The exception to this		consist of message request-response pairs. The exception to this
	rule is the GSA_REKEY pseudo-exchange, which is a single message		rule is the GSA_REKEY pseudo-exchange, which is a single message
	delivering group updates to the GMs.		delivering group updates to the GMs.
	1.1. Requirements Notation		1.1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	skipping to change at line 306 ¶		skipping to change at line 308 ¶
	the multicast transmission of data messages from the group sender		the multicast transmission of data messages from the group sender
	to other GMs. This specification relies on Encapsulating Security		to other GMs. This specification relies on Encapsulating Security
	Payload (ESP) and Authentication Header (AH) as protocols for		Payload (ESP) and Authentication Header (AH) as protocols for
	Data-Security SAs.		Data-Security SAs.
	Rekey SA:		Rekey SA:
	A single multicast SA between the GCKS and all of the GMs. This		A single multicast SA between the GCKS and all of the GMs. This
	SA is used for multicast transmission of key management messages		SA is used for multicast transmission of key management messages
	from the GCKS to all GMs.		from the GCKS to all GMs.
			Group SA:
			A Data-Security SA or Rekey SA that is shared as part of group
			policy.
	Group Security Association (GSA):		Group Security Association (GSA):
	A collection of Data-Security SAs and Rekey SAs necessary for a GM		A collection of Data-Security SAs and Rekey SAs necessary for a GM
	to receive key updates. A GSA describes the working policy for a		to receive key updates. A GSA describes the working policy for a
	group. Refer to the MSEC Group Key Management Architecture		group. Refer to the MSEC Group Key Management Architecture
	[RFC4046] for additional information.		[RFC4046] for additional information.
	Traffic Encryption Key (TEK):		Traffic Encryption Key (TEK):
	The symmetric cipher key used in a Data-Security SA (e.g., IPsec		The symmetric cipher key used in a Data-Security SA (e.g., IPsec
	ESP) to protect traffic.		ESP) to protect traffic.
	skipping to change at line 503 ¶		skipping to change at line 509 ¶
	The GSA_AUTH exchange is similar to the IKE_AUTH exchange with the		The GSA_AUTH exchange is similar to the IKE_AUTH exchange with the
	difference that its goal is to establish a multicast Data-Security		difference that its goal is to establish a multicast Data-Security
	SA(s) and optionally provide GM with the keys for a Rekey SA. The		SA(s) and optionally provide GM with the keys for a Rekey SA. The
	set of payloads in the GSA_AUTH exchange is slightly different		set of payloads in the GSA_AUTH exchange is slightly different
	because policy is not negotiated between the GM and the GCKS;		because policy is not negotiated between the GM and the GCKS;
	instead, it is provided by the GCKS for the GM. Also note that		instead, it is provided by the GCKS for the GM. Also note that
	GSA_AUTH has its own exchange type, which is different from the		GSA_AUTH has its own exchange type, which is different from the
	IKE_AUTH exchange type.		IKE_AUTH exchange type.
	Note that due to the similarities between IKE_AUTH and GSA_AUTH, most		| Note: Due to the similarities between IKE_AUTH and GSA_AUTH,
	IKEv2 extensions to the IKE_AUTH exchange (like secure password		| most IKEv2 extensions to the IKE_AUTH exchange (like secure
	authentication [RFC6467]) can also be used with the GSA_AUTH		| password authentication [RFC6467]) can also be used with the
	exchange.		| GSA_AUTH exchange.
	Initiator (GM) Responder (GCKS)		Initiator (GM) Responder (GCKS)
	-------------------- ------------------		-------------------- ------------------
	HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,]		HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,]
	AUTH, IDg, [SAg,] [N(GROUP_SENDER),] [N]} -->		AUTH, IDg, [SAg,] [N(GROUP_SENDER),] [N]} -->
	Figure 3: GSA_AUTH Request		Figure 3: GSA_AUTH Request
	A GM initiates a GSA_AUTH request to join a group indicated by the		A GM initiates a GSA_AUTH request to join a group indicated by the
	IDg payload. The GM may include an SAg payload declaring which		IDg payload. The GM may include an SAg payload declaring which
	skipping to change at line 624 ¶		skipping to change at line 630 ¶
	signifies that it is a sender but provides the GM the ability to		signifies that it is a sender but provides the GM the ability to
	request Sender-ID values in case the Data-Security SA supports a		request Sender-ID values in case the Data-Security SA supports a
	counter-mode cipher. Section 2.5.1 includes guidance on requesting		counter-mode cipher. Section 2.5.1 includes guidance on requesting
	Sender-ID values.		Sender-ID values.
	A GM may be limited in the Transforms IDs that it is able or willing		A GM may be limited in the Transforms IDs that it is able or willing
	to use and may find it useful to inform the GCKS which Transform IDs		to use and may find it useful to inform the GCKS which Transform IDs
	it is willing to accept for different security protocols by including		it is willing to accept for different security protocols by including
	the SAg payload into the request message. Proposals for Rekey SA and		the SAg payload into the request message. Proposals for Rekey SA and
	for Data-Security (AH [RFC4302] and/or ESP [RFC4303]) SAs may be		for Data-Security (AH [RFC4302] and/or ESP [RFC4303]) SAs may be
	included into SAg. Proposals for Rekey SA are identified by new		included into SAg. Proposals for Rekey SA are identified by a new
	Protocol ID GIKE_UPDATE with the value 6. Each Proposal contains a		Security Protocol Identifier GIKE_UPDATE with the value 6. Each
	list of Transforms that the GM is able and willing to support for		Proposal contains a list of Transforms that the GM is able and
	that protocol. Valid Transform Types depend on the protocol (AH,		willing to support for that protocol. Valid Transform Types depend
	ESP, GIKE_UPDATE) and are defined in Table 2. Other Transform Types		on the protocol (AH, ESP, GIKE_UPDATE) and are defined in Table 2.
	SHOULD NOT be included as they will be ignored by the GCKS. The		Other Transform Types SHOULD NOT be included as they will be ignored
	Security Parameter Index (SPI) length of each Proposal in an SAg is		by the GCKS. The Security Parameter Index (SPI) length of each
	set to zero, and thus the SPI field is empty. The GCKS MUST NOT use		Proposal in an SAg is set to zero, and thus the SPI field is empty.
	SPI length and SPI fields in the SAg payload.		The GCKS MUST NOT use SPI length and SPI fields in the SAg payload.
	Generally, a single Proposal for each protocol (GIKE_UPDATE, AH/ESP)		Generally, a single Proposal for each protocol (GIKE_UPDATE, AH/ESP)
	will suffice. Because the transforms are not negotiated, the GM		will suffice. Because the transforms are not negotiated, the GM
	simply alerts the GCKS to restrictions it may have. In particular,		simply alerts the GCKS to restrictions it may have. In particular,
	the restriction from Section 3.3 of [RFC7296] that Authenticated		the restriction from Section 3.3 of [RFC7296] that Authenticated
	Encryption with Associated Data (AEAD) and non-AEAD transforms not be		Encryption with Associated Data (AEAD) and non-AEAD transforms not be
	combined in a single proposal doesn't hold when the SAg payload is		combined in a single proposal doesn't hold when the SAg payload is
	being formed. However, if the GM has restrictions on the combination		being formed. However, if the GM has restrictions on the combination
	of algorithms, this can be expressed by sending several proposals.		of algorithms, this can be expressed by sending several proposals.
	skipping to change at line 715 ¶		skipping to change at line 721 ¶
	attacks. The first GSA_REKEY message that the GM receives from the		attacks. The first GSA_REKEY message that the GM receives from the
	GCKS will have a Message ID greater than or equal to the Message ID		GCKS will have a Message ID greater than or equal to the Message ID
	received in the GSA_INITIAL_MESSAGE_ID attribute.		received in the GSA_INITIAL_MESSAGE_ID attribute.
	GMs MUST install the Rekey SA only in the inbound direction.		GMs MUST install the Rekey SA only in the inbound direction.
	Once a GM successfully registers to the group, it MUST replace any		Once a GM successfully registers to the group, it MUST replace any
	information related to this group (policy, keys) that it might have		information related to this group (policy, keys) that it might have
	as a result of a previous registration with a new one.		as a result of a previous registration with a new one.
	Once a GM has received GIKE_UPDATE policy during a registration, the		Once a GM has received the GIKE_UPDATE policy during a registration,
	IKE SA MAY be closed. By convention, the GCKS closes the IKE SA; the		the IKE SA MAY be closed. By convention, the GCKS closes the IKE SA;
	GM SHOULD NOT close it. The GCKS MAY choose to keep the IKE SA open		the GM SHOULD NOT close it. The GCKS MAY choose to keep the IKE SA
	for inband rekey, especially for small groups. If inband rekey is		open for inband rekey, especially for small groups. If inband rekey
	used, then the initial IKE SA can be rekeyed by any side with the		is used, then the initial IKE SA can be rekeyed by any side with the
	standard IKEv2 mechanism described in Section 1.3.2 of [RFC7296]. If		standard IKEv2 mechanism described in Section 1.3.2 of [RFC7296]. If
	for some reason the IKE SA is closed and no GIKE_UPDATE policy is		for some reason the IKE SA is closed and no GIKE_UPDATE policy is
	received during the registration process, the GM MUST consider itself		received during the registration process, the GM MUST consider itself
	excluded from the group. To continue participating in the group, the		excluded from the group. To continue participating in the group, the
	GM needs to re-register.		GM needs to re-register.
	2.3.4. GCKS Registration Operations		2.3.4. GCKS Registration Operations
	A G-IKEv2 GCKS listens for incoming requests from GMs. When the GCKS		A G-IKEv2 GCKS listens for incoming requests from GMs. When the GCKS
	receives an IKE_SA_INIT request, it selects an IKE proposal and		receives an IKE_SA_INIT request, it selects an IKE proposal and
	skipping to change at line 792 ¶		skipping to change at line 798 ¶
	policy.		policy.
	* The GCKS could evaluate the list of Transforms and compare it to		* The GCKS could evaluate the list of Transforms and compare it to
	its current policy for the group. If the GM did not include all		its current policy for the group. If the GM did not include all
	of the ESP, AH, or GIKE_UPDATE Transforms that match the current		of the ESP, AH, or GIKE_UPDATE Transforms that match the current
	group policy or the capabilities of all other currently active		group policy or the capabilities of all other currently active
	GMs, then the GCKS SHOULD return a NO_PROPOSAL_CHOSEN		GMs, then the GCKS SHOULD return a NO_PROPOSAL_CHOSEN
	notification. Alternatively, the GCKS can change the group policy		notification. Alternatively, the GCKS can change the group policy
	as defined below.		as defined below.
	* The GCKS could store the list of transforms with the goal of		* The GCKS could store the list of Transforms with the goal of
	migrating the group policy from the current set of transforms to a		migrating the group policy from the current set of transforms to a
	different one once all of the GMs indicate that they can support		different one once all of the GMs indicate that they can support
	transforms from the new set.		transforms from the new set.
	* The GCKS could store the list of Transforms and adjust the current		* The GCKS could store the list of Transforms and adjust the current
	group policy based on the capabilities of the devices as long as		group policy based on the capabilities of the devices as long as
	they fall within the acceptable security policy of the GCKS.		they fall within the acceptable security policy of the GCKS.
	Depending on its policy, the GCKS may have no further need for the		Depending on its policy, the GCKS may have no further need for the
	IKE SA (e.g., it does not plan to initiate a GSA_INBAND_REKEY		IKE SA (e.g., it does not plan to initiate a GSA_INBAND_REKEY
	exchange). If the GM does not initiate another registration exchange		exchange). If the GM does not initiate another registration exchange
	or Notify (e.g., NO_PROPOSAL_CHOSEN) and the GCKS is not intended to		or Notify (e.g., NO_PROPOSAL_CHOSEN) and the GCKS is not intended to
	use the SA, then the GCKS SHOULD close the IKE SA to save resources		use the SA, then the GCKS SHOULD close the IKE SA to save resources
	after a short period of time.		after a short period of time.
	2.4. Group Maintenance Channel		2.4. Group Maintenance Channel
	The GCKS is responsible for rekeying the secure group per the group		The GCKS is responsible for rekeying the secure group per the group
	policy. Rekeying is an operation whereby the GCKS provides		policy. Rekeying is an operation whereby the GCKS provides
	replacement TEK(s) and KEK, deleting TEK(s), and/or excluding GMs.		replacement TEK(s) and/or KEK, deleting TEK(s), and/or excluding GMs.
	The GCKS may initiate a rekey message if group membership and/or		The GCKS may initiate a rekey message if group membership and/or
	policy has changed or if the keys are about to expire. Two forms of		policy has changed or if the keys are about to expire. Two forms of
	group maintenance channels are provided in G-IKEv2 to push new policy		group maintenance channels are provided in G-IKEv2 to push new policy
	to GMs.		to GMs.
	GSA_REKEY:		GSA_REKEY:
	The GSA_REKEY is a pseudo-exchange, consisting of a one-way IKEv2		The GSA_REKEY is a pseudo-exchange, consisting of a one-way IKEv2
	message sent by the GCKS where the rekey policy is delivered to		message sent by the GCKS where the rekey policy is delivered to
	GMs using IP multicast as a transport. This method is valuable		GMs using IP multicast as a transport. This method is valuable
	for large and dynamic groups and where policy may change		for large and dynamic groups and where policy may change
	skipping to change at line 966 ¶		skipping to change at line 972 ¶
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
	| IKE SA Initiator's SPI | | |		| IKE SA Initiator's SPI | | |
	| | | |		| | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
	| IKE SA Responder's SPI | K |		| IKE SA Responder's SPI | K |
	| | E |		| | E |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Next Payload | MjVer | MnVer | Exchange Type | Flags | H A		| Next Payload | MjVer | MnVer | Exchange Type | Flags | h A
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
	| Message ID | r |		| Message ID | r |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
	| AdjustedLen | | |		| AdjustedLen | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x |
	| Next Payload |C| RESERVED | AdjustedPldLen | | |		| Next Payload |C| RESERVED | AdjustedPldLen | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v
	| | |		| | |
	~ Initialization Vector ~ E		~ Initialization Vector ~ E
	| | n		| | n
	skipping to change at line 1557 ¶		skipping to change at line 1563 ¶
	Algorithm transform. If an AEAD algorithm is used for encryption,		Algorithm transform. If an AEAD algorithm is used for encryption,
	then the GSK_a key will not be used (GM can use the formula above		then the GSK_a key will not be used (GM can use the formula above
	assuming the length of GSK_a is zero).		assuming the length of GSK_a is zero).
	4. Header and Payload Formats		4. Header and Payload Formats
	The G-IKEv2 is an IKEv2 extension and thus inherits its wire format		The G-IKEv2 is an IKEv2 extension and thus inherits its wire format
	for data structures. However, the processing of some payloads are		for data structures. However, the processing of some payloads are
	different. Several new payloads are defined: Group Identification		different. Several new payloads are defined: Group Identification
	(IDg) (Section 4.2), Security Association - GM Supported Transforms		(IDg) (Section 4.2), Security Association - GM Supported Transforms
	(SAg) (Section 4.3), GSA (Section 4.4), and Key Download (KD)		(SAg) (Section 4.3), Group Security Association (GSA) (Section 4.4),
	(Section 4.5). The G-IKEv2 header (Section 4.1), IDg payload, and		and Key Download (KD) (Section 4.5). The G-IKEv2 header
	SAg payload reuse the IKEv2 format for the IKEv2 header, IDi/IDr		(Section 4.1), IDg payload, and SAg payload reuse the IKEv2 format
	payloads, and SA payload, respectively. New exchange types GSA_AUTH,		for the IKEv2 header, IDi/IDr payloads, and SA payload, respectively.
	GSA_REGISTRATION, GSA_REKEY, and GSA_INBAND_REKEY are also added.		New exchange types GSA_AUTH, GSA_REGISTRATION, GSA_REKEY, and
			GSA_INBAND_REKEY are also added.
	This section describes new payloads and the differences in the		This section describes new payloads and the differences in the
	processing of existing IKEv2 payloads.		processing of existing IKEv2 payloads.
	4.1. G-IKEv2 Header		4.1. G-IKEv2 Header
	G-IKEv2 uses the same IKE header format as specified in Section 3.1		G-IKEv2 uses the same IKE header format as specified in Section 3.1
	of [RFC7296]. The Major Version is 2 and the Minor Version is 0, as		of [RFC7296]. The Major Version is 2 and the Minor Version is 0, as
	in IKEv2. IKE SA Initiator's SPI, IKE SA Responder's SPI, Flags,		in IKEv2. IKE SA Initiator's SPI, IKE SA Responder's SPI, Flags,
	Message ID, and Length are as specified in [RFC7296].		Message ID, and Length are as specified in [RFC7296].
	skipping to change at line 1621 ¶		skipping to change at line 1628 ¶
	Next Payload, C, RESERVED, and Payload Length fields:		Next Payload, C, RESERVED, and Payload Length fields:
	Comprise the IKEv2 generic payload header and are defined in		Comprise the IKEv2 generic payload header and are defined in
	Section 3.2 of [RFC7296].		Section 3.2 of [RFC7296].
	Group Policies (variable):		Group Policies (variable):
	A set of group policies for the group.		A set of group policies for the group.
	4.4.1. Group Policies		4.4.1. Group Policies
	Group policies are comprised of two types: GSA policy and GW policy.		Group policies are comprised of two types: group SA policy and group-
	GSA policy defines parameters for the Security Association of the		wide (GW) policy. Group SA policy defines parameters for the
	group. Depending on the employed security protocol, GSA policies may		Security Association of the group. Depending on the employed
	further be classified as Rekey SA (GSA KEK) policy and Data-Security		security protocol, group SA policies may further be classified as
	(GSA TEK) SA policy. GSA payload may contain zero or one GSA KEK		Rekey SA (GSA KEK) policy and Data-Security (GSA TEK) SA policy. GSA
	policy, zero or more GSA TEK policies, and zero or one GW policy,		payload may contain zero or one GSA KEK policy, zero or more GSA TEK
	where either one GSA KEK or one GSA TEK policy MUST be present.		policies, and zero or one GW policy, where either one GSA KEK or one
			GSA TEK policy MUST be present.
	This latitude allows various group policies to be accommodated. For		This latitude allows various group policies to be accommodated. For
	example, if the group policy does not require the use of a Rekey SA,		example, if the group policy does not require the use of a Rekey SA,
	the GCKS would not need to send a GSA KEK policy to the group member		the GCKS would not need to send a GSA KEK policy to the group member
	since all SA updates would be performed using the GSA_INBAND_REKEY		since all SA updates would be performed using the GSA_INBAND_REKEY
	exchange via the unicast IKE SA. Alternatively, group policy might		exchange via the unicast IKE SA. Alternatively, group policy might
	use a Rekey SA but choose to download a KEK to the GM only as part of		use a Rekey SA but choose to download a KEK to the GM only as part of
	the unicast IKE SA. Therefore, the GSA KEK policy would not be		the unicast IKE SA. Therefore, the GSA KEK policy would not be
	necessary as part of the GSA_REKEY message.		necessary as part of the GSA_REKEY message.
	Specifying multiple GSA TEKs allows multiple related data streams		Specifying multiple GSA TEKs allows multiple related data streams
	(e.g., video, audio, and text) to be associated with a session, but		(e.g., video, audio, and text) to be associated with a session, but
	each are protected with an individual Security Association policy.		each are protected with an individual Security Association.
	A GW policy allows for the distribution of group-wide policy, such as		A GW policy allows for the distribution of group-wide policy, such as
	instructions for when to activate and deactivate SAs.		instructions for when to activate and deactivate SAs.
	Policies are distributed in substructures to the GSA payload. The		Policies are distributed in substructures to the GSA payload. The
	format of the substructures is defined in Section 4.4.2 (for GSA		format of the substructures is defined in Section 4.4.2 (for group SA
	policy) and in Section 4.4.3 (for GW policy). The first octet of the		policy) and in Section 4.4.3 (for GW policy). The first octet of the
	substructure unambiguously determines its type; it is zero for GW		substructure unambiguously determines its type; it is zero for GW
	policy and non-zero (actually, it is a security Protocol ID) for GSA		policy and non-zero (actually, it contains a Security Protocol
	policies.		Identifier) for group SA policies.
	4.4.2. Group Security Association Policy Substructure		4.4.2. Group Security Association Policy Substructure
	The GSA policy substructure contains parameters for the SA that are		The group SA policy substructure contains parameters for a single SA
	used with this group. Depending on the security protocol, the SA is		that is used with this group. Depending on the security protocol,
	either a Rekey SA or a Data-Security SA (ESP and AH). The GCKS MUST		the SA is either a Rekey SA or a Data-Security SA (ESP and AH). The
	NOT distribute both ESP and AH policies for the same set of Traffic		GCKS MUST NOT distribute both ESP and AH policies for the same set of
	Selectors.		Traffic Selectors.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Protocol | SPI Size | Length |		| Protocol | SPI Size | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ SPI ~		~ SPI ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Source Traffic Selector ~		~ Source Traffic Selector ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Destination Traffic Selector ~		~ Destination Traffic Selector ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ <GSA Transforms> ~		~ <Group SA Transforms> ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ <GSA Attributes> ~		~ <Group SA Attributes> ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 15: GSA Policy Substructure Format		Figure 15: Group SA Policy Substructure Format
	The GSA policy fields are defined as follows:		The group SA policy fields are defined as follows:
	Protocol (1 octet):		Protocol (1 octet):
	Identifies the security protocol for this group SA. The values		Identifies the security protocol for this group SA. The values
	are defined in the "IKEv2 Security Protocol Identifiers" registry		are defined in the "IKEv2 Security Protocol Identifiers" registry
	in [IKEV2-IANA]. The valid values for this field are 6		in [IKEV2-IANA]. The valid values for this field are 6
	(GIKE_UPDATE) for Rekey SA and 2 (AH) or 3 (ESP) for Data-Security		(GIKE_UPDATE) for Rekey SA and 2 (AH) or 3 (ESP) for Data-Security
	SAs.		SAs.
	SPI Size (1 octet):		SPI Size (1 octet):
	Size of the SPI for the SA. SPI size depends on the SA protocol.		Size of the SPI for the SA. SPI size depends on the SA protocol.
	skipping to change at line 1738 ¶		skipping to change at line 1746 ¶
	in this case will usually define a single IP address or be a		in this case will usually define a single IP address or be a
	wildcard selector. An IP protocol and ports define the		wildcard selector. An IP protocol and ports define the
	characteristics of traffic protected by this Data-Security SA.		characteristics of traffic protected by this Data-Security SA.
	If the Data-Security SAs are created in tunnel mode, then it MUST		If the Data-Security SAs are created in tunnel mode, then it MUST
	be tunnel mode with address preservation (see Multicast Extensions		be tunnel mode with address preservation (see Multicast Extensions
	to the Security Architecture [RFC5374]. UDP encapsulation of ESP		to the Security Architecture [RFC5374]. UDP encapsulation of ESP
	packets [RFC3948] cannot be specified in G-IKEv2 and thus is not		packets [RFC3948] cannot be specified in G-IKEv2 and thus is not
	used for the multicast Data-Security SAs.		used for the multicast Data-Security SAs.
	GSA Transforms (variable):		Group SA Transforms (variable):
	A list of Transform Substructures specifies the policy information		A list of Transform Substructures specifies the policy information
	for the SA. The format is defined in IKEv2 (Section 3.3.2 of		for the SA. The format is defined in IKEv2 (Section 3.3.2 of
	[RFC7296]). The "Last Substruc" field in each Transform		[RFC7296]). The "Last Substruc" field in each Transform
	Substructure is set to 3 except for the last Transform		Substructure is set to 3 except for the last Transform
	Substructure, where it is set to 0. Section 4.4.2.1 describes		Substructure, where it is set to 0. Section 4.4.2.1 describes
	using IKEv2 transforms in GSA policy substructure.		using IKEv2 transforms in the group SA policy substructure.
	GSA Attributes (variable):		Group SA Attributes (variable):
	Contains policy attributes associated with the group SA. The		Contains policy attributes associated with the group SA. The
	following sections describe the possible attributes. Any or all		following sections describe the possible attributes. Any or all
	attributes may be optional, depending on the protocol and the		attributes may be optional, depending on the protocol and the
	group policy. Section 4.4.2.2 defines attributes used in GSA		group policy. Section 4.4.2.2 defines attributes used in the
	policy substructure.		group SA policy substructure.
	4.4.2.1. GSA Transforms		4.4.2.1. Group SA Transforms
	GSA policy is defined by the means of transforms in the GSA policy		Group SA policy is defined by the means of transforms in the group SA
	substructure. For this purpose, the transforms defined in [RFC7296]		policy substructure. For this purpose, the transforms defined in
	are used. In addition, new Transform Types are defined for use in		[RFC7296] are used. In addition, new Transform Types are defined for
	G-IKEv2: Group Controller Authentication Method (GCAUTH) and Key Wrap		use in G-IKEv2: Group Controller Authentication Method (GCAUTH) and
	Algorithm (KWA); see Section 9.		Key Wrap Algorithm (KWA); see Section 9.
	Valid Transform Types depend on the SA protocol and are summarized in		Valid Transform Types depend on the SA protocol and are summarized in
	the table below. Exactly one instance of each mandatory Transform		the table below. Exactly one instance of each mandatory Transform
	Type and at most one instance of each optional Transform Type MUST be		Type and at most one instance of each optional Transform Type MUST be
	present in the GSA policy substructure.		present in the group SA policy substructure.
	+=============+=============================+================+		+=============+=============================+================+
	| Protocol | Mandatory Types | Optional Types |		| Protocol | Mandatory Types | Optional Types |
	+=============+=============================+================+		+=============+=============================+================+
	| GIKE_UPDATE | ENCR, INTEG*, GCAUTH**, KWA | |		| GIKE_UPDATE | ENCR, INTEG*, GCAUTH**, KWA | |
	+-------------+-----------------------------+----------------+		+-------------+-----------------------------+----------------+
	| ESP | ENCR, SN | INTEG |		| ESP | ENCR, SN | INTEG |
	+-------------+-----------------------------+----------------+		+-------------+-----------------------------+----------------+
	| AH | INTEG, SN | |		| AH | INTEG, SN | |
	+-------------+-----------------------------+----------------+		+-------------+-----------------------------+----------------+
	skipping to change at line 1896 ¶		skipping to change at line 1904 ¶
	The key wrap algorithm defined in [RFC5649] with a 128-bit,		The key wrap algorithm defined in [RFC5649] with a 128-bit,
	192-bit, and 256-bit key, respectively. This key wrap algorithm		192-bit, and 256-bit key, respectively. This key wrap algorithm
	is designed for use with AES block cipher.		is designed for use with AES block cipher.
	KW_ARX:		KW_ARX:
	The ARX-KW-8-2-4-GX key wrap algorithm defined in [ARX-KW]. This		The ARX-KW-8-2-4-GX key wrap algorithm defined in [ARX-KW]. This
	key wrap algorithm is designed for use with Chacha20 stream		key wrap algorithm is designed for use with Chacha20 stream
	cipher.		cipher.
	More key wrap algorithms may be defined in the future. The		More key wrap algorithms may be defined in the future. The
	requirement is that these algorithms MUST be able to wrap key		requirement is that these algorithms must be able to wrap key
	material of size up to 256 bytes.		material of size up to 256 bytes.
	The type of the Key Wrap Algorithm transform is 13.		The type of the Key Wrap Algorithm transform is 13.
	4.4.2.1.3. Sequence Numbers Transform		4.4.2.1.3. Sequence Numbers Transform
	The Sequence Numbers (SNs) Transform Type is defined in [RFC9827].		The Sequence Numbers (SNs) Transform Type is defined in [RFC9827].
	This transform describes the properties of sequence numbers of IPsec		This transform describes the properties of sequence numbers of IPsec
	packets. There are currently two Transform IDs defined for this		packets. There are currently two Transform IDs defined for this
	Transform Type: "32-bit Sequential Numbers" and "Partially		Transform Type: "32-bit Sequential Numbers" and "Partially
	skipping to change at line 1928 ¶		skipping to change at line 1936 ¶
	will have to somehow learn the current high-order 32 bits of ESN for		will have to somehow learn the current high-order 32 bits of ESN for
	each sender in the group. The algorithm for doing this described in		each sender in the group. The algorithm for doing this described in
	AH [RFC4302] and ESP [RFC4303] is resource-consuming and is only		AH [RFC4302] and ESP [RFC4303] is resource-consuming and is only
	suitable when a receiver is able to guess the high-order 32 bits		suitable when a receiver is able to guess the high-order 32 bits
	close enough to its real value, which is not the case for multicast		close enough to its real value, which is not the case for multicast
	SAs. For this reason, the "Partially Transmitted 64-bit Sequential		SAs. For this reason, the "Partially Transmitted 64-bit Sequential
	Numbers" Transform ID MUST NOT be used for multicast Data-Security		Numbers" Transform ID MUST NOT be used for multicast Data-Security
	SAs utilizing protocols ESP or AH.		SAs utilizing protocols ESP or AH.
	This document defines a new Transform ID for this Transform Type:		This document defines a new Transform ID for this Transform Type:
	32-bit Unspecified Numbers (2). This Transform ID defines the		"32-bit Unspecified Numbers" (2). This Transform ID defines the
	following properties:		following properties:
	* Sequence numbers are 32 bits in size and are transmitted in the		* Sequence numbers are 32 bits in size and are transmitted in the
	Sequence Number field of AH and ESP packets.		Sequence Number field of AH and ESP packets.
	* The value of sequence numbers is not guaranteed to be unique for		* The value of sequence numbers is not guaranteed to be unique for
	the duration of an SA, thus they are not suitable for replay		the duration of an SA, thus they are not suitable for replay
	protection.		protection.
	This Transform ID MUST be used by the GCKS in case of multi-sender		This Transform ID MUST be used by the GCKS in case of multi-sender
	multicast Data-Security SAs utilizing protocols ESP or AH to inform		multicast Data-Security SAs utilizing protocols ESP or AH to inform
	the GMs that the replay protection is not expected to be possible.		the GMs that the replay protection is not expected to be possible.
	The GCKS MAY also use this Transform ID for single-sender multicast		The GCKS MAY also use this Transform ID for single-sender multicast
	Data-Security SAs if replay protection is not needed (e.g., it is		Data-Security SAs if replay protection is not needed (e.g., it is
	done on the application level).		done on the application level).
	4.4.2.2. GSA Attributes		4.4.2.2. Group SA Attributes
	GSA attributes are generally used to provide GMs with additional		Group SA attributes are generally used to provide GMs with additional
	parameters for the GSA policy. Unlike security parameters		parameters for the group SA policy. Unlike security parameters
	distributed via transforms, which are expected not to change over		distributed via transforms, which are expected not to change over
	time (unless the policy changes), the parameters distributed via GSA		time (unless the policy changes), the parameters distributed via
	attributes may depend on the time the provision takes place, on the		group SA attributes may depend on the time the provision takes place,
	existence of others group SAs, or on other conditions.		on the existence of other group SAs, or on other conditions.
	This document creates a new IKEv2 IANA registry for the types of GSA		This document creates a new IKEv2 IANA registry for the types of
	attributes, which has been initially populated as described in		group SA attributes, which has been initially populated as described
	Section 9. In particular, the following attributes have been added:		in Section 9. In particular, the following attributes have been
			added:
	+=====+========================+======+============+==============+		+=====+========================+======+============+==============+
	|Value| GSA Attributes |Format|Multi-Valued| Used in |		|Value| Group SA Attributes |Format|Multi-Valued| Used in |
	| | | | | Protocol |		| | | | | Protocol |
	+=====+========================+======+============+==============+		+=====+========================+======+============+==============+
	|0 | Reserved | |		|0 | Reserved | |
	+-----+------------------------+------+------------+--------------+		+-----+------------------------+------+------------+--------------+
	|1 | GSA_KEY_LIFETIME |TLV |NO | GIKE_UPDATE, |		|1 | GSA_KEY_LIFETIME |TLV |NO | GIKE_UPDATE, |
	| | | | | AH, ESP |		| | | | | AH, ESP |
	+-----+------------------------+------+------------+--------------+		+-----+------------------------+------+------------+--------------+
	|2 | GSA_INITIAL_MESSAGE_ID |TLV |NO | GIKE_UPDATE |		|2 | GSA_INITIAL_MESSAGE_ID |TLV |NO | GIKE_UPDATE |
	+-----+------------------------+------+------------+--------------+		+-----+------------------------+------+------------+--------------+
	|3 | GSA_NEXT_SPI |TLV |YES | GIKE_UPDATE, |		|3 | GSA_NEXT_SPI |TLV |YES | GIKE_UPDATE, |
	| | | | | AH, ESP |		| | | | | AH, ESP |
	+-----+------------------------+------+------------+--------------+		+-----+------------------------+------+------------+--------------+
	Table 5: GSA Attributes		Table 5: Group SA Attributes
	The attributes follow the format defined in IKEv2 (Section 3.3.5 of		The attributes follow the format defined in IKEv2 (Section 3.3.5 of
	[RFC7296]). The "Format" column defines what attribute format is		[RFC7296]). The "Format" column defines what attribute format is
	allowed: Type/Length/Value (TLV) or Type/Value (TV). The "Multi-		allowed: Type/Length/Value (TLV) or Type/Value (TV). The "Multi-
	Valued" column defines whether multiple instances of the attribute		Valued" column defines whether multiple instances of the attribute
	can appear. The "Used in Protocol" column lists the security		can appear. The "Used in Protocol" column lists the security
	protocols, for which the attribute can be used.		protocols, for which the attribute can be used.
	4.4.2.2.1. GSA_KEY_LIFETIME Attribute		4.4.2.2.1. GSA_KEY_LIFETIME Attribute
	The GSA_KEY_LIFETIME attribute (1) specifies the maximum time for		The GSA_KEY_LIFETIME attribute (1) specifies the maximum time for
	which the SA is valid. The value is a 4-octet unsigned integer in		which the SA is valid. The value is a 4-octet unsigned integer in
	network byte order, specifying a valid time period in seconds. When		network byte order, specifying a valid time period in seconds. When
	the lifetime expires, the GSA and all associated keys MUST be		the lifetime expires, the GSA and all associated keys MUST be
	deleted. The GCKS may delete the SA at any time before the end of		deleted. The GCKS may delete the SA at any time before the end of
	the validity period.		the validity period.
	A single attribute of this type MUST be included into any GSA policy		A single attribute of this type MUST be included into any group SA
	substructure if multicast rekey is employed by the GCKS. This		policy substructure if multicast rekey is employed by the GCKS. This
	attribute SHOULD NOT be used if inband rekey (via the		attribute SHOULD NOT be used if inband rekey (via the
	GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM.		GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM.
	4.4.2.2.2. GSA_INITIAL_MESSAGE_ID Attribute		4.4.2.2.2. GSA_INITIAL_MESSAGE_ID Attribute
	The GSA_INITIAL_MESSAGE_ID attribute (2) defines the initial Message		The GSA_INITIAL_MESSAGE_ID attribute (2) defines the initial Message
	ID to be used by the GCKS in the GSA_REKEY messages. The Message ID		ID to be used by the GCKS in the GSA_REKEY messages. The Message ID
	is a 4-octet unsigned integer in network byte order.		is a 4-octet unsigned integer in network byte order.
	A single attribute of this type is included into the GSA KEK policy		A single attribute of this type is included into the GSA KEK policy
	substructure if the initial Message ID of the Rekey SA is non-zero.		substructure if the initial Message ID of the Rekey SA is non-zero.
	Note that it is always true if a GM joins the group after some		Note that it is always true if a GM joins the group after some
	multicast rekey operations have already taken place in this group.		multicast rekey operations have already taken place in this group.
	In this case this attribute will be included into the GSA policy when		In this case, this attribute will be included into the group SA
	the GM is registered.		policy when the GM is registered.
	This attribute MUST NOT be used if inband rekey (via the		This attribute MUST NOT be used if inband rekey (via the
	GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM.		GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM.
	4.4.2.2.3. GSA_NEXT_SPI Attribute		4.4.2.2.3. GSA_NEXT_SPI Attribute
	The optional GSA_NEXT_SPI attribute (3) contains the SPI that the		The optional GSA_NEXT_SPI attribute (3) contains the SPI that the
	GCKS reserved for the next Rekey SA or Data-Security SAs replacing		GCKS reserved for the next Rekey SA or Data-Security SAs replacing
	the current ones. The length of the attribute data is determined by		the current ones. The length of the attribute data is determined by
	the SPI Size field in the GSA policy substructure the attribute		the SPI Size field in the group SA policy substructure the attribute
	resides in (see Section 4.4.2), and the attribute data contains the		resides in (see Section 4.4.2), and the attribute data contains the
	SPI as it would appear on the network. Multiple attributes of this		SPI as it would appear on the network. Multiple attributes of this
	type MAY be included, meaning that any of the supplied SPIs can be		type MAY be included, meaning that any of the supplied SPIs can be
	used in the replacement group SA.		used in the replacement group SA.
	The GM MAY store these values. Later on, if the GM starts receiving		The GM MAY store these values. Later on, if the GM starts receiving
	messages with one of these SPIs without seeing a rekey message over		messages with one of these SPIs without seeing a rekey message over
	the current Rekey SA, then it may be used as an indication that the		the current Rekey SA, then it may be used as an indication that the
	rekey message got lost on its way to this GM. In this case, the GM		rekey message got lost on its way to this GM. In this case, the GM
	SHOULD re-register to the group.		SHOULD re-register to the group.
	skipping to change at line 2184 ¶		skipping to change at line 2193 ¶
	Keys are distributed in substructures called key bags. Each key bag		Keys are distributed in substructures called key bags. Each key bag
	contains one or more keys that are logically related -- these are		contains one or more keys that are logically related -- these are
	keys for either a single SA (Data-Security SA or Rekey SA) or a		keys for either a single SA (Data-Security SA or Rekey SA) or a
	single GM (in the latter case, besides keys, the key bag may also		single GM (in the latter case, besides keys, the key bag may also
	contain security parameters for this GM).		contain security parameters for this GM).
	For this reason, two types of key bags are defined: Group Key Bag and		For this reason, two types of key bags are defined: Group Key Bag and
	Member Key Bag. The type is unambiguously determined by the first		Member Key Bag. The type is unambiguously determined by the first
	byte of the key bag substructure; for a Member Key Bag, it is zero		byte of the key bag substructure; for a Member Key Bag, it is zero
	and for a Group Key Bag, it is a protocol number, which is always		and for a Group Key Bag, it contains a Security Protocol Identifier,
	non-zero. For a Group Key Bag, the protocol number along with the		which is always non-zero. For a Group Key Bag, the Protocol along
	SPI (see Figure 20) identify the SA that is associated with the keys		with the SPI (see Figure 18) identify the SA that is associated with
	in this bag.		the keys in this bag.
	4.5.2. Group Key Bag Substructure		4.5.2. Group Key Bag Substructure
	The Group Key Bag substructure contains SA key information. This key		The Group Key Bag substructure contains SA key information. This key
	information is associated with some group SAs: either with Data-		information is associated with some group SAs: either with Data-
	Security SAs or with a group Rekey SA.		Security SAs or with a group Rekey SA.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at line 2433 ¶		skipping to change at line 2442 ¶
	generic in general, they are often tied to the underlying encryption		generic in general, they are often tied to the underlying encryption
	algorithms in practice. For example, AES Key Wrap with Padding		algorithms in practice. For example, AES Key Wrap with Padding
	Algorithm [RFC5649] defines key wrapping using AES, and Key Wrapping		Algorithm [RFC5649] defines key wrapping using AES, and Key Wrapping
	Constructions using SipHash and ChaCha [ARX-KW] define key wrapping		Constructions using SipHash and ChaCha [ARX-KW] define key wrapping
	using Chacha20.		using Chacha20.
	In G-IKEv2, the key wrap algorithm MUST be negotiated in the		In G-IKEv2, the key wrap algorithm MUST be negotiated in the
	IKE_SA_INIT exchange so that the GCKS is able to send encrypted keys		IKE_SA_INIT exchange so that the GCKS is able to send encrypted keys
	to the GM in the GSA_AUTH exchange. In addition, if the GCKS plans		to the GM in the GSA_AUTH exchange. In addition, if the GCKS plans
	to use the multicast Rekey SA for group rekey, then it MUST specify		to use the multicast Rekey SA for group rekey, then it MUST specify
	the key wrap algorithm in the GSA payload. Note that key wrap		the key wrap algorithm in the group SA policy for the Rekey SA inside
	algorithms for these cases MAY be different. For the unicast SA, the		the GSA payload. Note that key wrap algorithms for these cases MAY
	key wrap algorithm is negotiated between the GM and the GCKS, while		be different. For the unicast SA, the key wrap algorithm is
	for the multicast Rekey SA, the key wrap algorithm is provided by the		negotiated between the GM and the GCKS, while for the multicast Rekey
	GCKS to the GMs as part of the group policy. If an SAg payload is		SA, the key wrap algorithm is provided by the GCKS to the GMs as part
	included in the GSA_AUTH request, then it MUST indicate which key		of the group policy. If an SAg payload is included in the GSA_AUTH
	wrap algorithms are supported by the GM. In all these cases, the key		request, then it MUST indicate which key wrap algorithms are
	wrap algorithm is specified in a Key Wrap Algorithm transform (see		supported by the GM. In all these cases, the key wrap algorithm is
	Section 4.4.2.1.2).		specified in a Key Wrap Algorithm transform (see Section 4.4.2.1.2).
	The format of the wrapped key is shown in Figure 20.		The format of the wrapped key is shown in Figure 20.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Key ID |		| Key ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| KWK ID |		| KWK ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at line 2566 ¶		skipping to change at line 2575 ¶
	- Attribute MUST NOT be present.		- Attribute MUST NOT be present.
	Note that the restrictions are defined per a substructure for which		Note that the restrictions are defined per a substructure for which
	corresponding attributes are defined and not per a whole G-IKEv2		corresponding attributes are defined and not per a whole G-IKEv2
	message.		message.
	+========================+==================+===========+=======+		+========================+==================+===========+=======+
	| Attributes | GSA_AUTH | GSA_REKEY | Notes |		| Attributes | GSA_AUTH | GSA_REKEY | Notes |
	| | GSA_REGISTRATION | | |		| | GSA_REGISTRATION | | |
	+========================+==================+===========+=======+		+========================+==================+===========+=======+
	| GSA Attributes (Section 4.4.2.2) |		| Group SA Attributes (Section 4.4.2.2) |
	+========================+==================+===========+=======+		+========================+==================+===========+=======+
	| GSA_KEY_LIFETIME | S | S | |		| GSA_KEY_LIFETIME | S | S | |
	+------------------------+------------------+-----------+-------+		+------------------------+------------------+-----------+-------+
	| GSA_INITIAL_MESSAGE_ID | [S] | [S] | |		| GSA_INITIAL_MESSAGE_ID | [S] | [S] | |
	+------------------------+------------------+-----------+-------+		+------------------------+------------------+-----------+-------+
	| GSA_NEXT_SPI | [M] | [M] | |		| GSA_NEXT_SPI | [M] | [M] | |
	+========================+==================+===========+=======+		+========================+==================+===========+=======+
	| GW Policy Attributes (Section 4.4.3.1) |		| GW Policy Attributes (Section 4.4.3.1) |
	+========================+==================+===========+=======+		+========================+==================+===========+=======+
	| GWP_ATD | [S] | [S] | |		| GWP_ATD | [S] | [S] | |
	skipping to change at line 2607 ¶		skipping to change at line 2616 ¶
	(1): The GWP_SENDER_ID_BITS attribute MUST be present if the GCKS		(1): The GWP_SENDER_ID_BITS attribute MUST be present if the GCKS
	policy includes at least one cipher in counter mode of		policy includes at least one cipher in counter mode of
	operation and if the GM included the GROUP_SENDER notify into		operation and if the GM included the GROUP_SENDER notify into
	the registration request. Otherwise, it MUST NOT be present.		the registration request. Otherwise, it MUST NOT be present.
	At least one GM_SENDER_ID attribute MUST be present in the		At least one GM_SENDER_ID attribute MUST be present in the
	former case (and more MAY be present if the GM requested more		former case (and more MAY be present if the GM requested more
	Sender-IDs), and it MUST NOT be present in the latter case.		Sender-IDs), and it MUST NOT be present in the latter case.
	(2): For a Data-Security SA, exactly one SA_KEY attribute MUST be		(2): For a Data-Security SA, exactly one SA_KEY attribute MUST be
	present. For a Rekey SA, at least one SA_KEY attribute MUST be		present. For a Rekey SA, exactly one SA_KEY attribute MUST be
	present in all cases and more of these attributes MAY be		present in the GSA_AUTH and the GSA_REGISTRATION exchange. In
	present in a GSA_REKEY pseudo-exchange.		the GSA_REKEY pseudo-exchange, at least one SA_KEY attribute
			MUST be present and more of these attributes MAY be present.
	(3): The WRAP_KEY attribute MUST be present if the GCKS employs a		(3): The WRAP_KEY attribute MUST be present if the GCKS employs a
	key management method that relies on a key tree (like LKH).		key management method that relies on a key tree (like LKH).
	(4): The AUTH_KEY attribute MUST be present in the GSA_AUTH and		(4): The AUTH_KEY attribute MUST be present in the GSA_AUTH and
	GSA_REGISTRATION exchanges if the GCKS employs an		GSA_REGISTRATION exchanges if the GCKS employs an
	authentication method of rekey operations based on digital		authentication method of rekey operations based on digital
	signatures and MUST NOT be present if implicit authentication		signatures and MUST NOT be present if implicit authentication
	is employed. The AUTH_KEY attribute MUST be present in the		is employed. The AUTH_KEY attribute MUST be present in the
	GSA_REKEY pseudo-exchange if the GCKS employs an authentication		GSA_REKEY pseudo-exchange if the GCKS employs an authentication
	method based on digital signatures and wants to change the		method based on digital signatures and wants to change the
	public key for the following multicast rekey operations.		public key for the following multicast rekey operations.
	+========================+================+==================+=====+		+========================+================+==================+=====+
	| Attributes |GSA_AUTH | GSA_INBAND_REKEY |Notes|		| Attributes |GSA_AUTH | GSA_INBAND_REKEY |Notes|
	| |GSA_REGISTRATION| | |		| |GSA_REGISTRATION| | |
	+========================+================+==================+=====+		+========================+================+==================+=====+
	| GSA Attributes (Section 4.4.2.2) |		| Group SA Attributes (Section 4.4.2.2) |
	+========================+================+==================+=====+		+========================+================+==================+=====+
	| GSA_KEY_LIFETIME |[S] | [S] | |		| GSA_KEY_LIFETIME |[S] | [S] | |
	+------------------------+----------------+------------------+-----+		+------------------------+----------------+------------------+-----+
	| GSA_INITIAL_MESSAGE_ID |- | - | |		| GSA_INITIAL_MESSAGE_ID |- | - | |
	+------------------------+----------------+------------------+-----+		+------------------------+----------------+------------------+-----+
	| GSA_NEXT_SPI |- | - | |		| GSA_NEXT_SPI |- | - | |
	+========================+================+==================+=====+		+========================+================+==================+=====+
	| GW Policy Attributes (Section 4.4.3.1) |		| GW Policy Attributes (Section 4.4.3.1) |
	+========================+================+==================+=====+		+========================+================+==================+=====+
	| GWP_ATD |[S] | [S] | |		| GWP_ATD |[S] | [S] | |
	skipping to change at line 2709 ¶		skipping to change at line 2719 ¶
	which is derived from SK_d and thus cannot be broken even by an		which is derived from SK_d and thus cannot be broken even by an
	attacker equipped with a QC. However, other data sent over the		attacker equipped with a QC. However, other data sent over the
	initial IKE SA may be susceptible to an attacker equipped with a QC		initial IKE SA may be susceptible to an attacker equipped with a QC
	of a sufficient size. Such an attacker can store all the traffic		of a sufficient size. Such an attacker can store all the traffic
	until it obtains such a QC and then decrypt it (i.e., Store Now		until it obtains such a QC and then decrypt it (i.e., Store Now
	Decrypt Later attack). See Section 6 of [RFC8784] for details.		Decrypt Later attack). See Section 6 of [RFC8784] for details.
	While the group keys are protected with PPK and thus are immune to		While the group keys are protected with PPK and thus are immune to
	QC, GCKS implementations that care about other data sent over initial		QC, GCKS implementations that care about other data sent over initial
	IKE SA MUST rely on IKEv2 extensions that protect even initial IKE SA		IKE SA MUST rely on IKEv2 extensions that protect even initial IKE SA
	against QC (like [IPSEC-IKEV2-QR-ALT]).		against QC (like [RFC9867]).
	6.3. Aggregation and Fragmentation Mode for ESP		6.3. Aggregation and Fragmentation Mode for ESP
	Aggregation and fragmentation mode for ESP is defined in [RFC9347].		Aggregation and fragmentation mode for ESP is defined in [RFC9347].
	This mode allows IP packets to be split over several ESP packets or		This mode allows IP packets to be split over several ESP packets or
	several IP packets to be aggregated in a single ESP packet. This		several IP packets to be aggregated in a single ESP packet. This
	mode can only be used with ESP tunnel mode and relies on		mode can only be used with ESP tunnel mode and relies on
	monotonically increasing sequence numbers in the incoming packets.		monotonically increasing sequence numbers in the incoming packets.
	Thus, it is impossible to use this mode for multi-sender multicast		Thus, it is impossible to use this mode for multi-sender multicast
	SAs. Since multicast Data-Security SAs are unidirectional, the		SAs. Since multicast Data-Security SAs are unidirectional, the
	skipping to change at line 2749 ¶		skipping to change at line 2759 ¶
	8. Security Considerations		8. Security Considerations
	When an entity joins the group and becomes a GM, it has to trust that		When an entity joins the group and becomes a GM, it has to trust that
	the GCKS only authorized entities that are admitted to the group and		the GCKS only authorized entities that are admitted to the group and
	has to trust that other GMs will not leak the information shared		has to trust that other GMs will not leak the information shared
	within the group.		within the group.
	8.1. GSA Registration and Secure Channel		8.1. GSA Registration and Secure Channel
	G-IKEv2 registration exchange uses IKEv2 IKE_SA_INIT protocols,		G-IKEv2 registration procedure uses IKEv2 initial exchanges,
	inheriting all the security considerations documented in Section 5 of		inheriting all the security considerations documented in Section 5 of
	[RFC7296], including authentication, confidentiality, on-path attack		[RFC7296], including authentication, confidentiality, on-path attack
	protection, protection against replay/reflection attacks, and denial-		protection, protection against replay/reflection attacks, and denial-
	of-service protection. The GSA_AUTH and GSA_REGISTRATION exchanges		of-service protection. The GSA_REGISTRATION exchange also takes
	also take advantage of those protections. In addition, G-IKEv2		advantage of those protections. In addition, G-IKEv2 brings in the
	brings in the capability to authorize a particular GM regardless of		capability to authorize a particular GM regardless of whether they
	whether they have the IKEv2 credentials.		have the IKEv2 credentials.
	8.2. GSA Maintenance Channel		8.2. GSA Maintenance Channel
	The GSA maintenance channel is cryptographically and integrity		The GSA maintenance channel is cryptographically and integrity
	protected using the cryptographic algorithm and key negotiated in the		protected using the cryptographic algorithm and key negotiated in the
	GSA member registration exchange.		GSA member registration exchange.
	8.2.1. Authentication/Authorization		8.2.1. Authentication/Authorization
	The authentication key is distributed during the GM registration and		The authentication key is distributed during the GM registration and
	skipping to change at line 2856 ¶		skipping to change at line 2866 ¶
	+------------+----------------------------------------+		+------------+----------------------------------------+
	| 2 | Digital Signature |		| 2 | Digital Signature |
	+------------+----------------------------------------+		+------------+----------------------------------------+
	| 3-1023 | Unassigned |		| 3-1023 | Unassigned |
	+------------+----------------------------------------+		+------------+----------------------------------------+
	| 1024-65535 | Reserved for Private Use |		| 1024-65535 | Reserved for Private Use |
	+------------+----------------------------------------+		+------------+----------------------------------------+
	Table 12		Table 12
	3. IANA has created the "GSA Attributes" registry. The registration		3. IANA has created the "Group SA Attributes" registry. The
	policy for this registry is Expert Review [RFC8126]. The initial		registration policy for this registry is Expert Review [RFC8126].
	values of the registry are as follows:		The initial values of the registry are as follows:
	+===========+======================+======+======+============+		+===========+======================+======+======+============+
	|Value |GSA Attributes |Format|Multi-|Used in |		|Value |Group SA Attributes |Format|Multi-|Used in |
	| | | |Valued|Protocol |		| | | |Valued|Protocol |
	+===========+======================+======+======+============+		+===========+======================+======+======+============+
	|0 |Reserved | |		|0 |Reserved | |
	+-----------+----------------------+------+------+------------+		+-----------+----------------------+------+------+------------+
	|1 |GSA_KEY_LIFETIME |TLV |NO |GIKE_UPDATE,|		|1 |GSA_KEY_LIFETIME |TLV |NO |GIKE_UPDATE,|
	| | | | |AH, ESP |		| | | | |AH, ESP |
	+-----------+----------------------+------+------+------------+		+-----------+----------------------+------+------+------------+
	|2 |GSA_INITIAL_MESSAGE_ID|TLV |NO |GIKE_UPDATE |		|2 |GSA_INITIAL_MESSAGE_ID|TLV |NO |GIKE_UPDATE |
	+-----------+----------------------+------+------+------------+		+-----------+----------------------+------+------+------------+
	|3 |GSA_NEXT_SPI |TLV |YES |GIKE_UPDATE,|		|3 |GSA_NEXT_SPI |TLV |YES |GIKE_UPDATE,|
	skipping to change at line 2933 ¶		skipping to change at line 2943 ¶
	| | Private | |		| | Private | |
	| | Use | |		| | Use | |
	+-------------+-------------+-----------------------------------+		+-------------+-------------+-----------------------------------+
	Table 15		Table 15
	6. IANA has created the "Member Key Bag Attributes" registry. The		6. IANA has created the "Member Key Bag Attributes" registry. The
	registration policy for this registry is Expert Review [RFC8126].		registration policy for this registry is Expert Review [RFC8126].
	The initial values of the registry are as follows:		The initial values of the registry are as follows:
	+================+=============+========+==============+		+=============+================+========+==============+
	| Member Key Bag | Value | Format | Multi-Valued |		| Value | Member Key Bag | Format | Multi-Valued |
	| Attributes | | | |		| | Attributes | | |
	+================+=============+========+==============+		+=============+================+========+==============+
	| Reserved | 0 | |		| 0 | Reserved | |
	+----------------+-------------+--------+--------------+		+-------------+----------------+--------+--------------+
	| WRAP_KEY | 1 | TLV | YES |		| 1 | WRAP_KEY | TLV | YES |
	+----------------+-------------+--------+--------------+		+-------------+----------------+--------+--------------+
	| AUTH_KEY | 2 | TLV | NO |		| 2 | AUTH_KEY | TLV | NO |
	+----------------+-------------+--------+--------------+		+-------------+----------------+--------+--------------+
	| GM_SENDER_ID | 3 | TLV | YES |		| 3 | GM_SENDER_ID | TLV | YES |
	+----------------+-------------+--------+--------------+		+-------------+----------------+--------+--------------+
	| Unassigned | 4-16383 | |		| 4-16383 | Unassigned | |
	+----------------+-------------+-----------------------+		+-------------+----------------+-----------------------+
	| Reserved for | 16384-32767 | |		| 16384-32767 | Reserved for | |
	| Private Use | | |		| | Private Use | |
	+----------------+-------------+-----------------------+		+-------------+----------------+-----------------------+
	Table 16		Table 16
	9.1.1. Guidance for Designated Experts		9.1.1. Guidance for Designated Experts
	In all cases of Expert Review described in this section, the		In all cases of Expert Review described in this section, the
	designated expert (DE) is expected to ascertain the existence of		designated expert (DE) is expected to ascertain the existence of
	suitable documentation (a specification) as described in [RFC8126]		suitable documentation (a specification) as described in [RFC8126]
	and verify that the document is permanently and publicly available.		and verify that the document is permanently and publicly available.
	The DE is also expected to check the clarity of purpose and use of		The DE is also expected to check the clarity of purpose and use of
	skipping to change at line 3181 ¶		skipping to change at line 3191 ¶
	Management using IKEv2", Work in Progress, Internet-Draft,		Management using IKEv2", Work in Progress, Internet-Draft,
	draft-yeung-g-ikev2-07, 5 November 2013,		draft-yeung-g-ikev2-07, 5 November 2013,
	<https://datatracker.ietf.org/doc/html/draft-yeung-		<https://datatracker.ietf.org/doc/html/draft-yeung-
	g-ikev2-07>.		g-ikev2-07>.
	[IKEV2-IANA]		[IKEV2-IANA]
	IANA, "Internet Key Exchange Version 2 (IKEv2)		IANA, "Internet Key Exchange Version 2 (IKEv2)
	Parameters",		Parameters",
	<http://www.iana.org/assignments/ikev2-parameters>.		<http://www.iana.org/assignments/ikev2-parameters>.
	[IPSEC-IKEV2-QR-ALT]
	Smyslov, V., "Mixing Preshared Keys in the
	IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of
	IKEv2 for Post-quantum Security", Work in Progress,
	Internet-Draft, draft-ietf-ipsecme-ikev2-qr-alt-10, 23 May
	2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
	ipsecme-ikev2-qr-alt-10>.
	[NNL] Naor, D., Naor, M., and J. Lotspiech, "Revocation and		[NNL] Naor, D., Naor, M., and J. Lotspiech, "Revocation and
	Tracing Schemes for Stateless Receivers", Advances in		Tracing Schemes for Stateless Receivers", Advances in
	Cryptology - CRYPTO 2001, Lecture Notes in Computer		Cryptology - CRYPTO 2001, Lecture Notes in Computer
	Science, vol. 2139, pp. 41-62,		Science, vol. 2139, pp. 41-62,
	DOI 10.1007/3-540-44647-8_3, 2001,		DOI 10.1007/3-540-44647-8_3, 2001,
	<http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf>.		<http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf>.
	[OFT] McGrew, D. and A. Sherman, "Key Establishment in Large		[OFT] McGrew, D. and A. Sherman, "Key Establishment in Large
	Dynamic Groups Using One-Way Function Trees", IEEE		Dynamic Groups Using One-Way Function Trees", IEEE
	Transactions on Software Engineering, vol. 29, no. 5, pp.		Transactions on Software Engineering, vol. 29, no. 5, pp.
	skipping to change at line 3334 ¶		skipping to change at line 3336 ¶
	Traffic Flow Security (IP-TFS)", RFC 9347,		Traffic Flow Security (IP-TFS)", RFC 9347,
	DOI 10.17487/RFC9347, January 2023,		DOI 10.17487/RFC9347, January 2023,
	<https://www.rfc-editor.org/info/rfc9347>.		<https://www.rfc-editor.org/info/rfc9347>.
	[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van		[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
	Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple		Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
	Key Exchanges in the Internet Key Exchange Protocol		Key Exchanges in the Internet Key Exchange Protocol
	Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May		Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
	2023, <https://www.rfc-editor.org/info/rfc9370>.		2023, <https://www.rfc-editor.org/info/rfc9370>.
			[RFC9867] Smyslov, V., "Mixing Preshared Keys in the
			IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the
			Internet Key Exchange Protocol Version 2 (IKEv2) for Post-
			Quantum Security", RFC 9867, DOI 10.17487/RFC9867, October
			2025, <https://www.rfc-editor.org/info/rfc9867>.
	Appendix A. Use of LKH in G-IKEv2		Appendix A. Use of LKH in G-IKEv2
	Section 5.4 of [RFC2627] describes the LKH architecture and how a		Section 5.4 of [RFC2627] describes the LKH architecture and how a
	GCKS uses LKH to exclude GMs. This section clarifies how the LKH		GCKS uses LKH to exclude GMs. This section clarifies how the LKH
	architecture is used with G-IKEv2.		architecture is used with G-IKEv2.
	A.1. Notation		A.1. Notation
	In this section, we will use the notation X{Y}, where a key with ID Y		In this section, we will use the notation X{Y}, where a key with ID Y
	is encrypted with the key with ID X. The notation GSK_w{Y} means		is encrypted with the key with ID X. The notation GSK_w{Y} means
End of changes. 52 change blocks.
	136 lines changed or deleted		144 lines changed or added
This html diff was produced by rfcdiff 1.48.