Project

General

Profile

Issue #357

Lifetime in case of IKEv1

Added by Anonymous about 7 years ago. Updated about 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
libcharon
Affected version:
5.0.4
Resolution:

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 about 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.

Also available in: Atom PDF