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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
