: Why not just take max of both counters. I.e. cluster member sends
: following counters:
:
: - host_a_out_id = Message ID I plan to use next (i.e. last
: message id + 1)
: - host_a_in_id = Largest Message ID I have received from you
:
: Then the client has host_b_out_id (Message ID client plans to use next
: (i.e. last message id + 1), and host_b_in_id (Largest message ID he
: has seen from the cluster members) and will send:
:
: - max(host_a_out_id, host_b_in_id)
: - max(host_a_in_id, host_b_out_id)
:
Isn't this what the -02 draft specifies?
...
o The active member dies, and a standby member takes over. The
standby member sends its own idea of the IKE Message IDs (both
incoming and outgoing) to the peer in an Informational message
exchange with Message ID zero.
o The peer first authenticates the message and then validates the
failover count. The peer compares the received values with the
values available locally and picks the higher value. It then
updates its Message IDs with the higher values and also propose
the same values in its response.
...
: Now the real question is what are we going to do with the exchanges
: which are still in progress when the sync message is received, and how
: do we recover when we notice that we do have missed IKE messages,
: meaning we have created, rekeyed or deleted some Child SA in those
: messages we lost because of failover.
:
Draft specifies what to do here as well, at least partly. Also note that
you may never notice missed IKE messages because they happened in the
failed cluster node. Normal crash recovery takes care of any desync
problems that may have happened.
...
o The peer should not wait for any pending responses while
responding with the new Message ID values. For example, if the
window size is 5 and the peer's window is 3-7, and if the peer has
sent requests 3, 4, 5, 6, 7 and received responses only for 4, 5,
6, 7 but not for 3, then it should include the value 8 in its
EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a
response to message 3 anymore.
o Similarly, the peer should also not wait for pending (incoming)
requests. For example if the window size is 5 and the peer's
window is 3-7 and if the peer has received requests 4, 5, 6, 7 but
not 3, then it should send the value 8 in the
EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to
receive message 3 anymore.
...
Are the Security Considerations in the draft valid anymore at all? And
are the nonce and failover count needed? Yaron wanted to eliminate these,
and I'm all for it.
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
