Project

General

Profile

Issue #2835

Rekeyed SA can't be deleted in standby node

Added by Xiaoqiang Fu almost 2 years ago. Updated almost 2 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.6.1
Resolution:

Description

Hi expert,

When active node initiate rekey with remote node, there is a rekey collision, then local wait for delete that IKE_SA. Acturally the IKE_SA is added by "HA IKE_ADD" message to standby node.
But the status is REKEYED for that IKE_SA in active node, then the IKE_SA can't be DELETE in standby node by code restriction as below.
I would like to know why "REKEYED" IKE_SA can't be deleted by ike_updown()? What is the restriction used for?
If so, how to remove the REKEYED SA in standby node?

Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA rekey collision won, waiting for delete for redundant IKE_SA heatipv6~heatipv6[16]
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA rekey collision won, waiting for delete for redundant IKE_SA heatipv6~heatipv6[16]
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[16] state change: CONNECTING => REKEYED
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[16] state change: CONNECTING => REKEYED
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[15] state change: CONNECTING => ESTABLISHED
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[15] state change: CONNECTING => ESTABLISHED
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] scheduling rekeying in 99s
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] scheduling rekeying in 99s
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] maximum IKE_SA lifetime 110s
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] maximum IKE_SA lifetime 110s
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[15] rekeyed between 2a00:8a00:8000:5002:0:15:0:c[2a00:8a00:8000:5002:0:15:0:c]...2a00:8a00:8000:134::d:b506[2a00:8a00:8000:134::d:b506]
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[15] rekeyed between 2a00:8a00:8000:5002:0:15:0:c[2a00:8a00:8000:5002:0:15:0:c]...2a00:8a00:8000:134::d:b506[2a00:8a00:8000:134::d:b506]
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[14] state change: REKEYING => REKEYED
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[14] state change: REKEYING => REKEYED
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] reinitiating already active tasks
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] reinitiating already active tasks
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE]   IKE_REKEY task
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE]   IKE_REKEY task
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] deleting IKE_SA heatipv6~heatipv6[14] between 2a00:8a00:8000:5002:0:15:0:c[2a00:8a00:8000:5002:0:15:0:c]...2a00:8a00:8000:134::d:b506[2a00:8a00:8000:134::d:b506]
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] deleting IKE_SA heatipv6~heatipv6[14] between 2a00:8a00:8000:5002:0:15:0:c[2a00:8a00:8000:5002:0:15:0:c]...2a00:8a00:8000:134::d:b506[2a00:8a00:8000:134::d:b506]
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[14] state change: REKEYED => DELETING
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] IKE_SA heatipv6~heatipv6[14] state change: REKEYED => DELETING
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] sending DELETE for IKE_SA heatipv6~heatipv6[14]
Nov 20 23:29:42 ei-1 charon[17017]: 11[IKE] sending DELETE for IKE_SA heatipv6~heatipv6[14]
Nov 20 23:29:42 ei-1 charon[17017]: 16[IKE] IKE_SA deleted
Nov 20 23:29:42 ei-1 charon[17017]: 16[IKE] IKE_SA deleted
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] received DELETE for IKE_SA heatipv6~heatipv6[16]
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] received DELETE for IKE_SA heatipv6~heatipv6[16]
Nov 20 23:29:42 ei-1 charon[17017]: 16[IKE] IKE_SA heatipv6~heatipv6[14] state change: DELETING => DESTROYING
Nov 20 23:29:42 ei-1 charon[17017]: 16[IKE] IKE_SA heatipv6~heatipv6[14] state change: DELETING => DESTROYING
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] deleting IKE_SA heatipv6~heatipv6[16] between 2a00:8a00:8000:5002:0:15:0:c[%any]...2a00:8a00:8000:134::d:b506[%any]
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] deleting IKE_SA heatipv6~heatipv6[16] between 2a00:8a00:8000:5002:0:15:0:c[%any]...2a00:8a00:8000:134::d:b506[%any]
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] IKE_SA heatipv6~heatipv6[16] state change: REKEYED => DELETING
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] IKE_SA heatipv6~heatipv6[16] state change: REKEYED => DELETING
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] IKE_SA deleted
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] IKE_SA deleted
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] IKE_SA heatipv6~heatipv6[16] state change: DELETING => DESTROYING
Nov 20 23:29:42 ei-1 charon[17017]: 08[IKE] IKE_SA heatipv6~heatipv6[16] state change: DELETING => DESTROYING
METHOD(task_t, process_i, status_t,
    private_ike_delete_t *this, message_t *message)
{
    DBG0(DBG_IKE, "IKE_SA deleted");
    if (!this->rekeyed)
    {    /* invoke ike_down() hook if SA has not been rekeyed */
        charon->bus->ike_updown(charon->bus, this->ike_sa, FALSE);
    }
    /* completed, delete IKE_SA by returning DESTROY_ME */
    return DESTROY_ME;
}

History

#1 Updated by Xiaoqiang Fu almost 2 years ago

Hi expert,

Any comment for my issue?

Regards,
Yang Li

#2 Updated by Tobias Brunner almost 2 years ago

  • Status changed from New to Feedback

When active node initiate rekey with remote node, there is a rekey collision, then local wait for delete that IKE_SA. Acturally the IKE_SA is added by "HA IKE_ADD" message to standby node.

Yes, they are created as soon as the key material is established.

I would like to know why "REKEYED" IKE_SA can't be deleted by ike_updown()? What is the restriction used for?

Because if it's a rekeying, ike_rekey is triggered and not ike_updown, which is only called for completely new SAs and when the last IKE_SA in a chain of rekeyings is eventually deleted.

If so, how to remove the REKEYED SA in standby node?

Probably needs some special handling of this particular case (e.g. via a new alert for redundant IKE_SAs, or perhaps we could check in ha_ike_t::ike_state_change() if the cache still had an entry and send a HA_IKE_DELETE if that was the case).

#3 Updated by Xiaoqiang Fu almost 2 years ago

via a new alert for redundant IKE_SAs

We have tried via a new alert for such case. We'll send code for review purpose if verify successfully.

Also available in: Atom PDF