| Internet-Draft | IKEv2 Fragment Acknowledgment | November 2025 |
| Antony, et al. | Expires 22 May 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 May 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] 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 [RFC7383] 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 [RFC9370], 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 [I-D.nir-ipsecme-big-payload], [I-D.smyslov-ipsecme-ikev2-extended-pld], [I-D.tjhai-ikev2-beyond-64k-limit].¶
In the current IKEv2 fragmentation mechanism [RFC7383], 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 [RFC9000].¶
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 [RFC7383]. 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 a IKEv2 response, of the same exchange with Fragment Acknowledgment notification indicating the missing fragments. This message is sent with 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 [RFC7296]: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, SK_e, SK_a.¶
This document also uses the following terms defined in [RFC9242]: IKE_INTERMEDIATE.¶
This document also uses the following terms defined in [RFC7383]: 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The Fragment Acknowledgment Notifier, FRAGMENT_ACK, is primarily useful during IKE_AUTH, IKE_INTERMEDIATE, and CREATE_CHILD_SA exchanges. During IKE_AUTH and IKE_INTERMEDIATE, peer authentication may still be incomplete. In these exchanges, fragments are already protected by encryption and integrity using SK_e and SK_a, which must have been derived but not yet authenticated. The format of the fragment header is specified in [RFC7383].¶
#Request
Initiator Responder
IKE_INTERMEDIATE --------------> received some fragments send back ACK
/------- IKE_INTERMEDIATE (with ACK only)
/
Full retransmit /
IKE_INTERMEDIATE ----/--------->
<---
Only send missing fragments
IKE_INTERMEDIATE --------------> Possibly repeat above until all
fragments received
# Response
Initiator Responder
/----- IKE_INTERMEDIATE (actual response)
/
Only send missing fragments
IKE_INTERMEDIATE ------/------->
/ Full retransmit if at least one
<---/ fragment received (although see below)
Received at least one /----- IKE_INTERMEDIATE
fragment /
IKE_INTERMEDIATE (with ACK) --->
/ Only send missing fragments
<----/ /----- IKE_INTERMEDIATE
Possibly send another /
ACK etc. /
<-----/
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-----------------------------+-------------------------------+ | Next Payload !C! RESERVED ! Payload Length | +---------------+---------------+-------------------------------+ | Protocol ID ! SPI Size ! Notify Message Type | +---------------+---------------+-------------------------------+ | ACK #1 (16) | Missing #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK #2 (16) | Missing #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .............................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0.¶
SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0.¶
Notify Status Message Type value (2 octets) - set to TBD2.¶
Pairs of ACK # and Range¶
The payload enumerates a set of received fragments for a single IKE message. The ACK # field indicates the start with lowest fragment number received. And the Missing # field indicates the contiguous range of missing fragments. It enables selective retransmission of only the missing fragments by the sender. The Total Fragments field is part of each fragment header, as defined in [RFC7383], Section 2.5. e.g 4,4 7,10 and so on.¶
The responder MAY send a response to an exchange with Fragment Acknowledgment notification after receiving one or more fragments of a request. See Figure 1. Similarly, the initiator MAY send a Fragment Acknowledgment notification after receiving one or more fragments of a response. See Figure 2.¶
When the initiator sends a FRAGMENT_ACK notification in response to a fragmented response, it would need to set the IKE header Response flag (R) bit. This results in a "response to a response" that uses the same Message ID, which is somewhat unusual in IKEv2 message flow. [NOTE: Other solutions?]¶
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.¶
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 [RFC7296], Section 3.10. It does not include any data in the Notification Data field.¶
Receipt of a FRAGMENT_ACK notification MUST NOT be interpreted as advancing the IKEv2 exchange state. Instead it is signal to retransmit only the missing fragments.¶
The FRAGMENT_ACK notifcation message SHOULD NOT be large enough to cause path-MTU issues. If the number of acknowledged fragments results in a payload that approaches the path MTU or IKEv2 Fragemnet size , the sender MAY limit the number of 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.¶
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.¶
Path MTU discovery mentioned in [RFC7383] is currently ignored; applicability TBD.¶
When fragments exceed the path MTU, they may not be acknowledged, and the IKE state will not advance. This will have re-fragmented as specified in [RFC7383]¶
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 adance 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 bigger protocol change.¶
Should every acknowledgement sent by an IKE peer MUST include the entire state of the buffer. That is, acknowledgements are cumulative. However, when the entire state does not conservately fit into one packt FRAGMENT_ACK message would be partial.¶
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 [I-D.ietf-ipsecme-ikev2-reliable-transport], 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.¶
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 resuse of IV. Which MUST be avoided.¶
[RFC7383] 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 RFC 7383 by modifying the retransmission behavior defined.¶
With FRAGMENT_ACK response, a retransmission would not include the first fragment as required by [RFC7383]. May be add retransmissions should include the First Fragment? This I.D would update [RFC7383].¶
The Section 4 of [RFC7383] should be updated to allow fragment acknowledgment.¶
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 | [this document] |
ACKs TBD¶
TBD¶
TBD¶