strongSwan - Bug #3164
Retransmit rekeying uses remote address before mobike event occurs
02.09.2019 16:13 - Michaël Legagneur

ステータス:

Closed

開始日:

優先度:

Normal

期日:担当者:

Tobias Brunner

予定工数:

0.00時間カテゴリ:

kernel-interface

対象バージョン:5.9.1

Affected version:

5.8.0

Resolution:

Fixed

説明
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
o TSi TSr ]Mon, 2019-09-02
Mon, 2019-09-02
Mon, 2019-09-02
Mon, 2019-09-02
Mon, 2019-09-02

14:31

03[ENC]<backbone¦1>

generating

CREATE̲CHILD̲SA

request0[N(REKEY̲SA)

14:31
14:31
14:31
14:31
14:31

03[NET] <backbone¦1> sending packet: from 10.1.3.20[4500] to 10.1.3.7[4500]
05[IKE] <backbone¦1> retransmit 1 of request with message ID 005[NET] <backbone¦1> sending packet: from 10.1.3.20[4500] to 10.1.3.7[4500]
13[IKE] <backbone¦1> retransmit 2 of request with message ID 0
13[NET] <backbone¦1> sending packet: from 10.1.3.20[4500] to 10.1.3.7[4500]

N(IPCOMP̲SUP)(272bytes)(272bytes)(272bytes)

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̲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[4o 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[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,Mon,Mon,Mon,Mon,Mon,Mon,Mon,Mon,Mon,Mon,Mon,Mon,Mon,Mon,

2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02
2019-09-02

11.10.2024

14:31
14:31
14:31
14:31
14:31
14:31
14:31
14:31
14:31
14:31
14:31
14:31
14:31
14:31
14:31

16[CHD]
16[CHD]16[CHD]
16[CHD]
16[CHD]
16[KNL]
16[KNL]
16[KNL]
16[KNL]
16[KNL]16[CHD]
16[CHD]
16[KNL]
16[KNL]
16[KNL]<backbone¦1> CHILD̲SA net{2} state change: CREATED => INSTALLING<backbone¦1>
using AES̲CBC for encryption<backbone¦1>
using HMAC̲SHA2̲256̲128 for integrity<backbone¦1> adding inbound ESP SA<backbone¦1>
SPI 0xc30b09eb, src 10.1.3.7 dst 10.1.3.20<backbone¦1> adding SAD entry with SPI c30b09eb and reqid {1}<backbone¦1>
using encryption algorithm AES̲CBC with key size 128<backbone¦1>
using integrity algorithm HMAC̲SHA2̲256̲128 with key size<backbone¦1>
using replay window of 32 packets<backbone¦1>
HW offload: no<backbone¦1> adding outbound ESP SA<backbone¦1>
SPI 0xc14b0d45, src 10.1.3.20 dst 10.1.3.7<backbone¦1> adding SAD entry with SPI c14b0d45 and reqid {1}<backbone¦1>
using encryption algorithm AES̲CBC with key size 128<backbone¦1>
using integrity algorithm HMAC̲SHA2̲256̲128 with key size

1/3256256

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: noMon, 2019-09-02 14:31 16[KNL] <backbone¦1> policy 10.4.0.1/32 === 10.1.4.0/24 in already exists, increasing refcou
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, refc
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 refc
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, re]Mon, 2019-09-02 14:31 16[IKE] <backbone¦1> inbound CHILD̲SA net{2} established with SPIs c30b09eb̲i c14b0d45̲o
S 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 refco
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, refMon, 2019-09-02 14:31 16[IKE] <backbone¦1> outbound CHILD̲SA net{2} established with SPIs c30b09eb̲i c14b0d45̲
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 anddidn'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 toreturn FAILED;}

allocate

SPIsfrom ");kernelWhat could be the best fix ? I have updated the local and remote address of child̲sa with dedicated method during the process̲imethod but I am not sure that was the best place.
Thanks,Michaël履歴#1 - 13.10.2020 14:39 - Frédéric Martinsons
Hello there,
are there any news about this issue ? I mean, is the patch suggested is the correct one to be applied ?
#2 - 15.10.2020 15:44 - Tobias Brunner- トラッカー を Issue から Bug に変更- カテゴリ を libcharon から kernel-interface に変更- ステータス を New から Feedback に変更- 対象バージョン を 5.9.1 にセット

I mean, is the patch suggested is the correct one to be applied ?

There are some potential issues. The IP addresses that are passed to the constructor are used when allocating an SPI for the inbound SA from thekernel (this has to be done before sending the CREATE̲CHILD̲SA request as it is contained in the proposals). This usually creates a temporary SA
in the kernel to keep track of it. If the addresses are later updated before installing/updating the inbound SA, the kernel might not be able to findthe temporary SA. The tuple SPI, destination address and protocol is usually used for this lookup, so for the inbound SA that should work if the local
address did not change (as in the example above). But the MOBIKE client could also switch to a different server address if multiple are available (andif a kernel uses both addresses to identify SAs that would not work either). This might not necessarily be a problem, it could just create a "duplicate"

11.10.2024

2/3

SA with different addresses and the same SPI. The temporary SA will eventually expire but if the addresses are switched back until that happens,there would be a conflict (the newly updated SA would have the same address and SPI as the existing temporary one). The expiration also causes anevent in the kernel and the daemon, which might or might not be an issue, depending on the addresses that are in use at that time of the event (inthe worst case the expire could cause the SA to get deleted).
With some additional changes, we could probably call child̲sa̲t::update() with the new addresses before installing the SAs and policies, which doesnothing if the addresses did not change. Not all kernel interfaces support updating addresses on SAs (in which case the addresses are currently notupdated on the child̲sa̲t object) and it might not work at all for temporary SAs that were created implicitly when an SPI was allocated (there might
not even be any such temporary SAs). So there is probably no point in attempting to actually update the inbound SA (the outbound SA won't beupdated until installed). I pushed some patches to this effect to the 3164-mobike-childsa branch.
#3 - 21.10.2020 15:26 - Frédéric Martinsons
Tobias Brunner wrote:
There are some potential issues. The IP addresses that are passed to the constructor are used when allocating an SPI for the inbound SA fromthe kernel (this has to be done before sending the CREATE̲CHILD̲SA request as it is contained in the proposals). This usually creates atemporary SA in the kernel to keep track of it. If the addresses are later updated before installing/updating the inbound SA, the kernel might
not be able to find the temporary SA. The tuple SPI, destination address and protocol is usually used for this lookup, so for the inbound SA thatshould work if the local address did not change (as in the example above). But the MOBIKE client could also switch to a different server
address if multiple are available (and if a kernel uses both addresses to identify SAs that would not work either). This might not necessarily bea problem, it could just create a "duplicate" SA with different addresses and the same SPI. The temporary SA will eventually expire but if theaddresses are switched back until that happens, there would be a conflict (the newly updated SA would have the same address and SPI as theexisting temporary one). The expiration also causes an event in the kernel and the daemon, which might or might not be an issue, dependingon the addresses that are in use at that time of the event (in the worst case the expire could cause the SA to get deleted).
With some additional changes, we could probably call child̲sa̲t::update() with the new addresses before installing the SAs and policies, which
does nothing if the addresses did not change. Not all kernel interfaces support updating addresses on SAs (in which case the addresses arecurrently not updated on the child̲sa̲t object) and it might not work at all for temporary SAs that were created implicitly when an SPI wasallocated (there might not even be any such temporary SAs). So there is probably no point in attempting to actually update the inbound SA(the outbound SA won't be updated until installed). I pushed some patches to this effect to the 3164-mobike-childsa branch.

Thank you very much for the detailed answer and the commits you provided.
#4 - 27.10.2020 16:45 - Tobias Brunner- ステータス を Feedback から Closed に変更- 担当者 を Tobias Brunner にセット
- Resolution を Fixed にセットファイル
charon̲debug.log

16.4 KB

02.09.2019

Michaël Legagneur

swanctl-client.conf

401 Bytes

02.09.2019

Michaël Legagneur

swanctl-server.conf

612 Bytes

02.09.2019

Michaël Legagneur

11.10.2024

3/3