>From the draft:
There were some concerns about the current window sync process. The
concern was to make IKEv2 window sync optional but we beleive IKEv2
window sync will be mandatory.
The IKEv2 message id sync is definitely mandatory, but the IPSEC SA seqno
sync IMHO isn't. Although, none of this would be an issue if IKEv2 would
allow initiator to move the window forward freely (that would be real
"fix").
I'm not sure if any of the following should be mentioned in the draft:
- Multiple failovers. In a cluster with three or more nodes, it's
possible that failovers happen in rapid succession. The protocol and the
implementation must be able to handle new failover even if they are still
processing the old failover (for example doing the IPSEC SA seqno sync,
which, if we leave it in, can take time). I see no reason why the
protocol wouldn't allow for this, but implementations must make sure they
can handle it.
- Simultaneous failover at both ends. If failover happens at the same
time in both ends, implementations must be able to handle situation where
they receive SYNC_SA_COUNTER_INFO request before they receive response to
their own request (they may receive the response only after
retransmission).
- Should there be way to negotiate support for IKE SA window sync but not
for IPSEC SA sync? Currently by sending SYNC_SA_COUNTER_INFO_SUPPORTED
you agree to support both, which can mean you may receive the IPSEC SA
syncs.
There's also still bunch of typos in the draft.
Pekka
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
