<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="font-size:12.8px">> My question: How is the Cisco ASR supposed to know that the old IKE SA<br></span><span class="gmail-im" style="font-size:12.8px">> is no longer relevant?</span><span class="gmail-im" style="font-size:12.8px"><br></span><span style="font-size:12.8px">Because it is deleted? </span></blockquote><div>How is the peer supposed to know that it is deleted if it doesn't receive a DELETE message?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 22, 2016 at 12:16 PM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Noam,<br>
<span class=""><br>
> We are having integration problems with Cisco ASR on IKEv1 that appear<br>
> only during IKE rekey.<br>
<br>
</span>Why not use IKEv2?<br>
<span class=""><br>
> My question: How is the Cisco ASR supposed to know that the old IKE SA<br>
> is no longer relevant?<br>
<br>
</span>Because it is deleted?  Rekeying in IKEv1 is done by creating a new<br>
IKE_SA and deleting the old one afterwards (we typically call this<br>
reauthentication, even though some clients don't do full authentication<br>
rounds - the whole process is not really standardized, though, see [1]<br>
for some pointers).  All CHILD_SAs are thereafter managed by the new<br>
IKE_SA.  There is, however, no strong ownership model as in IKEv2 (or in<br>
our implementation).  IPsec SAs negotiated with IKEv1 could<br>
theoretically also exist without any active IKE_SAs.  And since there is<br>
no signaling that the new IKE_SA is intended to rekey an existing one<br>
some heuristics might be required to detect that.  In strongSwan<br>
identities, IPs and ports are compared and if a match is found CHILD_SAs<br>
are migrated to the new one.  Other implementations seem to just always<br>
use the latest IKE_SA between two endpoints to manage CHILD_SAs.  How<br>
Cisco devices handle this I don't know, but it seems the rekeying wasn't<br>
detected in this particular case for some reason.<br>
<br>
Regards,<br>
Tobias<br>
<br>
[1] <a href="https://tools.ietf.org/html/draft-jenkins-ipsec-rekeying-06#section-3" rel="noreferrer" target="_blank">https://tools.ietf.org/html/<wbr>draft-jenkins-ipsec-rekeying-<wbr>06#section-3</a><br>
</blockquote></div><br></div>