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

[Tobias Brunner]

Hi James,

> Interestingly with StrongSwan v5.4.0 we had the
> following error message if we had more than 255 proposals configured:
> 
>> 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.).

>>> 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