> > > My question: How is the Cisco ASR supposed to know that the old IKE SA > > is no longer relevant? > Because it is deleted?
How is the peer supposed to know that it is deleted if it doesn't receive a DELETE message? On Mon, Aug 22, 2016 at 12:16 PM, Tobias Brunner <[email protected]> wrote: > 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
