[strongSwan-dev] ike_updown() call from ike_delete during rekeying

[Martin Willi]

Hi,

> Are there scenarios where the 'rekeyed' check around the ike_updown()
> call in ikev2/tasks/ike_delete.c build_r() is really required?

Yes. After rekeying an IKE_SA, the old one gets deleted using this task.
We don't want to signal ike_updown() in this case, as the IKE_SA has
been rekeyed, not deleted.

> In the cases where the ike_sa was rekeyed successfully, the deleting
> ike_sa will have no child SAs and an ike_updown() call wouldn't
> generate any reports

While the updown plugin listens for CHILD_SA events only, other plugins
are interested in up/down events for the IKE_SA itself. These events can
be used independently, and we really don't want to raise an ike_updown()
event after rekeying (but an ike_rekey() event).

> My client and its peer initiated rekeys simultaneously, but my
> client's request got lost along the way. The peer doesn't recognize
> there's any rekey collision, and sends INFO[DELETE] for the original
> ike_sa, thinking the rekeying is done successfully. My client receives
> the INFO[DELETE] while it's got the original ike_sa in REKEYING state
> and with its children still associated with it, and two potential
> successor ike_sas in CONNECTING state. Processing of the INFO[DELETE]
> results in all these being deleted in my client, with no successor
> ike_sa established, and no report to the application.

I think what you are describing here is a known bug or at least related,
see [1].

Regards
Martin

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