On Mon, 6 Sep 2010, Raj Singh wrote:
: > 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").
: >
: > The IPsec SA replay counter sync is required for these reasons:
: 1. In cluster environment, IPsec SA reply counter will get get updated from
: active to standby in
: periodic manner. Suppose, we sync IPsec reply counter for every 1,000
: IPsec packets and
: last sync happened at 30,000. So, the next sync will happen 31,000.
: Now, say failover happened at 30, 500. So, standby member becomes
: active, and it start
: using IPsec replay counter from 30, 000. It will be considered as Replay
: Attack and SA has to be destroyed.
:
I don't think the picture is this bleak. What needs to be done is to
increase the sequence number when the failover happens with large enough
value to avoid the replay errors. This can be done by calculating the
expected pps that can be sent by the active node during the sequence
number sync period in the cluster. If you sync once a second, then
calculate the maximum pps you think/know what can be for that period, and
increse the sequence number with that ammount. In your example it would
go as follows:
active seq: 30500
standby seq: 30000
--failover--
standby seq: 30000 + 1000
The window at the remote peer will move to 31000; no replay errors.
In this example we assume that maximum of 1000 packets can be sent during
the sync period.
We've had this working for years without noticeable issues. We sync
faster than once a second because we support pretty high throughput
(several gbit/sec), but we also increase it by quite large number to
support that throughput also during failovers.
: This applies to both outbound and inbound replay counters.
:
The issue is only with outbound sequence numbers, because as we know, the
window can move always forward with incoming packets. So even if the
incoming window is lagging behind it will always move forward when the
remote sends new packets to us.
The draft itself says that the sequence numbers are increased in failover:
o Active member dies and Stand-by member takes over. Stand-by
Member increments its values of Outbound SA Counters for each
IPsec SA and sends them to the peer.
It just desn't define how much to increment. If it increments them with
large enough number there is no need to send them to the peer. The window
at the peer will move automatically to the new values when it receives
ESP/AH packets with the new sequence numbers.
: - 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).
: >
: > I don't think we have any solution for this and any solution is possible
: (?). This basically means that both sides has lost the SA.
: So we have to establish SA from scratch. This draft assumes, that both side
: has the SA and their message windows has mis-matched.
:
If both sides are clusters then naturally both ends have HA, and can
handle failover gracefully. Both ends retain the old SAs in the standby
node, and need to just update the message id window. The concern I had
here is that implementation must be able to handle request also from the
remote end while it is itself also doing the request.
Pekka
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
