[strongSwan-dev] Rekey Question

[Daniel Migault]

Hi,

Thanks for the response.

Actually we were wondering if it is possible to only have a IKE_SA 
rekeying without rekeying also the associated CHILD_SA.

BR,
Daniel


On 07/26/2013 10:31 AM, Martin Willi wrote:
> Hi Daniel,
>
>> Looking at the logs, it looks that all CHILD_SA attached to the IKE_SA
>> are rekeyed and removed with Delete Payload, but the IKE_SA does not
>> seems to be deleted with Delete Payloads. On the other hand ipsec
>> statusall does not shows the old IKE_SA.
> I can't reproduce this, IKE_SAs get properly deleted after rekeying
> here. When using reauth=no and short lifetimes I see:
>
> CHILD_SA rekeying:
>
>> 04[KNL] creating rekey job for ESP CHILD_SA with SPI c29d17c1 and reqid {1}
>> 04[IKE] establishing CHILD_SA c1{1}
>> 04[ENC] generating CREATE_CHILD_SA request 4 [ N(REKEY_SA) SA No TSi TSr ]
>> 04[NET] sending packet: from 192.168.0.1[4500] to 192.168.0.2[4500] (348 bytes)
>> 02[NET] received packet: from 192.168.0.2[4500] to 192.168.0.1[4500] (204 bytes)
>> 02[ENC] parsed CREATE_CHILD_SA response 4 [ SA No TSi TSr ]
>> 02[IKE] CHILD_SA c1{1} established with SPIs c8c5960a_i cc7ffde7_o and TS 10.3.0.1/32 === 10.2.0.0/16
>> 02[IKE] closing CHILD_SA c1{1} with SPIs c29d17c1_i (0 bytes) ceb69bae_o (0 bytes) and TS 10.3.0.1/32 === 10.2.0.0/16
>> 02[IKE] sending DELETE for ESP CHILD_SA with SPI c29d17c1
>> 02[ENC] generating INFORMATIONAL request 5 [ D ]
>> 02[NET] sending packet: from 192.168.0.1[4500] to 192.168.0.2[4500] (76 bytes)
>> 20[NET] received packet: from 192.168.0.2[4500] to 192.168.0.1[4500] (76 bytes)
>> 20[ENC] parsed INFORMATIONAL response 5 [ D ]
>> 20[IKE] received DELETE for ESP CHILD_SA with SPI ceb69bae
>> 20[IKE] CHILD_SA closed
> IKE_SA rekeying:
>
>> 01[IKE] initiating IKE_SA c1[2] to 192.168.0.2
>> 01[ENC] generating CREATE_CHILD_SA request 6 [ SA No KE ]
>> 01[NET] sending packet: from 192.168.0.1[4500] to 192.168.0.2[4500] (716 bytes)
>> 14[NET] received packet: from 192.168.0.2[4500] to 192.168.0.1[4500] (428 bytes)
>> 14[ENC] parsed CREATE_CHILD_SA response 6 [ SA No KE ]
>> 14[IKE] scheduling rekeying in 5s
>> 14[IKE] maximum IKE_SA lifetime 10s
>> 14[IKE] IKE_SA c1[2] rekeyed between 192.168.0.1[C=CH, O=strongSwan, CN=moon]...192.168.0.2[C=CH, O=strongSwan, CN=sun]
>> 14[IKE] rescheduling reauthentication in 10204s after rekeying, lifetime reduced to 10209s
>> 14[IKE] deleting IKE_SA c1[1] between 192.168.0.1[C=CH, O=strongSwan, CN=moon]...192.168.0.2[C=CH, O=strongSwan, CN=sun]
>> 14[IKE] sending DELETE for IKE_SA c1[1]
>> 14[ENC] generating INFORMATIONAL request 7 [ D ]
>> 14[NET] sending packet: from 192.168.0.1[4500] to 192.168.0.2[4500] (76 bytes)
>> 11[NET] received packet: from 192.168.0.2[4500] to 192.168.0.1[4500] (76 bytes)
>> 11[ENC] parsed INFORMATIONAL response 7 [ ]
>> 11[IKE] IKE_SA deleted
>
>> If strongswan does not support an IKE_SA REKEY, I would like to know
>> if there are any reasons for that, or if it just not yet implemented.
> IKE_SA rekeying is fully supported, and has been for many, many years.
>
> Best Regards
> Martin
>