On Wed, 8 Sep 2010, Tero Kivinen wrote:
: In many environments it is quite possible to keep the IKE SA state in
: sync between the cluster members, especially if the liveness checks
: are used correctly, i.e. only when needed, not every n seconds. I.e if
: IKE SA messages are only sent when Child SAs are created, rekeyed, or
: deleted, or when IKE SA is rekeyed, then syncing data between cluster
: members is anyways something you want to do as you want to move that
: new child SA state to other cluster member anyway and syncing the
: message ids in that case is very small part of the syncing you do. If
: you have 100,000 clients, and each have IPsec rekey interval of one
:
: (as you can see I am mostly assuming you do not need the IKE SA
: message id syncing at all, as syncing the peers for IKE SA message is
: completely feasible).
:
I think it is essential that this protocol provides way to rectify this
situation, since IKEv2 doesn't allow moving the window forward freely,
this protocol must provide mechanism for it. This issue is much more
serious than the possible replay attack with IPSEC sequence numbers; the
message id _must_ be correct or the IKE SA is broken.
I think we should leave both sync types in the protocol and provide way to
negotiate support for either or both. I think this will make everyone
happy and makes IKEv2 work in clusters (almost) as well as IKEv1.
Pekka
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
