[Swan] SA lifetime duration

[Paul Wouters]

On Mon, 11 Feb 2019, Kostya Vasilyev wrote:

>> Usually, watching SAs in Mikrtoik web UI and "ipsec status", there is a
>> tendency to have 4 or even 6 SA's and for them to rotate / expire a few
>> times a day.

It depends on how quickly the endpoints rekey their IPsec and IKE SAs.

>> Feb 11 20:10:29 pluto[4767]: "mytunnel" #300: responding to Main Mode
>> Feb 11 20:10:29 pluto[4767]: "mytunnel" #300: STATE_MAIN_R1: sent MR1,
>> expecting MI2

>> Feb 11 20:10:31 pluto[4767]: "mytunnel" #300: STATE_MAIN_R3: sent MR3,
>> ISAKMP SA established {auth=RSA_SIG cipher=AES_CBC_128
>> integ=HMAC_SHA2_256 group=MODP2048}
>> Feb 11 20:10:31 pluto[4767]: "mytunnel" #300: retransmitting in response
>> to duplicate packet; already STATE_MAIN_R3

Looks like there is some packet loss (congestion?) on the link. Note the
states have an R in it, that means Responding state.

>> Feb 11 20:22:21 pluto[4767]: "mytunnel" #299: deleting state
>> (STATE_MAIN_I4) and sending notification

This is an I state, an initiator state. So you have both endpoints
likely with similar timings, sometimes rekeying at the same time.

>> 000 #290: "mytunnel":500 STATE_QUICK_I2 (sent QI2, IPsec SA
>> established); EVENT_SA_REPLACE in 841s; newest IPSEC; eroute owner;
>> isakmp#289; idle;

Note that IPsec SA is configured to rekey in 841s from that time.

>> 000 #300: "mytunnel":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA
>> established); EVENT_SA_REPLACE in 1661s; newest ISAKMP; lastdpd=17s(seq
>> in:25740 out:0); idle;

And the IKE SA would rekey in 1661 seconds.

>> Now my question:
>>
>> Is this, like, normal? For a single pair of SA's to be used over such
>> long time (days) and not be rotated?

Common are 1-8 hours for IPsec SA, and 8-24h for IKE SA.

>> I thought (mistakenly) that SA's get replaced and part of rekeying process?

Yes they do.

>> Does this  perhaps just mean that my Internet connection is more stable
>> than before?

I did not see any errors, so i cannot see any problems. So I cannot tell
if it is more or less stable than before :)

> And just as I sent the above, there is a new pair of SA's - and a whole new connection (#301)?

Yup, you only had 14 minutes left on the IPsec SA. But remember also
that the remote endpoint can decide to rekey faster. Rekey times are
not negotiated, each endpoint decides on their own.

> Feb 11 20:52:20 pluto[4767]: "mytunnel" #301: initiating Quick Mode RSASIG+ENCRYPT+PFS+UP+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO to replace #290 {using isakmp#300 msgid:9da23ca9 proposal=AES_CBC_128-HMAC_SHA2_256_128-MODP2048 pfsgroup=MODP2048}
> Feb 11 20:52:21 pluto[4767]: "mytunnel" #301: STATE_QUICK_I2: sent QI2, IPsec SA established transport mode {ESP=>0x0ae5a560 <0x6ad1c975 xfrm=AES_CBC_128-HMAC_SHA2_256_128 NATOA=none NATD=none DPD=active}

Since these are I states, you know you initiated to them. So it was your
timer, not theirs, that wanted a rekey.

> 000 #290: "mytunnel":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 496s; isakmp#289; idle;
> 000 #290: "mytunnel" esp.a76f21d at 89.0.0.1 esp.366391ef at 139.0.0.1 ref=0 refhim=0 Traffic: ESPin=553KB ESPout=23MB! ESPmax=4194303B
> 000 #300: "mytunnel":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 708s; newest ISAKMP; lastdpd=10s(seq in:25763 out:0); idle;
> 000 #301: "mytunnel":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 28023s; newest IPSEC; eroute owner; isakmp#300; idle;

So since you _just_ rekeyed, it looks like you have salifetime=500s
which is way shorter than you should have it. Why did you set such
a short lifetime?

> I know the old pair of SA's will expire in a while - and that traffic is using the new pair already.

So since we linger the old states for about 5-15 minutes, I see why you
gain a few old lingering IKE and IPsec states.

> But I'm still curious - what is going on?

Nothing strange, but your timings seem a little overeager :)

> Why are SA's replaced sometimes fast, sometimes slow?

It depends on both endpoints indepedently. There is also a bit of fuzz
added, so that if you have 100 IPsec SA's, they would not all 100 rekey
at exactly the same time.

> Is there an connectivity issue between the client and the server?

Unlikely. The newest IPsec SA is always up, and that is why we linger
the old IPsec SA for a bit to ensure we get all the traffic moved to the
new SA before deleting the old one.

> Maybe they (client / server) can't agree on some sort of refresh interval?

It's not negotiated :)

> Something else?

NO, it really appears you have very short rekey values (ikelifetime / salifetime)

Paul