[strongSwan] "best practices"?

Andreas Steffen andreas.steffen at strongswan.org
Thu Apr 2 00:49:03 CEST 2015


Hi James,

here are the default proposals for the ike and esp algorithms
if you don't define them explictly:

carol charon: 04[CFG] configured proposals:
  IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048,
  IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536,
  IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/AES_CTR_128/
      AES_CTR_192/AES_CTR_256/HMAC_SHA1_96/
      HMAC_MD5_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/
      AES_XCBC_96/PRF_HMAC_SHA1/PRF_HMAC_MD5/PRF_HMAC_SHA2_256/
      PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/
      MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/
      MODP_4096/MODP_8192/MODP_1024/MODP_1024_160,
  IKE:AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/AES_CCM_12_128/
      AES_CCM_12_192/AES_CCM_12_256/AES_CCM_16_128/AES_CCM_16_192/
      AES_CCM_16_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/
      AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_16_128/
      AES_GCM_16_192/AES_GCM_16_256/PRF_HMAC_SHA1/PRF_HMAC_MD5/
      PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/
      PRF_AES128_XCBC/
      MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/
      MODP_4096/MODP_8192/MODP_1024/MODP_1024_160

carol charon: 13[CFG] configured proposals:
  ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ,
  ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ,
  ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/
      HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ

As you can see, the cipher suites in the first position are not the
strongest ones but are algorithms with a decent strength which most
of the IPsec endpoints support:

- We still keep 3DES since Windows XP does not support AES.

- We don't include the SHA-2 HMAC algorithms as well as the AES-GCM
  and AES-CCM  authenticated encryption schemes in our default
  ESP proposals because Linux kernels older than 2.6.33 do not
  support them and there are  still a lot of 2.6.18 kernels around
  (e.g. centOS and other fossils).

If you want strong and fast crypto and you have a recent Linux kernel
and your processor has the Intel AES-NI instruction set then I suggest

  ike=aes128gcm16-prfsha256-ecp256,aes256gcm16-prfsha384-ecp384!
  esp=aes128gcm16-ecp256,aes256gcm16-ecp384!

for 128 bit or 192 bit security strength, respectively.

If you don't trust the NIST elliptic curves then you can use
NTRU based on lattices instead:

  ike=aes128gcm16-prfsha256-ntru256,aes256gcm16-prfsha384-ntru384!
  esp=aes128gcm16-ntru256,aes256gcm16-ntru384!

Best regards

Andreas

On 04/01/2015 08:08 PM, James wrote:
> All,
> 
> Looking for best practices on the most secure settings that can be
> used.
> 
> I've scoured the net and found very little in terms of which
> settings are most secure and in which combination.
> 
> I saw a recommendation on a site that recommended the following
> settings:
> 
> conn %default 
> ike=aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024!
>
> 
esp=aes128gcm16-ecp256,aes256gcm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024,aes128gcm16,aes256gcm16,aes128-sha256,aes128-sha1,aes256-sha384,aes256-sha256,aes256-sha1!
> 
> Obviously there's the documentation 
> (https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites)
>
> 
but ti doesn't really indicate which are the strongest methods as best
> I can tell.
> 
> Should I assume that strongSwan will automatically use the "most 
> secure" communication method possible if both ends are configured 
> _without_ the esp and ike directives?
> 
> Thanks

======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==


More information about the Users mailing list