Site-to-Site VPN security proposals
When creating a VPN connection, you must define a security proposal (aka IPSec proposal). The security proposal defines the encryption and authentication methods used to secure the IPSec VPN tunnel.
A security proposal is made up of several parts, each with definable algorithms or settings. You should define these bearing in mind the use case of your Site-to-Site VPN, balancing security, performance and compatibility.
It is important to find the optimal trade-off between these elements: the strongest possible security may be overkill for your use-case, and slow down performance to unacceptable levels. Some algorithms are outdated and not optimal for modern VPNs, but may be the only compatible option for legacy VPNs.
In this document, we explain the different elements of a security protocol, and describe the different algorithms and security options available with Scaleway Site-to-Site VPN, giving advice to help you choose the best options for your use-case.
Defining a security proposal
There are two parts to a security proposal:
- IKEv2 (Internet Key Exchange): Establishes a secure connection between the VPN gateway and the customer gateway
- ESP (Encapsulating Security Payload): Encrypts and authenticates the payload of the IP data packets traveling through the tunnel.
When defining your Site-to-Site VPN security proposal, you must define the algorithms/ options to be used for IKEv2 and ESP as described below:
| Protocol | Element | Description | User must define? |
|---|---|---|---|
| IKEv2 | Encryption | Algorithm to encrypt IKE negotiation messages | ✅ Yes |
| IKEv2 | Integrity | HMAC-based algorithm to verify IKE negotiation messages have not been tampered with. Only set an HMAC integrity algorithm if not using an AEAD algorithm for IKEv2 encryption (see below). Otherwise, integrity is built in, and you do not need to set an IKEv2 integrity algorithm. | ❓ Depends |
| IKEv2 | Key Exchange Method | DH group to define strength of key exchange | ✅ Yes |
| Protocol | Element | Description | User must define? |
|---|---|---|---|
| ESP | Encryption | Algorithm to encrypt traffic's data payloads | ✅ Yes |
| ESP | Integrity | HMAC-based algorithm to verify data payloads have not been tampered with. Only set an HMAC integrity algorithm if not using an AEAD algorithm for ESP encryption (see below). Otherwise, integrity is built in, and you do not need to set an ESP integrity algorithm. | ❓ Depends |
| ESP | Key Exchange Method | DH group to define strength of key exchange | ❌ No |
Encryption algorithms
The following encryption algorithms are available.
| Algorithm | AEAD / non-AEAD* | Key Size (bits) | Security Level | Notes | Recommended? |
|---|---|---|---|---|---|
aes256gcm16 (AES-GCM) | AEAD | 256 | ✅ Very Strong | Generally the best choice for IPSec ESP & IKE | ✅ Recommended |
aes192gcm16 (AES-GCM) | AEAD | 192 | ✅ Strong | Suitable for high-performance VPNs | 👍 Acceptable |
aes128gcm16 (AES-GCM) | AEAD | 128 | ✅ Strong | Suitable for high-performance VPNs | 👍 Acceptable |
aes256ccm16 (AES-CCM) | AEAD | 256 | ✅ Strong | Alternative to AES-GCM, but GCM is preferred | 👍 Acceptable |
aes128ccm16 (AES-CCM) | AEAD | 128 | ⚠️ Medium | Alternative to AES-GCM, but GCM is preferred | 👍 Acceptable |
chacha20poly1305 | AEAD | 256 | ✅ Strong | Performance-sensitive (mobile, embedded), best choice for low-power devices | ✅ Recommended |
aes256 (AES-CBC) | non-AEAD | 256 | ✅ Strong | Suitable for legacy VPNs. Use only with HMAC (e.g. sha256) | ⚠️ Use with caution |
aes192 (AES-CBC) | non-AEAD | 192 | ⚠️ Medium | Rarely used, aes256 is preferred. | ⚠️ Use with caution |
aes128 (AES-CBC) | non-AEAD | 128 | ⚠️ Medium | Suitable for performance-sensitive VPNs, where constraints don't allow aes256 | ⚠️ Use with caution |
* Authenticated Encryption with Associated Data (AEAD) algorithms provide both encryption and authentication in a single step. They are more secure and efficient than non-AEAD algorithms, but are not supported by all legacy devices. We recommend that you always prefer AEAD algorithms (aes256gcm16 or chacha20poly1305) for performance and security. Choosing an AEAD algorithm for IKEv2/ESP encryption means you do not need to define an algorithm for IKEv2/ESP integrity.
Integrity algorithms
Integrity is based on Hash-based Message Authentication Code (HMAC). The following algorithms are available:
| Algorithm | Output Size (bits) | Security Level | Notes | Recommended? |
|---|---|---|---|---|
sha512 | 512 | ✅ Very Strong | Suitable for high security environments. Use for long term security. | ✅ Recommended |
sha384 | 384 | ✅ Strong | Balanced security/performance. Good alternative to sha-512. | ✅ Recommended |
sha256 | 256 | ✅ Strong | Default for most VPNs. Recommended baseline. | ✅ Recommended |
Key exchange methods
Key exchange is Diffie-Hellman-based. The following DH groups can be set to determine the strength and performance of the key exchange:
| DH Group | Bit Size | Security Level | Use Case | Recommended? |
|---|---|---|---|---|
ecp521 | 521 | ✅ Very Strong | Suitable for high security environments. May be overkill (lowers performance). | 👍 Acceptable |
ecp384 | 384 | ✅ Strong | Both strong and fast. Our top choice for modern VPNs. | ✅ Recommended |
ecp256 | 256 | ✅ Strong | Suitable for performance-sensitive VPNs. | ✅ Recommended |
curve25519 (X25519) | 256 | ✅ Very Strong | Both strong and fast. Our top choice for performance. | ✅ Recommended |
modp4096 | 4096 | ✅ Strong | Strong but slow. May be suitable for legacy VPNs. | 👍 Acceptable |
modp3072 | 3072 | ✅ Medium-Strong | May be suitable for legacy VPNs. | 👍 Acceptable |
modp2048 | 2048 | ⚠️ Minimum | Use for older VPNs only if absolutely needed. | ⚠️ Use with caution |
Standard recommendation
For standard usage on modern equipment we recommend the following security proposal:
| IKEv2 Encryption | IKEv2 Integrity | IKEv2 Key Exchange | ESP Encryption | ESP Integrity | ESP Key Exchange |
|---|---|---|---|---|---|
aes256gcm16 | not required | curve25519 | aes256gcm16 | not required | not required |