Files
Johnathan Corgan 5db6382788 Keep a link rekey responder from switching to keys the initiator never installed
The node that answers a link rekey stored its new session as pending and
cut over to it on its own next tick, before the initiator had read the
reply. When that reply was lost, the initiator abandoned the cycle and
freed the index the responder was now sealing to, so frames from the
responder were dropped at the initiator until the link was torn down.

The pending session now records which side of the handshake produced it.
Only a pending session this node initiated is cut over by the rekey tick.
One it answered is promoted when a frame on the new keys from the
initiator authenticates against it, as the data path already does, and a
held pending session also stops this node from starting a rekey of its
own that would overwrite it. If the initiator never adopts the keys, the
responder drops the pending session after a hold that outlasts the
initiator's resend ladder and cutover, its first heartbeat and the
link-dead timeout, and frees its index, so the next rekey can be
answered.

The lost-reply test now runs, and new tests cover the hold, the
retirement and the rekey that completes after it.
2026-09-22 21:43:28 +00:00
..