Mobike Port Change unable to add attribute, buffer too small about strongswan

[tobiasbrunner]

The code in kernel_netlink_ipsec_t::update_sa() copies all attributes retrieved from the existing SA to a new request. The default size of the buffer for the latter is 1024 (KERNEL_NETLINK_BUFSIZE), that might be too small in your case. Could you please provide a log with the debug level for knl increased to 4?

[svenauhagen]

That sounds like it could be the reason.

I do not have access to the remote system all the time.
I will be able to get the data on Thursday and report back.

I can also test a a new version with a larger bufsize afterwards.

[svenauhagen]

Hi,

it took a bit for the endpoint to change the port but here is the output.
ipsec.log

Best
Sven

[tobiasbrunner]

Thanks a lot for the log.

What triggers this in your case is basically the size of the anti-replay state. You configured a window size of 2048, which means the replay state contains a bitmap of 256 bytes (the complete attribute also has some overhead for the sequence numbers etc.).

That bitmap is already allocated when installing the SA. The difference when updating the SA is that we also receive and add some attributes that are not passed when the SA is originally installed, for instance, the current lifetime attribute (which contains the number of packets/bytes).

However, what I realized just now looking at the log, is that the response to the XFRM_MSG_GETSA message from the kernel actually includes the anti-replay state. So that's already copied to the message we send back to the kernel to install the SA with updated addresses (we copy all attributes except XFRMA_ENCAP if the UDP encapsulation state changed).

But we also request the anti-replay state together with the lifetime attribute (which is not included in the message above) in a separate XFRM_MSG_GETAE request and then add it to the message. So that attribute is added twice, which is definitely wrong but not a particular problem, unless the anti-replay window is as large as it is here.

The anti-replay state was originally not included in the response to XFRM_MSG_GETSA, which explains our current code. But it looks like the kernel adds the newer attribute that's used for larger windows and ESN since support for it was added with 2.6.39 (we added support for that attribute just in the same way as for the classic anti-replay attribute in 05e9589, without realizing that that's not necessary). And since 3.19, the kernel also includes the classic anti-replay state if the window is smaller and ESN is not used. So copying the ESN attribute is definitely not necessary anymore, and the classic one most likely neither. But since we have to call XFRM_MSG_GETAE anyway to get the usage stats, we could also just safeguard against adding that attribute twice. I've pushed such a change to the 1967-netlink-replay-update branch.