[strongSwan-dev] problem with a cisco891 after reauthentication

[SM K]

Hi Tobias, Andreas,

Thank you for your reply. I have a few more questions inline.


On Tue, Apr 14, 2015 at 5:32 AM, Tobias Brunner <tobias at strongswan.org>
wrote:

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


Just to make sure I understand what is expected of IKEv1 connections,
(sorry I had to ask again)
Are IKEv1s are expected to break all connections before making a new one?
Or
Are they expected to make a new one before breaking the old one.
I have seen Juniper firewalls and Cisco ASA make a new one before
terminating an old one.



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



I was thinking of two ways to workaround this, the first being similar to
what you suggest. Please let me know your opinion.
1. Ignore an Phase 1 delete if it still has phase2s. This is for IKEv1 only
since we are testing with ikev1 firewalls only.
2. Instead of silently deleting Phase2s, do a proper delete that sends out
a DELETE to the other side. Would this be difficult to implement?


regards,
SK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20150414/d2e20fbe/attachment-0001.html>