Hi, during the debugging of IKEv1 rekeying I found out that the old IKE_SA gets deleted before the new on is fully established.
In the file ike_sa_manager.c in the method check_uniqueness in line 1825 (status = duplicate->delete(duplicate);) the duplicate ike_sa is immediately deleted, that happens before the other side get noticed that the new ike_sa is established. For this reason the other side (in my case a Cisco ASA) deletes the whole ipsec connection, because there is no valid ike_sa at this time. If I remove line 1825, so the ike_sa is not deleted locally, but is deleted later on when the other side sends a delete notification, that everything works fine. So from my point of view the local deletion of the ike_sa needs to be delayed after the new ike_sa is fully established. Any comments? Regards Gerald P.S. I did't found a simple way to get this done, so I don't have a patch. > -----Ursprüngliche Nachricht----- > Von: Martin Willi [mailto:[email protected]] > Gesendet: Mittwoch, 20. Februar 2013 09:37 > An: Gerald Richter - ECOS > Cc: [email protected] > Betreff: Re: [strongSwan] Charon IKEv1 rekeying? > > Hi Gerald, > > > to me it seems that charon (5.0.1) does not support phase 1 rekeying > > at all? > > It does. However, strictly speaking, there is no such thing as Phase 1 > rekeying > (as it exists in IKEv2). ISAKMP SAs get reestablished from scratch to replace > the old one. > > charon was initially designed for IKEv2, which strictly associates CHILD_SAs > to > IKE_SAs. We handle things the same way in IKEv1, even this is not really true > (Quick Modes can theoretically exist without ISAKMP SA). Therefore we > must take care to migrate Quick Modes to the newest ISAKMP SA. > > > The rekeying is initiated, but is not recongized by the other side, so > > the IKE expires. > > There is actually no way to "recognize" an ISAKMP reauthentication. It looks > exactly the same as an initial connection attempt. > > > Maybe I am totally wrong, but I even were not able to find the > > rekeying code in the source for ikev1 (I have seen it for ikev2). > > It is true that there is no ISAKMP rekeying code, as said, strictly speaking > that > concept doesn't exist in IKEv1. We implement the > reestablishement/reauthentication of ISAKMP SAs, but that uses the same > tasks as the initial connection setup. > > > deleting duplicate IKE_SA for peer 'DC=test, DC=testuml, > > OU=Zertifikate, CN=ipsec cert' due to uniqueness policy > > > If I add " uniqueids = no" to the ipsec.conf, it works, but this was > > never necessary in the past. > > This is indeed an issue: ISAKMP reauthentication does not properly migrate > children from the replaced to the new SA. This is required when having a > unique policy. I pushed two changes to [1] fixing this issue. > Let me know if this works for you. > > The same would apply to a uniqueids=keep policy; we'd somehow have to > detect this is a reauth, and then accept the connection attempt. > Probably some heuristics based on lifetime could work. > > Regards > Martin > > [1]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/ik > ev1-rekeying > > PS: If your run charon on both ends, I'd recommend to switch to IKEv2. > It is just the better protocol. _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
