[strongSwan-dev] Understanding IKEv1 rekey

[Noam Lampert]

>
> > 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 <tobias at strongswan.org>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20160822/eda5c1e5/attachment.html>