| Internet-Draft | IKE Fragmentation for Large Messages | November 2026 |
| Smyslov, et al. | Expires 6 May 2027 | [Page] |
This document describes issues with using Internet Key Exchange version 2 (IKEv2) fragmentation for transmitting large messages on unreliable transport. The document proposes several approaches for dealing with these issues: randomizing the order the fragments are sent, dispersing sending fragments over time and selective retransmission of fragments based on information from the peer about their receiption.¶
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 6 May 2027.¶
Copyright (c) 2026 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 version 2 (IKEv2) protocol [RFC7296] is used for key management in IPsec architecture. IKEv2 was originally defined on UDP transport, and, while later IKEv2 extensions added TCP as a possible transport ([RFC9329], [I-D.ietf-ipsecme-ikev2-reliable-transport]), UDP is still a preferred and mostly used transport for IKEv2.¶
When UDP is used as a transport, any IKEv2 message that exceeds MTU size is fragmented at IP layer. IP fragmentation is known to cause problems with some intermediate devices that cannot correctly procesess any IP fragments other than the first one. To deal with this, a protocol extension was developed that allows fragmenting messages at IKE layer [RFC7383]. While IKEv2 fragmentation allows to avoid IP fragmentation of large messages, it lacks any congestion control mechanisms, that may cause issues when the fragmented message is large (with some definition of "large") and the network (or receiver's) capacity is limited (with some definition of "limited"). This document defines several approaches that can be used to mitigate these issues.¶
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.¶
All multi-octet fields representing integers in this document are laid out in big endian order (also known as "most significant byte first", or "network byte order").¶
It is expected that readers are familiar with the details of how IKEv2 fragmentation [RFC7383] works.¶
At the time the IKE fragmentation mechanism was being developed, it was considered that most IKEv2 messages would fit into the typical MTU size and only few of them could exceed it. In particular, the IKE_AUTH messages containing certificates were concerned and it was assumed at that time that "large" IKEv2 messages would be less than few Kbytes in size, so that the number of IKE fragments for a message (with a typical MTU size) would be small. Due to these considerations it was decided that no mechanism for acknowledging of receipt of individual fragments is needed - all fragments of a message are transmitted (and retransmitted) at once, as with IP fragmentation.¶
When postquantum cryptographic mechanisms started to be incorporated into IKEv2, the notion of "large" for an IKEv2 message has changed from few Kbytes to several tens of Kbytes [I-D.wang-ipsecme-hybrid-kem-ikev2-frodo] and up to several hundreds of Kbytes [I-D.smyslov-ipsecme-ikev2-mceliece] [I-D.kohbrok-ipsecme-mls-gike]. When messages of this size are fragmented and all fragments are sent at once, it can happen that either intermediate network devices or the final recipient are uncapable of handling that much data at the rate it was sent, causing some fragments to be lost. Sender will eventually retransmit all the message fragments, but since the disproportion between sending rate and network/recipient limitations remain, it is likely that some fragments will be lost again. Since the restransmissions are not adaptive, there is no guarantee that the message will eventually be drlivered even after several retransmissions.¶
This document defines several techniques that can be used to improve reliability of transmitting large messages using IKEv2 fragmentation mechanism. These techniques can be used independently of each other. The techniques can be classified as unilateral actionsm, which do not require any actiona from the peer, and bilateral actions that require mutual support by both sender and receiver.¶
The simplest technique is to change the order in which fragments are sent with each retransmission. This will help in situation the recipient have limited buffer size for incoming packets and cannot process the received fragments quickly enough to free the buffer. This means that the some number of the first sent fragments will be processed while the rest will be dropped. Changing the order in which the fragments are sent with each retransmission ensures that the first sent packets will change each time, thus increasing the chances all fragments are delivered.¶
Another simple technique is to add some delay between sending each fragment, thus reducing the rate with which data is being transmitted. Since the sender does not know what rate is OK for the receiver, this document gives no advice what this delay should be. If the sender uses exponential back-off when retransmitting, a sensible approach would be to also increase delay between sending fragments with each retransmission.¶
In IKEv2 it is always the initiator that plays an active role in ensuring that both the request and the response messages of an exchange are delivered (Section 2.1 of [RFC7296]). In particular, the initiator periodically retransmits the request until it receives the response. With IKE fragmentation in case the response message is fragmented, a situation is possible that the initiator receives only some of these fragments. In this situation the initiator must retransmit the request, but if the request message has been fragmented too (the usual case), there is no need to retransmit all fragments of the request message, it is enough to retransmit only the first one (i.e., with the Fragment Number field equal to 1). This works because only this fragment triggers re-sending the response (as specified in Section 2.6.1 of [RFC7383], all other fragments are discarded and would only waste network resources.¶
Selective Retransmission of Fragments is an IKEv2 extension that allows, when supported by both peers, to selectively retransmit only those fragments that weren't delivered.¶
This extension is negotiated by exchanging a new notification FRAGMENT_ACK_SUPPORTED in the IKE_SA_INIT exchange. The Notify Message Type for this notification is <TBA by IANA>, Protocol ID and SPI Size are both set to 0 and the notification data is empty. Future specifications may make use of the notification data of this notification. Implementations compliant with this document MUST ignore the content of the notification data in the received FRAGMENT_ACK_SUPPORTED notification if it is not empty.¶
The negotiation only takes effect if peers also negotiate the use of IKE fragmentation, as defined in Section 2.3 of [RFC7383]. If IKE fragmentation is not negotiated, the FRAGMENT_ACK_SUPPORTED notifications MUST be ignored.¶
If the selective retransmission of fragments is negotiated, the maximum number of fragments that an IKEv2 sender can fragment an IKE message to, is limited to 65534, because the value 65535 (0xffff) in the Total Fragments field of the Encrypted Fragment Payload (Section 2.5 of [RFC7383]) is used as an indication that this is not a fragment, but instead a Fragment Acknowledgment message (Section 4.2.1.4).¶
When the initiator fragments the request message, it sends the fragments to the responder. If the peers negotiated this extension and the responder received only some of the sent fragments, then the responder can indicate which fragments are missing. For this purpose, it sends an IKEv2 response message formatted in accordance with Section 4.2.1.4.¶
The initiator keeps retransmitting the request message until it receives at least one response message fragment. If this extension is negotiated and the request message was sent fragmented and the responder has indicated that it has received all its fragments in the latest Fragment Acknowledgment message, but no response message for the exchange is still received by the initiator, the initiator MUST continue retransmitting the very first fragment of the request until it receives at least one response message fragment.¶
When this happens and if there are still some missing response message fragments and the peers negotiated this extension, the initiator can indicate which fragments are missing. For this purpose, it sends an IKEv2 request message for the same exchange (with the same Message ID) formatted in accordance with Section 4.2.1.4.¶
Fragment Acknowledgment is an IKEv2 message that contains only the Encrypted Fragment payload (see Section 2.5 of [RFC7383]) formatted as follows:¶
All other fields are filled in accordance with [RFC7383] and [RFC7296].¶
If the peers negotiated this extension, the receiver will recognize that this message contains the fragment acknowledgment data. If the message is successfully decrypted and verified, then the receiver extracts the fragment acknowledgment data and obtains the information about the fragments that need to be retransmitted. The receiver MUST ignore messages failed to pass the ICV verification.¶
The content of the Encrypted Fragment payload contains the fragment acknowledgment data in the following format.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rcpt Status Packet Number | Total Fragments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Fragment Num | Last Fragment Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Fragment Acknowledgment Bitmap ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
TBD. Should discuss when to send messages with Fragment Acknowledgment data, how to handle them, how to keep these messages small when the number of fragments is large, how to cope with PMTU discovery, etc.¶
Security of IKEv2 and the IKEv2 fragmentation extension is discussed in [RFC7296] and [RFC7383] respectfully. Techniques proposed in this document do not affect security properties of the protocol.¶
This document defines a new Notify Message Type in the "IKEv2 Notify Message Status Types" registry under the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry group:¶
TBA FRAGMENT_ACK_SUPPORTED¶
This document was inspired by the draft "IKEv2 Fragment Acknowledgment Extension" [I-D.antony-ipsecme-ikev2-fragment-acknowledgment].¶