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" [email protected] > <mailto:[email protected]> (0 bytes) [email protected] > <mailto:[email protected]> (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" [email protected] > <mailto:[email protected]> (0 bytes) [email protected] > <mailto:[email protected]> (0 bytes); tunnel > 000 #2: "host-host" STATE_QUICK_I2 (sent QI2, IPsec SA established); > EVENT_SA_EXPIRE in 164s > 000 #2: "host-host" [email protected] > <mailto:[email protected]> (0 bytes) [email protected] > <mailto:[email protected]> (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 [email protected] 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 [email protected] https://lists.strongswan.org/mailman/listinfo/users
