[strongSwan] IPsec/IKEv2 tunnels scalability issue with load-tester plugin (using strongSwan 5.0.4)

[Martin Willi]

Hi,

> Although we did not encounter with aforesaid message, it could
> not create all 300 IPsec tunnels. [...]

> [IKE] tried 1 shared key for 'srv.strongswan.org' - 'c13-r1.strongswan.org',
> but MAC mismatched

This problem arises when enabling IKEv2 DoS protection using COOKIEs.

Assume the following: The initiator sends an IKE_SA_INIT without a
COOKIE. The responder queues that message for processing. If it then
enables DoS protection, and the initiator retransmits the IKE_SA_INIT,
you'll encounter this issue. The initiator assumes the responder
processed the COOKIEd IKE_SA_INIT, but in fact it processed the first
IKE_SA_INIT without a COOKIE. The peers use different IKE_SA_INIT data
to authenticate during IKE_AUTH, and the MAC does not match (see also
[1]).

While there could be ways to improve the situation (i.e. respect a
second IKE_SA_INIT message having a COOKIE), I don't think that there is
way to solve this issue completely. Under DoS the chance is high that
packets get lost elsewhere. The only option would be to change the IKEv2
protocol itself (for example to not include the COOKIE in MAC
calculation).

Further, I think your assumption is wrong that there is a guarantee that
a tunnel can be established given a Denial of Service situation. You
should reconsider what a DoS situation is, and configure the daemon
accordingly using the cookie_threshold and block_threshold options. Also
you might check the init_limit_job_load/init_limit_half_open options;
they can help in avoiding this issue. But once you hit DoS limits, the
above error will happen, and there is certainly no guarantee all
connection attempts will be successful.

Regards
Martin

[1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=1b7debcc