[strongSwan-dev] problem with a cisco891 after reauthentication

[Tobias Brunner]

Hi,

> I notice the problem when the cisco attempts reauthentication of phase1.
> It seems that the existing phase1 is first down-ed before the new one is
> created. In most other firewalls, i see that a new phase1 is created
> before the old one is killed. 

Yes, charon does that too when reauthenticating IKEv1 SAs.  For IKEv2 we
do what the Cisco box does and first terminate the existing IKE SA
before recreating it with all CHILD_SAs.  That's where 5.3.0 with its
optional make-before-break reauthentication comes in (as mentioned by
Andreas).  But that's irrelevant for IKEv1 as we did this all along.
However, it's also how we expect other IKEv1 implementations to
reauthenticate SAs.

> The problem with how the cisco891 does this is that when phase1 that is
> being reauthenticated is deleted, the phase2s are also killed on
> strongswan.

Yes, CHILD_SAs in charon are strictly associated with an IKE_SA, that
is, they can't exist without one (possible that pluto handled this
differently).  So when the IKE_SA with a peer is closed its CHILD_SAs
are destroyed too (there are no DELETES sent for them because we act on
the request of the other peer).

> Is there anyway to workaround this in strongswan? 

I suppose you could change the process_r() method of the isakmp_delete_t
task so that DELETES for ISAKMP SAs are ignored (i.e. simply return
SUCCESS without doing anything else there).  That way the original SA
and its CHILD_SAs are not closed but a reauthentication should still be
detected when the Cisco box creates the new SA (the old CHILD_SAs are
then adopted and the original IKE_SA gets closed).  The only
disadvantage is that IKE_SAs can't be closed by peers anymore.

Regards,
Tobias