Issue #357
Lifetime in case of IKEv1
Description
Lifetime of SA is not negotiated in case of IKEv2 but is negotiated in case of IKEv1. [RFC4306, 2.8]
However strongswan 5.0.4 does not schedule rekeying based on negotiated lifetime also in case of IKEv1.
For example: strongswan-A establishes IPsec SA with strongswan-B with IKEv1.
*strongswan-A
lifetime=20m
*strongswan-B
lifetime=30m
In such case, lifetime=20m is negoticated. But strongswan-B schedules rekeying in 30m.
This interpretation cases no problem when strongswan is used in both site. After 20m, DELETE message will be sent from strongswan-A and strongswan-A deletes SA base on the message.
But when other IPsec implementation is used in another site, this implementation cases a problem.
In case of IKEv1, an implementation may not send DELETE message and may ignore DELETE message. [RFC2408, 3.15]
For example: another site using other IPsec implementation establishes IPsec SA with strongswan-B with IKEv1.
*other implemetaion
lifetime=20m
*strongswan-B
lifetime=30m
In such case, lifetime=20m is negoticated. But strongswan-B schedules rekeying in 30m. After 20m, other implemenation delete SA without DELETE message.
But because strongswan-B schedules rekeying in 30m, transmitting from strongswan-B falls until 30m.
Such implementation is observed in some embedded IPsec equipment.
Can strongswan schedule rekeying based on negoticated lifetime in case of IKEv1?
History
#1 Updated by Noam Lampert over 5 years ago
I think that the source of the bug is that quick_mode.c does successfully negotiate in full the lifebytes/lifetime, but doesn't pass them to child_sa->install(). Rather, child_sa->install() takes these parameters from the config.
This is true as of release 5.3.1dr1 branch.