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 <[email protected]> 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
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
