Hi Paul, thank you very much for your pertinent feedback, please check out my
reply inline.
-----Original Message-----
From: Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org>
Sent: Monday, November 22, 2021 10:49 PM
To: Harold Liu <harold....@ericsson.com>
Cc: ipsec@ietf.org
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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
