secunet Security Networks AG

antony.antony@secunet.com

secunet Security Networks AG

steffen.klassert@secunet.com

codelabs GmbH

tobias@codelabs.ch

Internet IP Security Maintenance and Extensions IPsec ESP IKEv2 This document specifies an extension to the Internet Key Exchange Protocol Version 2 (IKEv2) that enables acknowledgment of IKEv2 message fragments over UDP. The mechanism allows an IKE peer to confirm reception of individual fragments during the IKE_AUTH exchange and any subsequent exchanges where IKEv2 Fragmentation is used. Support for this feature is negotiated using a new Notify Message Status Type during IKE_SA_INIT, and fragment acknowledgments are exchanged using a separate Notification payload. This extension improves reliability when large IKE messages are exchanged, such as those containing post-quantum cryptography (PQC) payloads, and reduces retransmission overhead, thereby improving IKEv2 round-trip times in lossy network conditions.

The Internet Key Exchange Protocol Version 2 (IKEv2) uses an unreliable transport (UDP) for message exchange. Originally, IKEv2 messages were small - typically a few hundred bytes to a few kilobytes - such that a simple fragmentation and retransmission mechanism operating over UDP, without congestion control or partial acknowledgments, was practically sufficient. However, with the introduction of post-quantum cryptographic (PQC) algorithms into IKEv2 , IKE peers are now required to exchange much larger messages than those produced by classical algorithms, often tens of kilobytes and sometimes approaching 64 kilobytes in size. There are also several proposals to extend IKEv2 beyond the 64-kilobyte payload limitation , , . In the current IKEv2 fragmentation mechanism , when one or more fragments are lost, the sender retransmits all fragments of the message. Practical experience shows that this can lead to significant retransmission overhead and long delays when large fragmented messages are exchanged. In some chronic cases, peers may fail to establish an IKE SA even after dozens of retransmissions. This document proposes a fragment acknowledgment mechanism for IKEv2, similar in concept to acknowledgment schemes used in QUIC . When both the responder and initiator support the new IKEv2 Fragment Acknowledgment, the initiator retransmits only the fragments that the responder reports as missing, reducing bandwidth consumption and latency overhead. The current IKEv2 retransmission model is entirely initiator-driven: only the initiator can decide when to retransmit a message after a timeout . The responder has no means to request retransmission or to signal that it has received an incomplete set of fragments. This document proposes to extend that model slightly by allowing the responder, upon receiving one or more fragments of an IKE message and detecting that some fragments are missing, to send an IKEv2 response, of the same exchange with Fragments Acknowledgment notification indicating the missing fragments. The IKEv2 responder send message with the IKEv2 Response flag set, while the initiator send it without the IKEv2 Response flag set. It does not require a response, does not advance the IKEv2 Message ID state.

This document uses the following terms defined in : IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, SK_e, SK_a. This document also uses the following terms defined in : IKE_INTERMEDIATE. This document also uses the following terms defined in : IKEv2 Fragmentation, Total Fragments,

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Two Notify Message Status Types are defined: FRAGMENT_ACK_REQ, which acknowledges fragments of an IKE request, and FRAGMENT_ACK_RES, which acknowledges fragments of an IKE response. The Fragment Acknowledgment notifiers (FRAGMENT_ACK_REQ and FRAGMENT_ACK_RES) are primarily useful during the IKE_AUTH, IKE_INTERMEDIATE, and CREATE_CHILD_SA exchanges. During IKE_AUTH and IKE_INTERMEDIATE, peer authentication may still be incomplete, but the fragments themselves are protected by encryption and integrity using SK_e and SK_a, which have been derived but not yet authenticated. The format of the fragment header is specified in . Using two distinct notifiers makes the direction of acknowledgment explicit, avoiding ambiguity in cases of simultaneous exchanges or delayed delivery where multiple messages share the same Message ID.

IKE_INTERMEDIATE request received some fragments send back ACK /------- IKE_INTERMEDIATE (with ACK only, R=1) / Full retransmit / IKE_INTERMEDIATE ----/---------> <--- Only send missing fragments IKE_INTERMEDIATE --------------> Possibly repeat above until all fragments received ]]>

IKE_INTERMEDIATE response / Full retransmit if at least one <---/ fragment received (although see below) Received at least one /----- IKE_INTERMEDIATE fragment / IKE_INTERMEDIATE (with ACK, R=0) ---> / Only send missing fragments <----/ /----- IKE_INTERMEDIATE Possibly send another / ACK etc. / <-----/ ]]>

FRAGMENT_ACK

