[strongSwan-dev] IKEv2 Proposal Limites StrongSwan v5.4.0

[James Hulka]

Dear StrongSwan Team,

are you aware of any limit on the number of IKEv2 IKE and ESP proposals that
StrongSwan v5.4.0 can support?

In our tests we found that there is a cut-off at around 220 proposals, independent of
what algorithms are used.

Testing with v5.0.3 we were able to use up to 10000 proposals.

Best Regards,

James Hulka

[Tobias Brunner]

Hi James,

Post by James Hulka
are you aware of any limit on the number of IKEv2 IKE and ESP proposals that
StrongSwan v5.4.0 can support?

Each proposal has a number assigned within the SA payload, which is
stored in an 8-bit field. Starting with 1 this theoretically limits the
number of proposals to 255. But the daemon actually does not enforce
this, so if you configure more they just get the same number assigned as
a previous proposal (the number is just truncated to 8-bit). However,
such an SA payload would then fail verification on the responder (the
daemon verifies that the proposals are numbered consecutively). The
number of transforms (algorithms) per proposal is also stored in an
8-bit field, so that's limited too (but also not enforced, so this could
fail miserably as e.g. adding 256 transforms would result in the number
getting set to 0).

Post by James Hulka
Testing with v5.0.3 we were able to use up to 10000 proposals.

Seems strange. How exactly did you test this? Could you provide some
test configs? Why would you have such a high number of proposals anyway?

Regards,
Tobias

[James Hulka]

Hello Tobias,

please find my answers inline.

Best Regards,

James

Post by Tobias Brunner
Hi James,

Post by James Hulka
are you aware of any limit on the number of IKEv2 IKE and ESP proposals that
StrongSwan v5.4.0 can support?

Each proposal has a number assigned within the SA payload, which is
stored in an 8-bit field. Starting with 1 this theoretically limits the
number of proposals to 255. But the daemon actually does not enforce
this, so if you configure more they just get the same number assigned as
a previous proposal (the number is just truncated to 8-bit). However,
such an SA payload would then fail verification on the responder (the
daemon verifies that the proposals are numbered consecutively). The
number of transforms (algorithms) per proposal is also stored in an
8-bit field, so that's limited too (but also not enforced, so this could
fail miserably as e.g. adding 256 transforms would result in the number
getting set to 0).

yes this makes sense. Interestingly with StrongSwan v5.4.0 we had the

Post by Tobias Brunner
ipsec up test_1

no config named ’test_1’

Post by Tobias Brunner

Post by James Hulka
Testing with v5.0.3 we were able to use up to 10000 proposals.

Seems strange. How exactly did you test this? Could you provide some
test configs? Why would you have such a high number of proposals anyway?

We were testing the cross product of different sets (rather large sets)
of algorithms to see if it would be possible to establish connections
with a variety of third party peers without having to tweak this part of
the configuration too much (I have attached an example configuration
ikev2.conf).

Post by Tobias Brunner
Regards,
Tobias

[Tobias Brunner]

Hi James,

Post by James Hulka
Interestingly with StrongSwan v5.4.0 we had the

Post by Tobias Brunner
ipsec up test_1

no config named ’test_1’

That indicates a problem when the config was loaded. The file you
posted loads fine here with 5.4.0, though. Try increasing the log level
for cfg to 2. You should see the config getting loaded as configured.
Also, make sure all components are from the same build (starter, charon,
libraries, plugins etc.).

Post by James Hulka

Post by Tobias Brunner

Post by James Hulka
Testing with v5.0.3 we were able to use up to 10000 proposals.

Seems strange. How exactly did you test this? Could you provide some
test configs? Why would you have such a high number of proposals anyway?

We were testing the cross product of different sets (rather large sets)
of algorithms to see if it would be possible to establish connections
with a variety of third party peers without having to tweak this part of
the configuration too much (I have attached an example configuration
ikev2.conf).

For IKEv2 that's overkill unless you want to allow algorithms only in a
certain combination (e.g. to ensure a consistent security strength).
Usually, you can simply configure a proposal that includes all
algorithms you want to allow (e.g.
ike=aes256-aes128-sha256-sha1-modp3072-modp2048!). Only if you want to
prevent that a peer uses e.g. sha1 with aes256 you'd have to use
separate proposals. But even then you could probably simplify this by
defining a handful of proposals with classes of algorithms (e.g. one
with strong, one with medium and one with weak algorithms - AEAD
algorithms, if proposed, also have to be defined in a separate proposal
as they can't be combined with integrity algorithms). Note that some of
the proposals you generated are invalid or otherwise problematic:

* There are lots of proposals in `ike` that don't list any DH groups,
which IKE proposals always must contain.
* NULL encryption for IKE, while theoretically possible, is definitely
not recommended (it also only works with the _openssl_ plugin).
* `sha` is just an alias for `sha1` so there are lots of duplicates.
* AES-GMAC for ESP can't be combined with an encryption algorithm as
it's basically NULL encryption with AES-GMAC as integrity algorithm.
* Some other combinations also make not much sense e.g. 3des with
modp8192. Weak algorithms like 3des, md5 or modp1024 should be
avoided anyway.

Regards,
Tobias