Hi,
section 2.25.2 describes some rules to deal with IKE SA close and rekey
collisions.
In particular, it states:
If a peer receives a request to close an IKE SA that it is currently
rekeying, it SHOULD reply as usual, and forget about its own rekeying
request.
Following this rule may lead to situation when IKE SA states become out of sync.
Consider the following example:
Host A Host B
-------------------------------------------------------------------
send req1:
SA(..,SPIa1,..),Ni1,.. -->
--> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,.. (lost)
Consider the situation when resp1 get lost. At this point
Host B thinks that old SA is successfully rekeyed.
And if it has any reason to close it (for example, its
lifetime is over and Host B was about to start its
rekeying by itself unless it noticed that Host A has
already done it), it will safely (as it thinks) make
close request.
<-- send req2 D()
recv resq2 <--
>From Host A's point of view this is exactly the situation
described in 2.25.2. According to the given rule it replies
as usual to req2 and forgets about its req1.
resend resp2 -->
--> recv resp2
As a result - old IKE SA is closed, but the two peers
have different views on its successor- Host A thinks
that old SA wasn't rekeyed at all and kills its Child SAs,
while Host B thinks it was successfully rekeyed and all its
Child SAs survived.
>From my point of view correct rule for this situation should be:
If a peer receives a request to close an IKE SA that it is currently
rekeying and it did notice simultaneous rekey, it SHOULD reply
as usual, and forget about its own rekeying request.
If a peer receives a request to close an IKE SA that it is currently
rekeying and it didn't notice simultaneous rekey, it SHOULD
postpone to reply to this request untill its own rekeying request
is completed (successfully or not).
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
