ipsec setup many SAs when rekey_time is less than reauth_time with IKE1

[rondyning]

System (please complete the following information):

• OS: Ubuntu 20.04.2
• Kernel version (if applicable): 5.15.0-79
• strongSwan version(s): 5.9.11
• Tested/confirmed with the latest version: yes

Describe the bug
I have too devices and they are running in net-net mode, and the ike version is 1 in conf files.
Config the rekey_time in children less than reauth_time in connections
Such as:
rekey_time = 60
reauth_time = 120

After about one hour, you can see many SAs with "swanctl --list-sas"
Please see the logs in Logs/Backtraces

To Reproduce
Steps to reproduce the behavior:

1. Please see the conf in the below:
   connections {
   test {
   local_addrs = 192.168.61.220
   remote_addrs = 192.168.61.110

   local {
   auth = psk
   id = 192.168.61.220
   }
   remote {
   auth = psk
   id = 192.168.61.110
   }
   children {
   client {
   remote_ts = 192.168.92.0/24
   local_ts = 192.168.91.0/24
   rekey_time = 60
   updown = /usr/local/libexec/ipsec/_updown iptables
   #esp_proposals = aes128gcm128
   }
   }
   version = 1
   reauth_time = 120
   mobike = no
   #proposals = aes128gcm128-prfsha1
   }
   }

secrets {

ike-gw {
#id = 192.168.51.11
secret = 789123
}
}

2. sudo swanctl --initiate --ike test
3. sudo swanctl --initiate --child client
4. After one hour, check ths SAs with "swanctl --list-sas", we can see many SAs

Expected behavior
Will observe many SAs with swanctl --list-sas
It's not correct, we should only observe one SA

Logs/Backtraces

nyl@ubuntu:/usr/local/etc/swanctl/conf.d$ sudo swanctl --list-sas
test: #74, ESTABLISHED, IKEv1, 6dc6c1da357d0edc_i 008d423bdf9370d0_r*
local '192.168.61.220' @ 192.168.61.220[500]
remote '192.168.61.110' @ 192.168.61.110[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
established 92s ago, reauth in 21s
client: #96, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 53s ago, rekeying in 5s, expires in 13s
in c7d17f66, 0 bytes, 0 packets
out c69ea5e3, 0 bytes, 0 packets
local 192.168.91.0/24
remote 192.168.92.0/24
client: #97, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 53s ago, rekeying in 2s, expires in 13s
in caaa8ac6, 0 bytes, 0 packets
out ce4999b3, 0 bytes, 0 packets
local 192.168.91.0/24
remote 192.168.92.0/24
test: #73, ESTABLISHED, IKEv1, 3c4477cec21195b4_i* 020cb2485e00a4a7_r
local '192.168.61.220' @ 192.168.61.220[500]
remote '192.168.61.110' @ 192.168.61.110[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
established 96s ago, reauth in 22s
client: #98, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 51s ago, rekeying in 5s, expires in 15s
in cb331b22, 0 bytes, 0 packets
out c36481f4, 0 bytes, 0 packets
local 192.168.91.0/24
remote 192.168.92.0/24
test: #72, ESTABLISHED, IKEv1, bbd20423ae53e8dc_i* e592dbaa14a908cc_r
local '192.168.61.220' @ 192.168.61.220[500]
remote '192.168.61.110' @ 192.168.61.110[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
established 97s ago, reauth in 20s
client: #94, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 57s ago, rekeying in 1s, expires in 9s
in c3410c2b, 0 bytes, 0 packets
out c75dd148, 0 bytes, 0 packets
local 192.168.91.0/24
remote 192.168.92.0/24
test: #71, ESTABLISHED, IKEv1, 168f811b3d92781b_i b3f0f9d18a5eec08_r*
local '192.168.61.220' @ 192.168.61.220[500]
remote '192.168.61.110' @ 192.168.61.110[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
established 101s ago, reauth in 11s
client: #99, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 45s ago, rekeying in 9s, expires in 21s
in c8e7f2ca, 0 bytes, 0 packets
out cea9b06d, 0 bytes, 0 packets
local 192.168.91.0/24
remote 192.168.92.0/24
test: #70, ESTABLISHED, IKEv1, 9e360c8f51995e4b_i 8462fef069f0b5fa_r*
local '192.168.61.220' @ 192.168.61.220[500]
remote '192.168.61.110' @ 192.168.61.110[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
established 105s ago, reauth in 15s
client: #100, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 43s ago, rekeying in 13s, expires in 23s
in c4e31e80, 0 bytes, 0 packets
out cdff2313, 0 bytes, 0 packets
local 192.168.91.0/24
remote 192.168.92.0/24
test: #69, ESTABLISHED, IKEv1, 53e97ab3b314b900_i f65d06434fd4b557_r*
local '192.168.61.220' @ 192.168.61.220[500]
remote '192.168.61.110' @ 192.168.61.110[500]
AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
established 105s ago, reauth in 4s
client: #95, reqid 1, REKEYED, TUNNEL, ESP:AES_GCM_16-128
installed 55s ago, rekeying in 1s, expires in 11s
in cff83307, 0 bytes, 0 packets
out cb291ad3, 0 bytes, 0 packets
local 192.168.91.0/24
remote 192.168.92.0/24
client: #101, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-128
installed 1s ago, rekeying in 55s, expires in 65s
in c2536749, 0 bytes, 0 packets
out cb5b241c, 0 bytes, 0 packets
local 192.168.91.0/24
remote 192.168.92.0/24
Additional context
None

[tobiasbrunner]

I have too devices and they are running in net-net mode, and the ike version is 1 in conf files.

Please never use IKEv1 between two strongSwan installations. If the other implementation is not strongSwan, note that IKEv1 is deprecated, so please stop using it anyway.

Config the rekey_time in children less than reauth_time in connections

Rekeying in IKEv1 is certainly ugly (there is no proper rekeying), so all kinds of things could get messed up with low life times that cause collisions.

After about one hour, you can see many SAs with "swanctl --list-sas"

Note that some of them are created by the peer. So it could very well be that there were collisions.

Please see the logs in Logs/Backtraces

I don't see any logs.