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.
: > - 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
: >
I think it's important that the peer that actually knows my message id
tells it to me.
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.
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
