On Tue, Nov 25, 2025 at 02:42:38PM -0500, Michael Richardson wrote: > > Antony Antony <[email protected]> wrote: > > 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. > > Which fragment? > Was it the biggest? Smallest? > Was there a NAT44? stateful firewall? I know that RFC7383 avoides IP > fragmentation, but it also sure seems strange that it's the same one. > Can this network be reproduced easily? > Was it a queue tail drop? Did you try sending slower? > (Not that it's a good solution, but it's a good diagnosis)
I don't have the full details of the tests. The gist is that IKEv2 gets stuck after several retries — i.e., RFC 7383-style retransmissions of all fragments — while other protocols recover. > > Feedback, concerns, and suggestions are very welcome. Anyone else > > experiece similar issues? Any other solutions? > > I guess I'd like to understand if the test network is realistic, and if so, > if this effort actually solves just this network situation, or many others. > > What I read is that you've implemented SACK for IKEv2 :-) yes. Very similar. > I found the interleaving of the ACK/Missing numbers a creative way to do > this. I would name it different. one thought was make it is easy for the sender to retransmit. > > > cause path-MTU issues. If the number of acknowledged fragments > > results in a payload that approaches the path MTU 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 > > 1. The sender SHOULD limit! > I'd even say that the maximum size SHOULD probably be 576 bytes. That is good advice. My experience is that implementations typically use a per-peer configured fragment size, which seems to work well in practice, so there hasn’t been a need to change it. Speficy ACK should 576 or 1280 for IPv6. > 2. I think the sender can actually send more than one FRAGMENT_ACK message. yes. > 3. If the message being lost is really that huge, then odds are that the > entire message hasn't even made it to the receiver. > A receiver does not need to NAK all missing fragments, just enough to > unblock the flow. Sender-initiated retransmission, IKEv2 behaviour, usually unblocks the flow, but in some scenarios an explicit ACK/NACK is still required. thanks for your feedback, -antony _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
