[Openswan Users] Keylife and ikelifetime

[Tuomo Soini]

Paul Wouters wrote:
> On Tue, 23 Dec 2008, openswan at thefeds.net wrote:
> 
>> Both ends have the same lifetimes defined. I noticed after I sent my last mail
>> that the default rekeyfuzz was 100%. This explains why the end that recieved a
>> proposal would sometimes set EVENT_SA_REKEY to be around 2500 seconds when the
>> default lifetime is around 8000 seconds. I have now explicitly set rekeyfuzz
>> to 0% on one of my connections and it is keeping SAs in step much better.
> 
> 100% sounds wrong. I'll look into that.
> 
> using fuzz of 0 is dangerous. If a busy server crashes and restarts, all the
> connections will rekey all at the same time at uptime == lifetime.
> 
>> I don't think the last version of openswan that I used had rekeyfuzz at all,
>> thus I wasn't expecting it to have such a large default.
> 
> It's been in there forever, but the default might have changed accidentally.

I checked and 100% seems to ver only really valid value. From
ipsec_pluto manpage:

Rekeying

When an SA that was initiated by pluto has only a bit of lifetime left,
pluto will initiate the creation of a new SA. This applies to ISAKMP and
IPsec SAs. The rekeying will be initiated when the SA’s remaining
lifetime is less than the rekeymargin plus a random percentage, between
0 and rekeyfuzz, of the rekeymargin.

Similarly, when an SA that was initiated by the peer has only a bit of
lifetime left, pluto will try to initiate the creation of a replacement.
To give preference to the initiator, this rekeying will only be
initiated when the SA’s remaining lifetime is half of rekeymargin. If
rekeying is done by the responder, the roles will be reversed: the
responder for the old SA will be the initiator for the replacement. The
former initiator might also initiate rekeying, so there may be redundant
SAs created. To avoid these complications, make sure that rekeymargin is
generous.

One risk of having the former responder initiate is that perhaps none of
its proposals is acceptable to the former initiator (they have not been
used in a successful negotiation). To reduce the chances of this
happening, and to prevent loss of security, the policy settings are
taken from the old SA (this is the case even if the former initiator is
initiating). These may be stricter than those of the connection.

pluto will not rekey an SA if that SA is not the most recent of its type
(IPsec or ISAKMP) for its potential connection. This avoids creating
redundant SAs.

The random component in the rekeying time (rekeyfuzz) is intended to
make certain pathological patterns of rekeying unstable. If both sides
decide to rekey at the same time, twice as many SAs as necessary are
created. This could become a stable pattern without the randomness.

Another more important case occurs when a security gateway has SAs with
many other security gateways. Each of these connections might need to be
rekeyed at the same time. This would cause a high peek requirement for
resources (network bandwidth, CPU time, entropy for random numbers). The
rekeyfuzz can be used to stagger the rekeying times.

Once a new set of SAs has been negotiated, pluto will never send traffic
on a superseded one. Traffic will be accepted on an old SA until it expires.

rekeymargin defaults to 540 seconds which means you can't have that
early rekeying with default values.

Only if you have tweaked rekeymargin to much longer value you can see
that early renegotiation.

-- 
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>