Hi Paul, thank you very much for your pertinent feedback, please check out my reply inline.
-----Original Message----- From: Paul Wouters <[email protected]> Sent: Monday, November 22, 2021 10:49 PM To: Harold Liu <[email protected]> Cc: [email protected] Subject: Re: [IPsec] FW: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt 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. <Harold> 1) We do use randomize the SA life time. Thanks for the feedback. 2) Currently the typical lifetime is 300s (shortest). 3) In the case of gateway to gateway, there is no client or server. 4) In gateway to gateway case, randomizing the SA lifetime is not sufficient as we do not want to rely on a probabilistic model that depends on the life time of the child SA, but rather ensure we do not run into such duplications. At the same time, even though initiator and responder both have randomize lifetime the lifetime is a completely local value (not negotiated), and even the initiator and responder can use different values. So there's still a probability of rekey happening at both ends simultaneously. 5) Due to the arrival of 5G the number of radio access increases greatly meanwhile IKE sessions are established between GATEWAY and GATEWAY based on cloud-RAN. At the same time, Cloud-ran causes IKE sessions to be concentrated on the gateway and gateway so as to the scale of Child SAs is huge, usually more than thousands. So even a few percent of simultaneous rekeying is unacceptable because it will bring too many redundant packets and occupy bandwidth. </Harold> > 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. <Harold> IKEv2 does not consider fix roles, that is the initiator of one exchange can be the responder of the next. I am wondering if that is something you are willing to change. I also have the impression you are considering a scenario that is different from ours. In our scenario (gateway-to-gateway) the roles of the peers are really symmetric, and there does not seem to have any reasons at all to keep each peer with a fixed role. Of course, when SA lifetime are different this does not occurs - I think the document is pretty clear on that - so the heuristic you propose based on the shortest life time does not seems applicable - at least in the situation we are considering. </Harold> 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? <Harold> We are looking for a deterministic mechanism. We are happy to change the one we proposed, but we cannot rely on SA random SA lifetime. </Harold> Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
