Project

General

Profile

Issue #3164

Retransmit rekeying uses remote address before mobike event occurs

Added by Michaël Legagneur about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
libcharon
Affected version:
5.8.0
Resolution:

Description

Hello,

We observed an issue when using a client IKEv2 on strongswan 5.8.0 with two interfaces and mobike enable.
The scenario is the following : the client has an instable primary link and triggers mobike on the secondary link during rekeying initiated by the server.
To reproduce the issue, we uses testbed where we dropped packet on the primary link (10.1.3.7 on our logs at the server side).

Mon, 2019-09-02 14:31 03[ENC] <backbone|1> generating CREATE_CHILD_SA request 0 [ N(REKEY_SA) N(IPCOMP_SUP) SA No TSi TSr ]
Mon, 2019-09-02 14:31 03[NET] <backbone|1> sending packet: from 10.1.3.20[4500] to 10.1.3.7[4500] (272 bytes)
Mon, 2019-09-02 14:31 05[IKE] <backbone|1> retransmit 1 of request with message ID 0
Mon, 2019-09-02 14:31 05[NET] <backbone|1> sending packet: from 10.1.3.20[4500] to 10.1.3.7[4500] (272 bytes)
Mon, 2019-09-02 14:31 13[IKE] <backbone|1> retransmit 2 of request with message ID 0
Mon, 2019-09-02 14:31 13[NET] <backbone|1> sending packet: from 10.1.3.20[4500] to 10.1.3.7[4500] (272 bytes)

During these retransmissions, the current primary link goes down so it requests mobike to use the secondary interface (10.1.3.8).
This mobike is successfully done at the server side, the remote address used is 10.1.3.8.

Mon, 2019-09-02 14:31 17[ENC] <backbone|1> parsed INFORMATIONAL request 3 [ N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP) N(COOKIE2) N(ADD_4_ADDR) ]
Mon, 2019-09-02 14:31 17[IKE] <backbone|1> got additional MOBIKE peer address: 192.168.1.1
Mon, 2019-09-02 14:31 17[CHD] <backbone|1> CHILD_SA net{1} state change: REKEYING => UPDATING
..
Mon, 2019-09-02 14:31 17[KNL] <backbone|1> updating SAD entry with SPI cf7cf832 from 10.1.3.7[4500]..10.1.3.20[4500] to 10.1.3.8[4500]..10.1.3.21[4500]
Mon, 2019-09-02 14:31 17[KNL] <backbone|1> querying SAD entry with SPI c33187b9 for update
Mon, 2019-09-02 14:31 17[KNL] <backbone|1> querying replay state from SAD entry with SPI c33187b9
Mon, 2019-09-02 14:31 17[KNL] <backbone|1> deleting SAD entry with SPI c33187b9
Mon, 2019-09-02 14:31 17[KNL] <backbone|1> deleted SAD entry with SPI c33187b9
Mon, 2019-09-02 14:31 17[KNL] <backbone|1> updating SAD entry with SPI c33187b9 from 10.1.3.20[4500]..10.1.3.7[4500] to 10.1.3.21[4500]..10.1.3.8[4500]

The server continues to retransmit rekey toward the secondary link, and after client response, the server processes the rekeying with the first remote address (10.1.3.7) instead of the new one, 10.1.3.8.

