Hi Tero,
one attractive way to deal with the hard problems is to ignore them :-)
After resynching the IKE SA, the client looks at its active Child SAs.
If any SA is recent (say, less than 1 minute old), it initiates CCSA for
that SA.
We could add protocol elements to query the peer regarding active SAs,
but I don't think we want to go that way.
Thanks,
Yaron
On 11/19/2010 01:38 PM, Tero Kivinen wrote:
Yaron Sheffer writes:
it seems to me we have created an overly complicated solution for replay
protection of the Msg ID = 0 messages. Specifically, I think both the
failover counter and the nonce can be eliminated.
Since the messages are protected under the IKE SA, we just need to
ensure that in a correct run of the protocol, there is never any need to
repeat previous messages. This can be done by including *both* Msg ID
counters in each message, and specifying a few rules to make sure
counters never go backwards.
Cluster member to client:
- The counter I plan to use next (based on a traffic/rekey rate
estimate, must be higher than the last message that was actually sent,
otherwise it might be rejected)
- The counter I think you will use next (the last known value, as
received from the failed cluster member)
Client to cluster:
- The counter I really plan to use next (must be equal to or higher than
the received value)
- The counter you said you will use next
And each side must accept incoming messages only if both values are
equal to or larger than the corresponding one previously received from
the same peer, and one of them is strictly larger than the previous value.
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)
In normal case host_a_out_id and host_b_in_id are same, but if failed
host a cluster member has sent message which never reached the client
before crash, but did reach failover cluster member in sync message
the host_a_out_id might be larger than host_b_in_id, and if failed
cluster member has done exchange with client which didn't reach the
failover cluster member then host_b_in_id might be bigger than
host_a_out_id.
The host_a_in_id should always be smaller than or equal to
host_b_out_id as host B do have authorative knowledge about the
message ID (host A might have missed some messages). If there is
failover situation in both ends (i.e both ends fail simultaneously)
then the host_b_out_id might be smaller than host_a_in_id, and sending
max value of those two will solve even that case.
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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
