Valery Smyslov writes:
> 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 <--
RFC 5996 section 2.8 says:
After the new equivalent IKE SA is created, the initiator
deletes the old IKE SA, and the Delete payload to delete itself MUST
be the last request sent over the old IKE SA.
I.e. host B is not supposed to delete the IKE SA, it is supposed to
wait for the host A to delete the SA. This is required as otherwise
host B does not know whether the Host A received the its IKE SA rekey
response. When the host A send delete on the old IKE SA, host B will
know that the host A has finished the rekey, and the old IKE SA can be
deleted.
So here host B is not following the RFC5996 and that causes the
problem.
> 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.
I think host B never should start any new operations on the old IKE
SA after it has been rekeyed. I.e. when host B notices that old IKE SA
has (from its point of view) being rekeyed, it should not send
any new requests through it. It should always use the new IKE SA.
On the other hand if host B has already decided to delete the IKE SA,
and his request has for example got lost before it receives the IKE SA
rekey, it should fail the rekey request with TEMPORARY_FAILURE
(2.25.2, first paragraph, last sentence: "If a peer receives a request
to rekey an IKE SA that it is currently trying to close, it SHOULD
reply with TEMPORARY_FAILURE.")
> >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).
I think the correct solution is to say that peer should not send any
new exchanges through the IKE SA the other end has already rekeyed. It
can only wait for its older requests to finish, and wait for the other
end (the one who initiated the IKE SA rekey) to delete the old IKE SA.
Currently we only have "SHOULD NOT start new CREATE_CHILD_SA
exchanges" (section 1.3.2):
Once a peer receives a request to rekey an
IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any
new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed.
I think this should really have been
Once a peer receives a request to rekey an
IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any
new exchanges on the IKE SA that is being rekeyed (except the final
IKE SA delete from the peer who initiated IKE SA rekey).
I.e. SHOULD NOT start any new exchanges, not only CREATE_CHILD_SA
exchanges.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