• 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 Status Message Type value (2 octets) - set to TBD2 or TBD3
• Pairs of ACK # and Range

The payload enumerates the set of missing fragments for a single IKE message. The ACK # field identifies the lowest-numbered missing fragment, and the Missing # field specifies the contiguous range of additional missing fragments. This allows the sender to selectively retransmit only those fragments that have not been received. The Total Fragments field is present in each fragment header, as defined in , Section 2.5. For example: 4,4; 7,10; and so on. FRAGMENT_ACK_RES FRAGMENT_ACK_REQ or FRAGMENT_ACK_RES depends on whether a peer is acknowledging an IKEv2 request or a response.

The responder MAY send a response to an exchange with Fragment Acknowledgment notification after receiving one or more fragments of a request. See . Similarly, the initiator MAY send a Fragment Acknowledgment notification after receiving one or more fragments of a response. See . When the initiator sends a FRAGMENT_ACK_RES notification in response to a fragmented response, it MUST NOT set the IKE header Response (R) bit. This results in a message reuses the same Message ID, which is unusual in IKEv2. However, the notifier is distinct FRAGMENT_ACK_RES. This message is informational in nature, does not advance the Message ID state, and does not require a response. The exchange type is same the request.

Unlike typical IKEv2 exchanges, which complete when a response with the matching Message ID arrives, Fragment Acknowledgment notification do not indicate completion of the exchange. Instead, this message requests retransmission of the missing fragments and MUST NOT advance the IKEv2 Message ID counter. When the sender retransmits in response to a Fragment Acknowledgment, it SHOULD begin with the lowest missing fragment. (See editor’s note below regarding potential use of INFORMATIONAL exchanges.)

The use of Fragment Acknowledgment MUST be negotiated during the IKE_SA_INIT exchange. Both the initiator and the responder indicate support for this extension by including the FRAGMENT_ACK_SUPPORTED Notify Message Status Type (value TBD1) in the IKE_SA_INIT request and response messages. The presence of this notification in both directions confirms that both peers support the Fragment Acknowledgment mechanism. In addition, both peers MUST also signal support for IKEv2 Fragmentation by sending the IKEV2_FRAGMENTATION_SUPPORTED notification as specified in Section 2.3 Negotiation of . If either peer omits the FRAGMENT_ACK_SUPPORTED notification in IKE_SA_INIT the extension MUST NOT be used in subsequent exchanges within that IKE SA. The FRAGMENT_ACK_SUPPORTED notification follows the general rules for Notify Message Status Types as specified in , Section 3.10. It does not include any data in the Notification Data field.

Receipt of a FRAGMENT_ACK_REQ or FRAGMENT_ACK_RES notification MUST NOT be interpreted as advancing the IKEv2 exchange state. Instead it is signal to retransmit only the missing fragments. It MUST only be sent after both peers have indicated support for FRAGMENT_ACK_SUPPORTED.

The FRAGMENT_ACK notification message SHOULD NOT be large enough to cause PMTU issues. If the number of acknowledged fragments results in a payload that approaches the PMTU or the IKEv2 fragment size, the sender MAY limit the number of missing fragment ranges included in a single message and send multiple FRAGMENT_ACK messages if necessary. Implementations SHOULD ensure that each FRAGMENT_ACK message fits within a single UDP datagram to avoid IP-layer fragmentation. When the sender receives multiple FRAGMENT_ACK messages, the sender treats the union of all ranges acknowledged so far as the authoritative view.

Since the IKEv2 retransmission model is sender-driven, the responder SHOULD be conservative about when to send the first FRAGMENT_ACK message. A responder MAY send a FRAGMENT_ACK only after it detects that the sender has retransmitted at least one fragment of the same message, indicating that one or more fragments were likely lost. In general, an IKE peer sending a FRAGMENT_ACK message SHOULD do so only when it can provide useful information about missing fragments, in order to avoid unnecessary traffic and message processing overhead and to remain consistent with the sender-driven retransmission model of IKEv2. However, with large number of fragments this may take long time to converge.

One potential implementation issue I can see with these ACKs is the IV when using AEAD. Both the request and the response use the same Message ID as the actual messages more than once. If the IKEv2 Message ID is used as IV this would lead to reuse of IV. Which MUST be avoided.

specifies that when an IKE message is retransmitted, all fragments of that message, including the first fragment, MUST be retransmitted. The selective retransmission enabled by the FRAGMENT_ACK mechanism defined in this document relaxes that requirement by allowing the sender to retransmit only the fragments that the peer identifies as missing. Accordingly, this document updates by modifying the retransmission behavior specified in Section 2.6. When FRAGMENT_ACK is negotiated, a sender MAY retransmit only the fragments indicated as missing by the peer, rather than retransmitting all fragments including fragment number 1. Section 4 of should be updated to allow fragment acknowledgment.

