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)
> 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 :-)
I found the interleaving of the ACK/Missing numbers a creative way to do
this. I would name it different.
> 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.
2. I think the sender can actually send more than one FRAGMENT_ACK message.
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.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
