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

From: Harold Liu <[email-masked]>
Date: Mon, 22 Nov 2021 06:52:22 +0000

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.

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.

The below announcement is that draft. We would like to work with the community to improve and clarify tech draft.

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, November 22, 2021 2:37 PM
To: Congjie Zhang <[email-masked]>; Harold Liu <[email-masked]>; Daniel Migault <[email-masked]>
Subject: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt

A new version of I-D, draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt
has been successfully submitted by Daiying Liu and posted to the IETF repository.

Name:		draft-liu-ipsecme-ikev2-rekey-redundant-sas
Revision:	00
Title:		IKEv2 Rekey Priority Extension
Document date:	2021-11-21
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/archive/id/draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-rekey-redundant-sas/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-liu-ipsecme-ikev2-rekey-redundant-sas

Abstract:
   This document defines the Internet Key Exchange Version 2 (IKEv2)
   Rekeying Priority extension that enables to agree roles for the next
   rekey of the child SAs and as such optimize IKEv2 rekey negotiation.

The IETF Secretariat

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Nov 2021 09:49:22 -0500 (EST)

> 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 IK…

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

---

From: Harold Liu <[email-masked]>
Date: Wed, 24 Nov 2021 02:01:02 +0000

Hi Paul, thank you very much for your pertinent feedback, please check out my reply inline.

-----Original Message-----
From: Paul Wouters <paul.wouters=[email-masked]> 
Sent: Monday, November 22, 2021 10:49 PM
To: Harold Liu <[email-masked]>
Cc: [email-masked]
Subject: Re: [IPsec] FW: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt

> 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 IK…

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Nov 2021 22:06:45 -0500 (EST)

>       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 cau…

Okay that is fair. Please add it to the Introduction of the draft somehow :)

>       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.

So since lifetime is not negotiated, both endpoints have a need to
rekey. Even if they agree via some other mechanism that one end
should initiate the rekey, what should happen when that rekey is
not happening? At some point the endpoint not initiating will have
to tear down or start a rekey anyway.

So why not, instead of a random process, exchange the maximum Child SA
lifetime accepted before rekey? If the numbers are identical, prefer the
current exchange initiator.

That way, it is deterministic and both endpoints inform the other end
when (plus or minus some fuzz) a rekey is required.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Nov 2021 11:31:57 +0200

> when (plus or minus some fuzz) a rekey is required.

I think the normal way to do that is to make it so that the original
initiator stays initiator. This is usually smart thing anyway as it
keeps statistics etc more stable, and in case there is asymmetricy
between the nodes, it keeps the asymmetry same.

Easiest way to do that is to use shorter lifetime for the initiator,
i.e., if your configured lifetime is 3600 seconds, on original
initiator you use n * (0.85 ± 0.05), and on the original responder you
use n * (1.00 ± 0.05), i.e., your original initiator will start rekey
between 2880 and 3240 seconds, and the original responder is only
trying rekey after 3420-3780 seconds, so original initiator should be
able to finish rekey before original responder even starts thinking
about it.

Btw, I think 300 seconds is way too short rekey interval and would
considere anything less than 10 minutes, or half an hour as an DoS
attack against the gateway. Doing Diffie-Hellman that often is
consuming lots of resources, and I have no idea what your trust model
is to require that frequent rekeying, but similar method should work
there too, but at some point you will need to add some fixed modifiers
too.

I think the implementation I am familiar with did substract fixed 30
seconds from the initiator value always, just to make sure there was
time to finish the rekey before other started it. And I think there
was lower limit of rekey interval of two minutes or so, and that was
mostly because QA wanted to have short rekeying interval for testing
(so tests do not run too long), not for real operational use...

I.e., the rekeying interval on the original initiator was set to n *
(0.85 ± 0.05) - 30 seconds, and on the responder it was set to n *
(1.00 ± 0.05). On the responder you would not normally need
randomization but I think it was there just in case we talked to some
other implementation than our own and having it there might help then.

Also it does not really matter if this happens every now and then,
i.e., once per 100 rekeys or something like that, it usually is only
issue when it happens almost every time. If you follow the rules in
RFC you should recover from the duplicate SAs on the next rekey. On
the other hand if you are doing Diffie-Hellmans that often you clearly
are not concerned about resource use :-)
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 24 Nov 2021 18:55:33 +0300

Hi Harold,

I failed to understand one thing. The situation you are trying to avoid
in most cases happens if peers are configured with equal SA lifetime.
Why you don't just configure your gateways with different lifetimes?
It seems to me that in scenarios you describe you have a total control over gateways?

> > 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>
> >       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.

In our tests we emulated ~3000 SAs between two hosts with lifetime ~300 secs.
With SA lifetimes randomization collisions were very rare (don't remember exact data, I believe few percent of total rekeys).

> >       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>

I can't buy the last argument. Rekey consumes two ~100 bytes messages and little CPU cycles
(unless you do PFS). If you can handle 5G traffic, then couple of hundreds extra bytes happened
in approximately 1% of all rekeys (which in turn are very small fraction of data traffic) 
cannot saturate 5G network, IMHO.

> to tear down or start a rekey anyway.

Exactly. For this reason I don't think the proposed solution is workable.

> when (plus or minus some fuzz) a rekey is required.

It's not enough. There are many cases when rekey is caused not because
of time expiration, but due to other reasons. For example, peer
may count number of bytes sent and rekey after some amount is reached
(when it is critical to limit the number of bytes processed with the same key).
Or the number of messages sent (when you want to limit the number of 
times a key was used for crypto operations). Or just because peer
receives too many packets with invalid ICV and decides that he/she is
under attack trying to break the current key.

I only mentioned those reasons that we implemented...

So, there are a lot of reasons for rekey. I think that the ability for any
peer to rekey at any time it thinks it is needed is a fundamental
property of IKEv2 and I think we should not break it.

Regards,
Valery.

> Paul
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Daniel Migault <[email-masked]>
Date: Tue, 30 Nov 2021 08:21:14 -0500

Hi,

Thank you all for the comments. I believe there is a misunderstanding of
the resource issue we are facing, so please find below a more detailed
description.

The resource in question is neither related to the CPU nor the memory, nor
the bandwidth as comments seem to suggest but instead related to the number
of table entries that perform the IPsec processing that varies between 720
to 4000 depending on the hardware chip.
When gateways rekey at the same time, ephemeral  SAs are created in the
table entry and are filling the entries of the table which means, if we
consider the worst case scenario, only half of the table entries can be
used. In our cases, using the 4000 entry table, leaving 400 unused entries
is not sufficient to prevent legitimate SA from being created and so the
hardware is not used at its full capacity.

We are proposing a determinist mechanism to address this issue. The general
idea is that peers agree that one of the peers will handle the rekey to
renew the SA when that SA expires during a given time slot. To take Tero's
numbers the rekey time slot could be  (0.85 ± 0.05) leaving the future
responder the time to realize the commitment has not been respected and
take over the rekey.
The mechanism is not expected to interfere with any other reasons that
would lead to a rekey.

The mechanism currently does not provide the SA life time as we thought the
mechanism would be mostly useful between gateway that are known to have the
same configuration. We are fine extending the mechanism and including the
SA life time if we can agree that this does not generate any security /
privacy consideration.
Randomizing the SA lifetime is a probabilistic approach we - and our
customers - do not want to rely on even if the probability of collision
decreases with the SA lifetime. Similarly considering different SA lifetime
on every device would require some changes in the way the gateways are
provisioned our customers would like to avoid.

Yours,
Daniel

On Wed, Nov 24, 2021 at 10:55 AM Valery Smyslov <[email-masked]>
wrote:

> > >       4) In gateway to gateway case, randomizing the SA lifetime is
> not sufficient as we do not want to rely on
> With SA lifetimes randomization collisions were very rare (don't remember
> exact data, I believe few percent of total rekeys).
>
> > >       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>
> >

-- 
Daniel Migault
Ericsson

---

From: Paul Wouters <[email-masked]>
Date: Tue, 30 Nov 2021 14:42:00 -0500

> to 4000 depending on the hardware chip.

Okay.

Randomizing the SA lifetime is a probabilistic approach we - and our
customers - do not want to rely on even if the probability of collision
decreases with the SA lifetime.

So now I am a bit confused. If you are mostly concerned able table length,
then 1 double IPsec SA won't hurt you, but 4000 will. So removing a random
percentage amount of seconds from the initiator would actually
probabilistic fix your issue. 4000 connections with a lifetime of 3600s,
that all start at the same time with a 20% fuzz on initiator would cause
you an extra 5 or 6 SAs. If your code recognises the new SA traffic, and
there is frequent traffic, these double SAs would go away in seconds. So on
a unit that can do 4000 SAs, you can now do only 3994 SAs.

Am I making a mistake here ?

Paul