'Re: [strongSwan] [strongswan] ipsec SA rekeying'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       strongswan-users
Subject:    Re: [strongSwan] [strongswan] ipsec SA rekeying
From:       Andreas Steffen <andreas.steffen () strongswan ! org>
Date:       2009-12-29 6:05:50
Message-ID: 4B399C3E.3070907 () strongswan ! org
[Download RAW message or body]

Hello Ashish,

The old rekeying model up to and include version 4.3.4 was

  delta(x) = (1 + x/100) * rekeymargin

with x being a random value in the range

  0 <= x <= rekeyfuzz,

the defaultof rekeyfuzz being 100%. rekeyfuzz=0% disables the
randomization of the rekeying time.

The rekeying interval for ISAKMP / IKE SAs is then computed as

  ike_interval(x) = ikelifetime - delta(x)

and the rekeying interval for IPSEC / CHILD SAs as

  ipsec_interval(x) = keylife - delta(x)

Thus if you set

ikelifetime=24h
keylife=10m
rekeymargin=2m
rekeyfuzz=100%

we get the range 2m <= delta(x) <= 4m for the randomized margin and

ike_interval   = 24h-240s .. 24h-120s
ipsec_interval = 360s .. 480s

Of course a rekeying interval of 10 minutes for IPsec SAs is extremely
high. I would rather recommend 1..3 hours.

With version 4.3.5 we introduced an extended rekeying model for IKEv2
which allows dynamic rekeying based on encrypted volume measured in
bytes or number of ESP packets.

ike_time(x)      = ikelifetime - (1 + x/100) * margintime
ipsec_time(x)    = lifetime    - (1 + x/100) * margintime
ipsec_bytes(x)   = lifebytes   - (1 + x/100) * marginbytes
ipsec_packets(x) = lifepackets - (1 + x/100) * marginpackets

where x is again a random variable from the range

0 <= x <= rekeyfuzz

lifetime is a synonym for keylife and margintime for rekeymargin.

IKEv1 negotiates the ikelifetime and keylife values where usually
the responder accepts the values proposed by the initiator but
each peer does its own margin and fuzzying calculation.

Best regards

Andreas

ashish mahalka wrote:
> Hello Andreas,
> 
> I have been trying to setup rekeying of both IKE SA annd IPSEC SA. But
> there is some confusion as to what is really the correct behaviour.
> I understand that there some attributes which need to be set :
> 
> ikelifetime
> lifetime
> rekeymargin
> rekeyfuzz
> rekey
> reauth
> 
> We have a requirement to start rekeying at 80% of the time given in
> ikelifetime | lifetime. I am not sure as to how to get this done.
> Can ikelifetime and lifetime values be close ? Or they have to be far
> apart ?
> 
> Also, can you please tell under what scenarios rekeyfuzz, rekey and
> reauth are used ?
> 
> Whether these rekeying values have to be same on both the peers ? Or
> they can be differenet ? If they are different, do the peers agree to a
> common value ? Please explain this with respect to IKEv1 and IKEv2.
> 
> I tried with the below parameters and this is what I have got.
> ikelifetime=24h
> lifetime=10m
> rekeymargin=2m
> 
> FBM# ipsec status
> 000 "host-host": 10.10.10.0/24===10.10.10.2[C=FI
> <http://10.10.10.0/24===10.10.10.2%5BC=FI>, O=Insta,
> CN=Test]...10.10.10.5[C=FI, O=Insta, CN=Test]===10.10.10.0/24
> <http://10.10.10.0/24>; ero2
> 000 "host-host":   newest ISAKMP SA: #1; newest IPsec SA: #2;
> 000
> 000 #2: "host-host" STATE_QUICK_I2 (sent QI2, IPsec SA established);
> EVENT_SA_REPLACE in 377s; newest IPSEC; eroute owner
> 000 #2: "host-host" esp.fb533e8b@10.10.10.5
> <mailto:esp.fb533e8b@10.10.10.5> (0 bytes) esp.dce7c743@10.10.10.2
> <mailto:esp.dce7c743@10.10.10.2> (0 bytes); tunnel
> 000 #1: "host-host" STATE_MAIN_I4 (ISAKMP SA established);
> EVENT_SA_REPLACE in 86121s; newest ISAKMP
> 
> */This is taken as soon as the IPSEC SA was established. From these I
> understand IPSEC SA is going to replaced in 377s and ISAKMP SA in
> 86121s. But these values on the other peer were different even though I
> have given the same rekeying values.
> /*
> FBM# ipsec status
> 000 "host-host": 10.10.10.0/24===10.10.10.2[C=FI
> <http://10.10.10.0/24===10.10.10.2%5BC=FI>, O=Insta,
> CN=Test]...10.10.10.5[C=FI, O=Insta, CN=Test]===10.10.10.0/24
> <http://10.10.10.0/24>; ero3
> 000 "host-host":   newest ISAKMP SA: #1; newest IPsec SA: #3;
> 000
> 000 #3: "host-host" STATE_QUICK_I2 (sent QI2, IPsec SA established);
> EVENT_SA_REPLACE in 385s; newest IPSEC; eroute owner
> 000 #3: "host-host" esp.d31d7ed4@10.10.10.5
> <mailto:esp.d31d7ed4@10.10.10.5> (0 bytes) esp.bab02f6d@10.10.10.2
> <mailto:esp.bab02f6d@10.10.10.2> (0 bytes); tunnel
> 000 #2: "host-host" STATE_QUICK_I2 (sent QI2, IPsec SA established);
> EVENT_SA_EXPIRE in 164s
> 000 #2: "host-host" esp.fb533e8b@10.10.10.5
> <mailto:esp.fb533e8b@10.10.10.5> (0 bytes) esp.dce7c743@10.10.10.2
> <mailto:esp.dce7c743@10.10.10.2> (0 bytes); tunnel
> 000 #1: "host-host" STATE_MAIN_I4 (ISAKMP SA established);
> EVENT_SA_REPLACE in 85740s; newest ISAKMP
> 
> /*This I took after the first IPSEC SA which was established the time of
> 377s was elapsed. A new IPSec SA was established with the time showing
> 385s. The previous IPSec SA says expire in 164s.
> 
> */Now, I am not sure how these values are being calculated.
> Would it be possible for you to put working logs for rekeying in
> wiki.strongswan so that i can refer.
> 
> btw, i am using 4.3.4 ver strongswan. I hope there are no patches
> related to rekeying for this version. If there are, please let me know.
> 
> I am sorry to put up some many questions.
> 
> Thanks & Regards,
> Ashish.

-- 
======================================================================
Andreas Steffen                         andreas.steffen@strongswan.org
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
[prev in list] [next in list] [prev in thread] [next in thread] 