Hi Pekka,
the text you are quoting provides implementation guidance (probably good
one), but does not "recommend" (in the RFC 2119 sense of the word, i.e.
equivalent to a normative SHOULD) to do so. We should have stronger text
if we are to avoid accidental replay.
Thanks,
Yaron
On 11/20/2010 02:14 PM, Pekka Riikonen wrote:
:
: Let's take the extreme case where the cluster and the peer synchronize
: the SA, then there is no IKE traffic, and then they synchronize the SA
: again. If we don't do anything special, the second pair of synch
: messages will be identical to the first, i.e. will look like a replay.
: So we have to prevent this case. One trivial solution is to mandate one
: liveness test (initiated by the peer) immediately after the synch.
:
Note that draft recommends that the sync is done only when the IKE SA is
actually needed. If there is not IKE traffic then the sync would have
never been done in the first place.
...
Since there can be a large number of sessions at the standby member,
and sending synchronization exchanges for all of them may result in
overload, the standby member can choose to initiate the exchange in a
"lazy" fashion: only when it has to send or receive the request. In
general, the standby member is free to initiate this exchange at its
discretion.
...
I've implemented the lazy sync, it's seems the best way to do it.
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