Mon, 2019-09-02 14:31 16[CHD] <backbone|1> CHILD_SA net{2} state change: CREATED => INSTALLING
Mon, 2019-09-02 14:31 16[CHD] <backbone|1>   using AES_CBC for encryption
Mon, 2019-09-02 14:31 16[CHD] <backbone|1>   using HMAC_SHA2_256_128 for integrity
Mon, 2019-09-02 14:31 16[CHD] <backbone|1> adding inbound ESP SA
Mon, 2019-09-02 14:31 16[CHD] <backbone|1>   SPI 0xc30b09eb, src 10.1.3.7 dst 10.1.3.20
Mon, 2019-09-02 14:31 16[KNL] <backbone|1> adding SAD entry with SPI c30b09eb and reqid {1}
Mon, 2019-09-02 14:31 16[KNL] <backbone|1>   using encryption algorithm AES_CBC with key size 128
Mon, 2019-09-02 14:31 16[KNL] <backbone|1>   using integrity algorithm HMAC_SHA2_256_128 with key size 256
Mon, 2019-09-02 14:31 16[KNL] <backbone|1>   using replay window of 32 packets
Mon, 2019-09-02 14:31 16[KNL] <backbone|1>   HW offload: no
Mon, 2019-09-02 14:31 16[CHD] <backbone|1> adding outbound ESP SA
Mon, 2019-09-02 14:31 16[CHD] <backbone|1>   SPI 0xc14b0d45, src 10.1.3.20 dst 10.1.3.7
Mon, 2019-09-02 14:31 16[KNL] <backbone|1> adding SAD entry with SPI c14b0d45 and reqid {1}
Mon, 2019-09-02 14:31 16[KNL] <backbone|1>   using encryption algorithm AES_CBC with key size 128
Mon, 2019-09-02 14:31 16[KNL] <backbone|1>   using integrity algorithm HMAC_SHA2_256_128 with key size 256
Mon, 2019-09-02 14:31 16[KNL] <backbone|1>   using replay window of 0 packets
Mon, 2019-09-02 14:31 16[KNL] <backbone|1>   HW offload: no
Mon, 2019-09-02 14:31 16[KNL] <backbone|1> policy 10.4.0.1/32 === 10.1.4.0/24 in already exists, increasing refcount
Mon, 2019-09-02 14:31 16[KNL] <backbone|1> updating policy 10.4.0.1/32 === 10.1.4.0/24 in [priority 371327, refcount 2]
Mon, 2019-09-02 14:31 16[KNL] <backbone|1> policy 10.4.0.1/32 === 10.1.4.0/24 fwd already exists, increasing refcount
Mon, 2019-09-02 14:31 16[KNL] <backbone|1> updating policy 10.4.0.1/32 === 10.1.4.0/24 fwd [priority 371327, refcount 2]
Mon, 2019-09-02 14:31 16[IKE] <backbone|1> inbound CHILD_SA net{2} established with SPIs c30b09eb_i c14b0d45_o and TS 10.1.4.0/24 === 10.4.0.1/32
Mon, 2019-09-02 14:31 16[CHD] <backbone|1> CHILD_SA net{2} state change: INSTALLING => INSTALLED
Mon, 2019-09-02 14:31 16[KNL] <backbone|1> policy 10.1.4.0/24 === 10.4.0.1/32 out already exists, increasing refcount
Mon, 2019-09-02 14:31 16[KNL] <backbone|1> updating policy 10.1.4.0/24 === 10.4.0.1/32 out [priority 371327, refcount 2]
Mon, 2019-09-02 14:31 16[IKE] <backbone|1> outbound CHILD_SA net{2} established with SPIs c30b09eb_i c14b0d45_o and TS 10.1.4.0/24 === 10.4.0.1/32
Mon, 2019-09-02 14:31 16[CHD] <backbone|1> CHILD_SA net{1} state change: REKEYING => REKEYED

It seems that it could due that child_create task, the child_sa is created with the remote_address at the build initiator method and didn't update before installing it at the process_i method.

METHOD(task_t, build_i, status_t,
    private_child_create_t *this, message_t *message)
{
...
    this->child_sa = child_sa_create(this->ike_sa->get_my_host(this->ike_sa),
            this->ike_sa->get_other_host(this->ike_sa), this->config, this->reqid,
            this->ike_sa->has_condition(this->ike_sa, COND_NAT_ANY),
            this->mark_in, this->mark_out);

    if (!allocate_spi(this))
    {
        DBG1(DBG_IKE, "unable to allocate SPIs from kernel");
        return FAILED;
    }

What could be the best fix ? I have updated the local and remote address of child_sa with dedicated method during the process_i method but I am not sure that was the best place.

Thanks,

Michaël

charon_debug.log (16.4 KB) charon_debug.log Michaël Legagneur, 02.09.2019 15:07
swanctl-client.conf (401 Bytes) swanctl-client.conf Michaël Legagneur, 02.09.2019 15:15
swanctl-server.conf (612 Bytes) swanctl-server.conf Michaël Legagneur, 02.09.2019 15:15

Also available in: Atom PDF