The following issues are retained for discussion during the evolution of this document and are expected to be resolved or removed if the document becomes a Working Group item.

• PMTU discovery mentioned in should work as it is.
• This I.D. opens up possibility to send fragments of different sizes for PMTU detection. Because of the ACKs the sender can deduce PMTU.
• When fragments exceed the PMTU, they may not be acknowledged, and the IKE state will not advance. This will have re-fragmented as specified in
• Why not use IKEv2 INFORMATIONAL? That may adhere more to IKEv2. However, every INFORMATIONAL needs a response. And if there is no response the INFORMATIONAL message MUST be retransmitted to advance IKE state. This would lead to complex unpredictable retransmissions.
• Why not make new IKEv2 exchange without a response? Instead of responding to the same : responding with IKE_AUTH or IKE_INTERMEDIATE This is worth considering. New Exchange IKE_FRAG_ACK : which has no response. The message will carry IKE exchange and message ID it is responding to. This might be bigger change. This will be a bigger protocol change. Probably too complicated?
• Should every acknowledgment sent by an IKE peer MUST include the entire state of the buffer. That is, acknowledgments are cumulative. However, when the entire state does not conservatively fit into one packet FRAGMENT_ACK message would be partial.
• Rename ACK to NACK? -ve acknowledgment? or SACK May be later?

A possible design alternative is to define a new IKEv2 exchange type, IKE_FRAG_ACK, which carries fragment acknowledgment information but does not have a response. Each IKE_FRAG_ACK message would include the Exchange Type and Message ID of the IKE message it acknowledges. This exchange has no response specified. It is one shot message. This approach would decouple fragment acknowledgment from existing IKE exchanges such as IKE_AUTH, IKE_INTERMEDIATE or CREATE_CHILD_SA.

Reliable transport for IKEv2 over TCP, as proposed in , adds implementation complexity and resource cost. It requires maintaining both TCP and UDP sockets, increasing energy use on low-powered devices. Using TCP for IKE while keeping ESP in UDP mode through NAT gateways introduces additional state and resource requirements. It may also be less compatible with hardware offloading and inefficient for low-power or mobile platforms. Antony's position is that using TCP for IKEv2 is not an ideal solution for improving reliability. While a UDP based ideas borrowed from QUIC-based could provide reliable transport and may be one day congestion control! It would be complex for the limited goal of fragment acknowledgment and selective retransmission. Other authors may have different views on this topic.

This document defines one new registration for the IANA "IKEv2 Notify Message Status Types" registry.

Value	Notify Message Status Type	Reference
[TBD1]	FRAGMENT_ACK_SUPPORTED	[this document]
[TBD2]	FRAGMENT_ACK_REQ	[this document]
[TBD2]	FRAGMENT_ACK_RES	[this document]

ACKs TBD

TBD

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through. This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established. ELVIS-PLUS Nokia The Internet Key Exchange protocol version 2 (IKEv2) can operate either over unreliable (UDP) transport or over reliable (TCP) transport. If TCP is used, then IPsec tunnels created by IKEv2 also use TCP. This document specifies how to decouple IKEv2 and IPsec transports so that IKEv2 can operate over TCP, while IPsec tunnels use unreliable transport. This feature allows IKEv2 to effectively exchange large blobs of data (e.g., when post-quantum algorithms are employed) while avoiding performance problems that arise when IPsec uses TCP. Dell Technologies The messages of the Internet Key Exchange version 2 (IKEv2) protocol are made up of payloads. The current protocol limits each of these payloads to 64KB by having a 2-byte length field. While this is usually enough, several of the payloads may need to be larger. This document updates RFC 7296 by defining an extension that allows larger payloads. ELVIS-PLUS This document describes an extended payload format for the Internet Key Exchange protocol version 2 (IKEv2) messages. This format allows both to decrease an overhead many IKEv2 payloads have and to overcome the current 64 Kbytes limit on the maximum payload size. Post-Quantum genua GmbH ELVIS-PLUS The maximum Internet Key Exchange Version 2 (IKEv2) payload size is limited to 64KB. This makes IKEv2 not usable for conservative post- quantum cryptosystem whose public-key is larger than 64KB. This document discusses the considerations and defines a mechanism to exchange large post-quantum public keys and signatures in IKEv2.

TBD