[strongSwan] Charon IKEv1 rekeying?

[Gerald Richter - ECOS]

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:martin at strongswan.org]
> Gesendet: Mittwoch, 20. Februar 2013 09:37
> An: Gerald Richter - ECOS
> Cc: users at lists.strongswan.org
> 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.