On Mon, 22 Nov 2021, Harold Liu wrote:
Recently we ran into a real problem in some IPsec use case - IKEv2 protocol supports rekey mechanism for IKE Security Association (SA) and Child SA, but may result in redundant SAs ([RFC7296], section 2.8.1) when both peers start rekeying at the same time. Although in such case IKEv2 selects the SA created with the lowest of the four nonces and the redundant SA SHOULD be deleted by the endpoint that created it, but it is not enough. Because among the standards, frequent rekeying is highly recommended, but such an approach can be non-optimal when SA are frequently rekeys as SAs are unnecessary computed and adds an additional IKEv2 exchange.
Is your implementation not using a rekey fuzz of say 1 to 5 % ? In that way, two endpoints are extremely unlikely to rekey at the exact same time.
So this document defines the Rekeying Priority in IKEv2 extension which enables to agree roles for rekeying of child SAs and optimize IKEv2 rekey negotiation.
I don't think the role of Initiator or Responder should be changed based on a random value. It is really based on which end has the shortest lifetime, which is not negotiated, presuming both ends want the connection to stay up. In a classic, client to server IPsec connection, it should really be the client that initiates the rekey, and the server is just there to facilitate the client's needs.
The below announcement is that draft. We would like to work with the community to improve and clarify tech draft.
I don't think this document is needed if "fuzz" is used. Can you clarify why you think using random fuzz on the keylife is not good enough? Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
