Pekka Riikonen writes: > On Thu, 18 Nov 2010, Raj Singh wrote: > > : > 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) > : > > : > : It will be better to jump this counter by IKEv2 Message Send Window size > : rather than measuring or guessing traffic here. > : > I think this isn't enough. The failover may have happened after node sent > the packet but before the message id has been synced to another node (or > sync was dropped, or whatever). Skipping window size (for example 1) may > not be enough here. The remote peer is already processing the request > with the message id and now we would be re-using the same message id. > > I also don't like that we'd have to guess the message id.
Missed that guess part in the original message. I do not think there is any way to guess how many messages there was, as in normal case it will be either 0 or 1 (there are not that many Child SA creations / rekeys / deletions, and sane implementations do not do periodical liveness checks). On the other hand if we take max of the value what sender and receiver things the mssage ID for that direction should be that will give us value which can be used from that point on, so no need to guess. > IMO, this can work only we're allowed to freely select the next message ID > I'm going to use. Ie. skip as much as I want to skip, same way as we can > skip ESP sequence numbers. During the failover you will be skipping over the message IDs the other end has seen, but which you do not know you have sent if we are using the max of message ID method. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
