[strongSwan-dev] Understanding IKEv1 rekey

[Noam Lampert]

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

At rekey time strongswan successfully initiates and negotiates a new IKE
SA, and after 10 seconds strongswan silently deletes the old IKE SA causing
DPD failures on the old IKE SA. The confuses the Ciscso ASR, eventually
causing it to delete the child SAs and the new IKE SA.

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

Is it possible that the intention was to delete the IKE SA after it is
totally expired, and the '10' value should really be
peer_cfg->get_over_time() ? Even if so, shouldn't strongswan still not send
a delete message?

A few pointers in the code:
* ike_sa->delete() for a IKE SA that is rekeyed silently deletes itself:
https://github.com/strongswan/strongswan/blob/master/src/libcharon/sa/ike_sa.c#L1786
(note the 'break' and return DESTROY_ME).
* The decision to delete 10 seconds after negotiating the new IKE SA is
taken here:
https://github.com/strongswan/strongswan/blob/master/src/libcharon/sa/ike_sa_manager.c#L1908

Noam

[Tobias Brunner]

Hi Noam,

Post by Noam Lampert
We are having integration problems with Cisco ASR on IKEv1 that appear
only during IKE rekey.

Why not use IKEv2?

Post by 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? 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

[Noam Lampert]

Post by Tobias Brunner

Post by 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?

Post by Tobias Brunner
Hi Noam,

Post by Noam Lampert
We are having integration problems with Cisco ASR on IKEv1 that appear
only during IKE rekey.

Why not use IKEv2?

Post by 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? 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

[Tobias Brunner]

Hi Noam,

Post by Tobias Brunner

Post by 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?

It doesn't send one? I suppose that's problematic (however, DELETES in
IKEv1 are not really reliable anyway).

Regards,
Tobias

[Noam Lampert]

Strongswan does not send a DELETE.
Here is the pointer where Strongswan decides not to send a DELETE.
ke_sa->delete() for a IKE SA that is rekeyed silently deletes itself:
https://github.com/strongswan/strongswan/blob/master/src/libcharon/sa/ike_
sa.c#L1786 (note the 'break' and return DESTROY_ME).

Post by Tobias Brunner
Hi Noam,

Post by Tobias Brunner

Post by Noam Lampert
My question: How is the Cisco ASR supposed to know that the old

IKE SA

Post by Tobias Brunner

Post by Noam Lampert
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?

It doesn't send one? I suppose that's problematic (however, DELETES in
IKEv1 are not really reliable anyway).
Regards,
Tobias

[Tobias Brunner]

Hi Noam,

Post by Noam Lampert
Strongswan does not send a DELETE.

Yeah, according to the message of the commit that added that break
statement (3a0b67bce5) the idea was to just wait for the SA to expire
(it doesn't really explain why the break was added and the peer is not
notified about the deletion). The duplicate check that was added later
kills the SA after 10 seconds now. Perhaps the break was added to avoid
the alert if the SA expired, or the ike_updown() event (which has since
been added) - with strongSwan a notification wasn't required anyway as
it automatically deletes the old IKE_SA as responder of a rekeying.
But I think notifying the peer that the SA was deleted makes definitely
sense. If deleting it after 10 seconds is a problem (e.g. because the
DELETE is regularly dropped) we could probably also change that so SAs
are not killed until they actually expire (as responder or initiator of
the rekeying). But since strongSwan does not negotiate SA lifetimes and
always uses its own configuration that deletion will not be synced with
the peer, which could cause problems later if a peer did not receive the
delete and has a longer lifetime and still uses the SA.

I pushed a change that removes the break statement to the
ikev1-rekey-deletion branch.

Regards,
Tobias

[Noam Lampert]

Thanks, I am optimistic about this working.

Post by Tobias Brunner
Hi Noam,

Post by Noam Lampert
Strongswan does not send a DELETE.

Yeah, according to the message of the commit that added that break
statement (3a0b67bce5) the idea was to just wait for the SA to expire
(it doesn't really explain why the break was added and the peer is not
notified about the deletion). The duplicate check that was added later
kills the SA after 10 seconds now. Perhaps the break was added to avoid
the alert if the SA expired, or the ike_updown() event (which has since
been added) - with strongSwan a notification wasn't required anyway as
it automatically deletes the old IKE_SA as responder of a rekeying.
But I think notifying the peer that the SA was deleted makes definitely
sense. If deleting it after 10 seconds is a problem (e.g. because the
DELETE is regularly dropped) we could probably also change that so SAs
are not killed until they actually expire (as responder or initiator of
the rekeying). But since strongSwan does not negotiate SA lifetimes and
always uses its own configuration that deletion will not be synced with
the peer, which could cause problems later if a peer did not receive the
delete and has a longer lifetime and still uses the SA.
I pushed a change that removes the break statement to the
ikev1-rekey-deletion branch.
Regards,
Tobias

[Tobias Brunner]

Hi Avinoam,

I check this branch and there is an another issue.

When did you check the branch? I pushed a commit that fixes the task
activation issue nearly two weeks ago. You might want to fetch the
current version of the branch (also see [1]).

Regards,
Tobias

[1] https://wiki.strongswan.org/issues/2090

[Avinoam Meir]

Sorry, I didn't notice the 2 last commits in the branch.

Thanks.

Post by Tobias Brunner
Hi Avinoam,

I check this branch and there is an another issue.

When did you check the branch? I pushed a commit that fixes the task
activation issue nearly two weeks ago. You might want to fetch the
current version of the branch (also see [1]).
Regards,
Tobias
[1] https://wiki.strongswan.org/issues/2090