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