Subject: [IPsec] #22: Add section on simultaneous IKE SA rekey

From: Yaron Sheffer <[email-masked]>
Date: Sun, 7 Dec 2008 17:09:22 +0200

Tero: Instead of simultaneous CHILD_SA rekeying, there should be section of
simultaneous IKE SA rekeying. Simultaneous CHILD_SA rekeying just results
few extra SAs that will disappear after next rekeys (at worst there will be
2 SA pairs, but all others will be deleted instead of being rekeyed as they
are not used. The simultaneous IKE SA rekeying is much more important case
to get correct, as both ends MUST agree on which IKE SA survive, as
otherwise they will move the CHILD SA to wrong IKE SA and their state is
completely messed up after that. This section should also explain that even
if the simultaneous rekeying of IKE SA is noticed only AFTER the whole
rekeying is already finished, both ends MUST still correctly detect it and
act based on the fact which IKE SA will survive. This means that the old IKE
SA should not be deleted too quickly after the IKE SA rekey finished, just
in case there happened to be simultaneous rekey in progress. The one doing
the delete should wait at least few minutes before deleting the old IKE SA,
so it can be sure that other end does not have simultaneous rekey going on
the IKE SA.

Room: This (simultaneous IKE SA rekey) is not an easy situation to create
for testing, but it does happen.  Both sides need to agree on which SA
survives, otherwise both IKE SAs could be torn down, losing everything.
There is some text on this, but it needs attention, particularly for the
case in which both IKE SAs get created.  Also need text on how to recognize
simultaneous IKE SA rekey (e.g., if packets lost during simultaneous rekey).
Tero believes that the clarifications document covers this, but that text
needs to be checked.

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Dec 2008 19:53:16 +0200

Yaron Sheffer writes:
> for testing, but it does happen.

Easiest way to create this for testing is to set rekey times to be
same very short time period, but configure retransmission timers to be
much longer than normally. Then set the IKE SAs up and then disconnect
cable between the devices. Now wait for both ends to start doing rekey
of IKE SA, i.e. sending the first packet out. After both ends have
started that you reconnect the cable, and you have simultaneous rekey.
If the retransmission timers are long enough you might even get the
case where first rekey finishes completely before the one to other
direction even starts. 

> Both sides need to agree on which SA

The section 5.11.4 in the RFC4718 talks about this. The twist care
there should be taken care of by making sure the req3 D() is not sent
out before few minutes has passed, so host B's retransmissions of req2
will reach host A, and it will detect there was simultaneous rekey.

The section 5.11.8 also talks bit about similar cases, and there the
same solution works, i.e. delay the deletation of the old IKE SA so
that other end has option to finish the existing exchanges.

The delay is also needed for the device to know which one of the IKE
SAs is the surviving one, so they cannot send delete notification to
the old IKE SA before they know which of the new IKE SAs survived,
meaning which of the nodes should send it.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec