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

[Daniel Migault <[e-mail]>]

Hi Paul,

That is correct and this is what we are doing with a 10% over each side
when time base SA life time is used. The number I gave was measured using
byte base SA life time.
We tried the same approach for the byte base SA lifetime but the same
strategy does not work -- unless we consider very high values up to 40% of
the SA life time.

In our case, the traffic is symmetric, that is the same amount of bytes is
carried into both directions, SA life times are randomized +/- 10% and each
gateway checks the SA used for decryption. Such randomization (or
difference between the SAs) is not sufficient as that the counter is
checked approximately every 2 s to determine if a rekey needs to be
performed and any traffic burst cancels differences introduced by the
randomization.
In our current configuration initiator and responder are really
interchangeable, and this mostly results from the fact that they look at
different SAs AND that the traffic is relatively symmetric.
The ability to agree which of the peers is handling the rekey is expected
to prevent such simultaneous rekey as the behavior becomes predictable
between two peers and between different implementations.
There is still a need to introduce some randomness to prevent multiple
rekeys to happen at the same time. Assigning a rekey responsibility
requires one peer to look at both (unidirectional SAs) as opposed to one,
but over the number of SA the necessary resource associated to this
responsibility will remain the same as the one considered.
What we need to make sure is that a rekey occurs even if the peer
designated to rekey does not fulfill its commitment.

If we extend the case to traffic that is asymmetric (with our
implementation) the asymmetry of the traffic competes with the difference
of the SA lifetime which results for a given SA in randomness increasing or
decreasing the probability of simultaneous rekey. So here also, we believe
that being able to specify a behavior will prevent or at least limit the
simultaneous rekey.

Yours,
Daniel

On Tue, Nov 30, 2021 at 2:42 PM Paul Wouters <[e-mail]> wrote:

>
> On Tue, Nov 30, 2021 at 8:21 AM Daniel Migault <[e-mail]>
> wrote:
>
>>
>> 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.
>>
>
> 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
>
>
>
>

-- 
Daniel Migault
Ericsson