[Openswan Users] Regarding the life time for IKE SA and

[Shi Lang]

Thanks Peter,

I agree yours.

Here at Microsoft
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Serve
rHelp/ec4bc2a7-3e89-48c1-a16c-7dab4a2a1190.mspx
They also discuss about the IKE 8 hours, and IPsec SA 1 hour. It gives
details example.

I am going to test your case later on, any result come, will let you know.

Regards,
 
Shi Lang
Quality Assurance Engineer
GreenPacket Bhd
www.greenpacket.com 
Tel: 006-03-89966022 ext: 105

-----Original Message-----
From: Peter McGill [mailto:petermcgill at goco.net] 
Sent: Thursday, January 19, 2006 1:46 AM
To: shilang at greenpacket.com
Cc: users at openswan.org
Subject: RE: [Openswan Users] Regarding the life time for IKE SA and

Shi Lang:
> Regarding the life time for IKE SA and IPsec SA, openswan seems that the
> default values are:
> IKE sa: 1 hour
> IPsec sa: 8 hour
>
> But when I refer to other document, even like Microsoft ipsec, the default
> values are:
> IKE sa: 8 hour
> IPsec sa: 1 hour

> You said "however it did cause an inter-op problem with a Nortel switch,"
> Can you explain it more details?

Sure,
I discussed it in my "One Hour Disconnect?" thread/topic, Dec 15-20, 2005.
To summarize,

My Setup: OpenSWAN 2.4.4 on Linux Kernel 2.4.31
/etc/ipsec.conf:
version 2.0

config setup
 interfaces=%defaultroute
 uniqueids=yes

include /etc/ipsec.d/examples/no_oe.conf

conn sunoco-172-16-19-net-to-london-office-net
 left=66.11.74.93
 leftnexthop=%defaultroute
 leftsubnet=172.21.0.0/16
 alsoflip=sunoco-toronto
 rightsubnet=172.16.0.0/14
 auto=route

conn sunoco-192-168-net-to-london-office-net
 left=66.11.74.93
 leftnexthop=%defaultroute
 leftsubnet=172.21.0.0/16
 alsoflip=sunoco-toronto
 rightsubnet=192.168.0.0/16
 auto=route

conn sunoco-toronto
 left=199.212.129.226
 leftnexthop=%defaultroute
 also=sunoco

conn sunoco
 # keyexchange=ike
 # aggrmode=no
 # auth=esp
 # 3des-md5-modp1024
 ike=3des
 esp=3des
 # pfs=yes
 # ikelifetime=1.0h
 # keylife=8.0h
 # rekey=yes
 # compress=yes
 compress=no
 # keyingtries=%forever
 keyingtries=3
 dpddelay=30
 dpdtimeout=120
 # dpdaction=hold
 dpdaction=clear
 authby=secret
End: /etc/ipsec.conf

My Business Partner's Setup: Nortel Contivity VPN Switch (1700 I think)
Branch Office:
Group:
 Connectivity:
 Idle Timeout: 00:00:00 (none)
 IPsec:
 Encryption:
 - ESP - Triple DES with MD5 Integrity: Enabled
 IKE Encryption and Diffie-Hellman Group: Triple DES with Group 2 (1024-bit
prime)
 Aggressive Mode ISAKMP Initial Contact Payload: Disabled
 Perfect Forward Secrecy: Enabled
 Compression: Disabled
 Rekey Timeout: 08:00:00 (8 hours)
Connection Configuration:
 Text Pre-Shared Key
 Local Networks:
 172.21.16.0, 255.252.0.0
 192.168.0.0, 255.255.0.0

Results:
I would initiate the on demand (route) connection, by accessing a website on
the far side of the tunnel. The connection would establish, and work fine
for a while.
At about 45-50 minutes into the connection, the ESP tunnel (phase 2) would,
renegotiate the key; the connection would continue working as expected.
Tested with same website.
At 1 hour after the connection was first established, the Nortel box would,
terminate the connection, like this:
Dec 14 11:40:32 sheridan pluto[31069]: packet from 199.212.129.226:500:
Informational Exchange is for an unknown (expired?) SA
Dec 14 11:40:33 sheridan pluto[31069]: packet from 199.212.129.226:500:
Informational Exchange is for an unknown (expired?) SA
Dec 14 11:43:23 sheridan pluto[31069]:
"sunoco-172-16-19-net-to-london-office-net" #449: received Delete SA
payload: deleting ISAKMP State #449
Dec 14 11:43:23 sheridan pluto[31069]: packet from 199.212.129.226:500:
received and ignored informational message
At this point, I would have to manually force the connection up, via ipsec
auto --up or --route.

With the Nortel, it seems to track connections as follows:
OpenSWAN's IKE (phase 1), Nortel considers the connection (control tunnel).
OpenSWAN's ESP (phase 2), Nortel considers a connected subnet of that
connection.

I have had the following in my ipsec.conf for a month, and it works fine:
ikelifetime=1.0h
keylife=30m
Since it worked, I didn't bother testing other cases, although I had tested
a few that didn't work, before this one, such as ikelifetime=2.0h, and
keylife=8.0h. I also, tried changing most of the other values in the conf,
such as keyingtries, compression and various dpd settings. The results,
for these other tests, were no different.
To be complete, today I set ikelifetime=8.0h, and keylife=1.0h, the
connection has been up for a hour and a half now. If I discover a
problem with this new setting, I'll let you know, but I expect it to be
fine.

My guess is, that in Nortel's case when the ike conn expires, it expires the
esp conn too, since it considers the esp to be a child conn of the ike?
So if in OpenSWAN, keylife < ikelifetime, and ikelifetime <= Nortel's Rekey
Timeout, it should work?
Possibly other venders use this way too?


Peter McGill
Software Developer / Network Administrator
Gra Ham Energy Limited