[strongSwan] Reporting Issue:Old CHILD_SA not getting cleared

[Tobias Brunner]

Hi Anurag,

> We would still want to understand that what happens if I want the
> reauth to happen [reauth=yes] each time for the IKE_SA. In such a
> case there is always a possibility that during the downtime of the
> IKE_SA, traffic matching the installed policies will trigger a new
> CHILD_SA to be created. By setting the reauth=no we are blocking this
> issue. Don't you think that this is some kind of limiting factor in
> the way we can exploit the facilities provided by charon?

Let me give you some context regarding reauthentication and the reauth
option.  For IKEv1 reauthentication is the only way to actually rekey an
IKE_SA (ISAKMP SA), so for IKEv1 reauth=no has no meaning.  Then for
some reason reauth=yes was chosen to be the default for the newly
developed IKEv2 daemon too (and it stayed that way ever since).
Now, while RFC 5996 (IKEv2) does mention reauthentication it does not
really define how it can be done properly.  The RFC does recommend to
establish the new IKE_SA before tearing down the old one but this leads
to all sorts of problems with duplicate IPsec SAs, virtual IP addresses,
potential for collisions etc.  So we decided to do IKEv2
reauthentication by first deleting the old and then reestablishing the
new IKE_SA.  This leads to the observed downtime and the problems if
auto=route is configured.

The question you want to ask yourself is whether you actually need
reauthentication or not.  It makes sense in situations where you want to
ensure a peer has still access to its long term secret, for instance, if
smart cards are used.  In such situations, where the secret is not
directly available to the daemon, auto=route makes rarely sense as some
kind of user interaction is required anyway.
However, another reason for reauthentication could be to periodically
verify the validity of a certificate.  Because without that a peer could
keep an IKE_SA open even if the certificate is later revoked or has
expired.  The peer could even rekey the IKE_SA regularly as the validity
of its credentials is currently only verified during authentication.
This is a situation where auto=route could be an option but you have to
consider the interval in which it makes sense to reauthenticate the peer
- probably not that often.  Also, there are other means for gateways to
enforce regular reauthentication of a peer.  For instance, by closing
IKE_SAs after they have been rekeyed a pre-defined number of times (a
custom plugin could determine that) then with auto=route set on the
clients the SAs would automatically be reestablished when traffic
requires it - with full authentication.

Anyway, I guess if you really require support for reauth=yes|auto=route
we could try to add it.  But I'm not sure how difficult that would be
and if it is actually worth the effort.

Regards,
Tobias