[Openswan Users] keeping SA made OCF resource leak

[Martin Schiller]

----- Original Message ----- 
From: "David McCullough"
Sent: Friday, July 31, 2009 12:53 AM


> That is correct.  AFAICT now,  pluto is not releasing all the SA's correctly
> on a rekey,  still working through it.

I've got a similar problem here since I have updated from openswan 2.4.14 to 2.6.22:

When I set up (ipsec auto --up) a very simply MainMode PSK connection between 2 machines, I am 
getting the following output:

root:~# ipsec spi
tun0x1001 at 10.1.3.28 IPIP: dir=out src=10.1.4.165 life(c,s,h)=addtime(2,0,0) natencap=none natsport=0 
natdport=0 refcount=2 ref=1 refhim=0 reftable=0 refentry=1
tun0x1002 at 10.1.4.165 IPIP: dir=in  src=10.1.3.28 policy=192.168.28.0/24->192.168.165.0/24 
flags=0x8<> life(c,s,h)=addtime(2,0,0) natencap=none natsport=0 natdport=0 refcount=3 ref=3 refhim=1 
reftable=0 refentry=3
esp0x54151c68 at 10.1.4.165 ESP_AES_HMAC_SHA1: dir=in  src=10.1.3.28 iv_bits=128bits 
iv=0x574f2a911105bab302e3e52117b0f6ad ooowin=64 alen=160 aklen=160 eklen=128 
life(c,s,h)=addtime(2,0,0) natencap=none natsport=0 natdport=0 refcount=2 ref=4 refhim=1 reftable=0 
refentry=4
esp0x4d313dc7 at 10.1.3.28 ESP_AES_HMAC_SHA1: dir=out src=10.1.4.165 iv_bits=128bits 
iv=0xf8fb7431dd25d6b8e1b0bc69dc2fd179 ooowin=64 alen=160 aklen=160 eklen=128 
life(c,s,h)=addtime(2,0,0) natencap=none natsport=0 natdport=0 refcount=3 ref=2 refhim=0 reftable=0 
refentry=2

When I then do an ipsec auto --down (on the initiator side) and check the output of ipsec spi once 
again, I can see that:

root:~# ipsec spi
tun0x1001 at 10.1.3.28 IPIP: dir=out src=10.1.4.165 life(c,s,h)=addtime(6,0,0) natencap=none natsport=0 
natdport=0 refcount=2 ref=1 refhim=0 reftable=0 refentry=1
tun0x1002 at 10.1.4.165 IPIP: dir=in  src=10.1.3.28 policy=192.168.28.0/24->192.168.165.0/24 
flags=0x8<> life(c,s,h)=addtime(6,0,0) natencap=none natsport=0 natdport=0 refcount=2 ref=3 refhim=1 
reftable=0 refentry=3

And if i wait some time, so that there could happen some rekeyings, the amount of tun* SAs are 
increasing but none is ever deleted.

So, It seems to me that tun* SAs will never be deleted in general.

That wasn't so in the openswan 2.4.x releases and I think it has something to to with the way the 
SAs are deleted in the ipsec_sa_rm() function.
In 2.4.x there was an ipsec_sa_delchain() instead, in which you can find the following code

 while(ips->ips_onext != NULL) {
  ips = ips->ips_onext;
 }

where ips_onext points the the previous entry in the chain.

If I am right, this means that we are jumping to the first entry in the chain before we start 
removing SAs.
I cannot find an equivalent of this in the 2.6.x code.

Regards,
Martin