[strongSwan-dev] Understanding IKEv1 rekey

[Tobias Brunner]

Hi Noam,

> We are having integration problems with Cisco ASR on IKEv1 that appear
> only during IKE rekey.

Why not use IKEv2?

> My question: How is the Cisco ASR supposed to know that the old IKE SA
> is no longer relevant? 

Because it is deleted?  Rekeying in IKEv1 is done by creating a new
IKE_SA and deleting the old one afterwards (we typically call this
reauthentication, even though some clients don't do full authentication
rounds - the whole process is not really standardized, though, see [1]
for some pointers).  All CHILD_SAs are thereafter managed by the new
IKE_SA.  There is, however, no strong ownership model as in IKEv2 (or in
our implementation).  IPsec SAs negotiated with IKEv1 could
theoretically also exist without any active IKE_SAs.  And since there is
no signaling that the new IKE_SA is intended to rekey an existing one
some heuristics might be required to detect that.  In strongSwan
identities, IPs and ports are compared and if a match is found CHILD_SAs
are migrated to the new one.  Other implementations seem to just always
use the latest IKE_SA between two endpoints to manage CHILD_SAs.  How
Cisco devices handle this I don't know, but it seems the rekeying wasn't
detected in this particular case for some reason.

Regards,
Tobias

[1] https://tools.ietf.org/html/draft-jenkins-ipsec-rekeying-06#section-3