HI Antony,
I doubt that this proposal is workable, at least in some situations.
Consider the IKE SA was just rekeyed, so that each peer starts
its first exchange with Message ID = 0. And consider they simultaneously
initiate same exchange, say CREATE_CHILD_SA. And consider
the response messages need fragmentation. Then the "response to response"
messages will have the same Message ID (0) and the same exchange type
and the same "response flag" as the regular response message for the
other exchange. Moreover, they both can have the same content - FRAGMENT_ACK
notify.
It is impossible for the receiver to find the exchange this message belongs to.
(OK, I can imagine a lot of possible approaches in this situation - e.g., ignore
such messages or process them for both exchanges since it is only a hint,
but this decreases the value of this extension).
In addition, you have to disable (or somehow tweak) a replay protection
mechanism
in IKEv2 since you should be able to process different messages with the same
Message ID.
And you already said that retransmission behavior of responders is also changed.
Overall, the proposed solution looks like a protocol hack to me and I'm not
sure it is
so easy to implement (taking into considerations all possible cases).
I think that depending on the nature of packet loss and the maximum size of the
message,
several approaches are possible.
1. If the message size is of few tens of Kbytes (so that the number of
fragments is few tens),
then the simplest solution would be either to randomize the order fragments
are sent
when retransmitted (or just shift them) and/or add some small delay (20-50
ms) between sending each
fragment. This will cope with situation when network is quickly saturated
or the receiver's buffers
are too small and receivers performance is insufficient. In this case only
the first few fragments are
processed and the rest is dropped. Both solutions (changing the order of
fragment and introducing
delay) should help. They are both easy to implement and don't require
protocol change.
2. If the message size is of several hundreds of Kbytes (so that the number of
fragments is few hundreds),
then the above approach might not help. In this situation your proposal may
not help too,
because the size of FRAGMENT_ACK can grow so much, that the message
containing it
would be fragmented itself. In addition, if the reason of the packet loss
is also network saturation
or insufficient buffer size on receiver, then even with individual acks the
process may still
not converged (you still send a lot of extra data with each retransmission,
that adds to the problem).
In this situation the preferred solution would be to redefine IKE
exchanges, perhaps splitting
them into two sub-exchanges, where peer send a series of fragments one by
one each
individually acknowledged (and not all fragments at once).
3. If the message size is more than 1 Mbyte, then it is not possible to use UDP
with IKE fragmentation
in its current form regardless of how fragments are sent and acknowledged,
because
the number of fragments is limited to 2^16, thus TCP should be used.
And if network just randomly drops packets (I assume there is no congestion
problems),
then your proposal won't help much (in my opinion).
I believe we are now at situation #1. Thus I think that simpler approaches
should help.
If we sometime reach situation #2 (e.g., if we use Classic McEliece with the
smallest public keys),
then proposals like yours can be considered (but I prefer less hacking
approaches).
Regards,
Valery.
> During field testing of post-quantum IKEv2 over UDP, we observed a high
> rate of retransmissions involving IKEv2 fragments. In real-world
> deployments, the same fragment was consistently lost, causing repeated
> all fragments retransmissions as required by RFC 7383. In some cases, the
> peers failed to complete the exchange even after more than 50 retries,
> indicating that the current recovery behavior is insufficient for large
> PQC-sized messages over UDP.
>
> We have been exploring incremental updates to IKEv2 over UDP to improve
> fragment recovery reliability—without introducing the complexity of a
> new transport protocol; without TCP as propsed in
> draft-ietf-ipsecme-ikev2-reliable-transport. The draft below
> outlines our initial ideas for
> selective fragment acknowledgment and receiver-assisted retransmission
> control
>
> Feedback, concerns, and suggestions are very welcome. Anyone else
> experiece similar issues? Any other solutions?
>
>
> -antony
>
> ----- Forwarded message from [email protected] -----
> Date: Wed, 19 Nov 2025 06:34:13 -0800
> From: [email protected]
> To: Antony Antony <[email protected]>, Steffen Klassert
> <[email protected]>, Tobias Brunner <[email protected]>
> Subject: New Version Notification for
> draft-antony-ipsecme-ikev2-fragment-acknowledgment-01.txt
>
> A new version of Internet-Draft
> draft-antony-ipsecme-ikev2-fragment-acknowledgment-01.txt has been
> successfully submitted by Antony Antony and posted to the
> IETF repository.
>
> Name: draft-antony-ipsecme-ikev2-fragment-acknowledgment
> Revision: 01
> Title: IKEv2 Fragment Acknowledgment Extension
> Date: 2025-11-19
> Group: Individual Submission
> Pages: 11
> URL:
> https://www.ietf.org/archive/id/draft-antony-ipsecme-ikev2-fragment-acknowledgment-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-antony-ipsecme-ikev2-fragment-acknowledgment/
> HTML:
> https://www.ietf.org/archive/id/draft-antony-ipsecme-ikev2-fragment-acknowledgment-01.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-antony-ipsecme-ikev2-fragment-acknowledgment
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-antony-ipsecme-ikev2-fragment-acknowledgment-01
>
> Abstract:
>
> 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 IETF Secretariat
>
>
>
> ----- End forwarded message -----
>
> _______________________________________________
> IPsec mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
