Re: [IPsec] FW: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt

[Paul Wouters <[e-mail]>]

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