Tip

This is the documentation for the 20.10 version. Looking for the documentation of the latest version? Have a look here.

IKE Proposal

IKE Proposals instruct TNSR how the key exchange will be encrypted and authenticated. TNSR supports a variety of encryption algorithms, integrity/authentication hash algorithms, pseudo-random functions (PRF), and Diffie-Hellman (DH) group specifications. These choices must be coordinated between both endpoints.

Tip

Some vendor IPsec implementations refer to IKE/ISAKMP as “Phase 1”, which may help when attempting to map values supplied by a peer to their corresponding values in TNSR.

From within config-ipsec-crypto-ike mode, use the proposal <name> command to start a new proposal and enter config-ike-proposal mode. In config-ike-proposal mode, the following commands are available:

encryption <ea-name>:

Configures the encryption algorithm to use for the proposal.

integrity <ia-name>:

Configures the integrity algorithm to use for the proposal.

prf <prf-name>:

Configures the pseudo-random function (PRF) to use for the proposal.

group <group-name>:

Configures the Diffie-Hellman group (DH Group) to use for the proposal.

Tip

To see a list of supported choices for each option, follow the initial command with a ?, such as encryption ?.

Each of these is described in more detail in the following sections.

Encryption Algorithms

TNSR supports many common, secure encryption algorithms. Some older and insecure algorithms are not supported.

Algorithms based on AES are common and secure, and are widely supported by other VPN implementations.

AES-GCM, or AES Galois/Counter Mode is an efficient and fast authenticated encryption algorithm, which means it provides data privacy as well as integrity validation, without the need for a separate integrity algorithm.

Additionally, AES-based algorithms can often be accelerated by AES-NI.

Warning

TNSR includes the Triple-DES (3DES) algorithm for compatibility with legacy systems, but it is not considered secure. Specifically, 3DES is considered broken by attacks such as Sweet32. Use stronger encryption algorithms where possible.

A full list of encryption algorithms supported by TNSR:

tnsr(config-ike-proposal)# encryption ?
  <cr>
  3des                  Triple-DES
  aes128                128 bit AES-CBC
  aes128ccm12           128 bit AES-CCM with 12 byte ICV
  aes128ccm16           128 bit AES-CCM with 16 byte ICV
  aes128ccm8            128 bit AES-CCM with 8 byte ICV
  aes128ctr             128 bit AES-Counter
  aes128gcm12           128 bit AES-GCM with 12 byte ICV
  aes128gcm16           128 bit AES-GCM with 16 byte ICV
  aes128gcm8            128 bit AES-GCM with 8 byte ICV
  aes192                192 bit AES-CBC
  aes192ccm12           192 bit AES-CCM with 12 byte ICV
  aes192ccm16           192 bit AES-CCM with 16 byte ICV
  aes192ccm8            192 bit AES-CCM with 8 byte ICV
  aes192ctr             192 bit AES-Counter
  aes192gcm12           192 bit AES-GCM with 12 byte ICV
  aes192gcm16           192 bit AES-GCM with 16 byte ICV
  aes192gcm8            192 bit AES-GCM with 8 byte ICV
  aes256                256 bit AES-CBC
  aes256ccm12           256 bit AES-CCM with 12 byte ICV
  aes256ccm16           256 bit AES-CCM with 16 byte ICV
  aes256ccm8            256 bit AES-CCM with 8 byte ICV
  aes256ctr             256 bit AES-Counter
  aes256gcm12           256 bit AES-GCM with 12 byte ICV
  aes256gcm16           256 bit AES-GCM with 16 byte ICV
  aes256gcm8            256 bit AES-GCM with 8 byte ICV
  camellia128           128 bit Camellia
  camellia128ccm12      128 bit Camellia-CCM with 12 byte ICV
  camellia128ccm16      128 bit Camellia-CCM with 16 byte ICV
  camellia128ccm8       128 bit Camellia-CCM with 8 byte ICV
  camellia128ctr        128 bit Camellia-Counter
  camellia192           192 bit Camellia
  camellia192ccm12      192 bit Camellia-CCM with 12 byte ICV
  camellia192ccm16      192 bit Camellia-CCM with 16 byte ICV
  camellia192ccm8       192 bit Camellia-CCM with 8 byte ICV
  camellia192ctr        192 bit Camellia-Counter
  camellia256           256 bit Camellia
  camellia256ccm12      256 bit Camellia-CCM with 12 byte ICV
  camellia256ccm16      256 bit Camellia-CCM with 16 byte ICV
  camellia256ccm8       256 bit Camellia-CCM with 8 byte ICV
  camellia256ctr        256 bit Camellia-Counter
  chacha20poly1305      256 bit ChaCha20/Poly1305 with 16 byte ICV

Integrity Algorithms

Integrity algorithms provide authentication of messages and randomness, ensuring that packets are authentic and were not altered by a third party before arriving, and also for constructing keying material for encryption.

Note

When using an authenticated encryption algorithm like AES-GCM with a child Security Association (SA) as opposed to IKE/ISAKMP, an integrity option should not be configured, as it is redundant and reduces performance.

When an authenticated encryption algorithm is used with IKE, configure a Pseudo-Random Function (PRF) instead of an Integrity Algorithm. If an integrity algorithm is defined in this case, TNSR will attempt to map the chosen algorithm to an equivalent PRF.

A full list of integrity algorithms supported by TNSR:

tnsr(config-ike-proposal)# integrity ?
  <cr>
  aescmac               AES-CMAC 96
  aesxcbc               AES-XCBC 96
  md5                   MD5 96
  sha1                  SHA1 96
  sha256                SHA2 256 bit blocks, 128 bits output
  sha384                SHA2 384 bit blocks, 192 bits output
  sha512                SHA2 512 bit blocks, 256 bits output

Pseudo-Random Functions

A Pseudo-Random Function (PRF) is similar to an integrity algorithm, but instead of being used to authenticate messages, it is only used to provide randomness for purposes such as keying material. PRFs are primarily used with an authenticated encryption algorithm type such as AES-GCM, but they can be explicitly defined for use with other integrity algorithms.

If a PRF is not explicitly defined, TNSR will attempt to derive the PRF to use based on the integrity algorithm for a given proposal.

Note

In the case of AES-NI, prfaesxcbc is likely the most appropriate choice as it can be accelerated by AES-NI, and it is more widely supported than its improved successor prfaescmac.

A full list of pseudo-random functions supported by TNSR:

tnsr(config-ike-proposal)# prf ?
  <cr>
  prfaescmac            AES128-CMAC PRF
  prfaesxcbc            AES128-XCBC PRF
  prfmd5                MD5 PRF
  prfsha1               SHA1 PRF
  prfsha256             SHA2-256 PRF
  prfsha384             SHA2-384 PRF
  prfsha512             SHA2-512 PRF

Diffie-Hellman Groups

Diffie-Hellman (DH) exchanges allow two parties to establish a shared secret across an untrusted connection. DH choices can be referenced in several different ways depending on vendor implementations. Some reference a DH group by number, others by size. When referencing by group number, generally speaking higher group numbers are more secure.

Tip

In most cases, modp2048 (Group 14) is the lowest choice considered to provide sufficient security in a modern computing environment.

A full list of DH Groups supported by TNSR:

tnsr(config-ike-proposal)# group ?
  <cr>
  curve25519            Group 31 (Elliptic Curve 25519, 256 bit)
  ecp256                Group 19 (256 bit ECP)
  ecp384                Group 20 (384 bit ECP)
  ecp521                Group 21 (521 bit ECP)
  modp1024              Group 2 (1024 bit modulus)
  modp1024s160          Group 22 (1024 bit modulus, 160 bit POS)
  modp1536              Group 5 (1536 bit modulus)
  modp2048              Group 14 (2048 bit modulus)
  modp2048s224          Group 23 (2048 bit modulus, 224 bit POS)
  modp2048s256          Group 24 (2048 bit modulus, 256 bit POS)
  modp3072              Group 15 (3072 bit modulus)
  modp4096              Group 16 (4096 bit modulus)
  modp6144              Group 17 (6144 bit modulus)
  modp768               Group 1 (768 bit modulus)
  modp8192              Group 18 (8192 bit modulus)

Warning

TNSR supports modp768 (Group 1) and modp1024 (Group 2) for compatibility purposes but they are considered broken by the Logjam Attack and should be avoided.

TNSR also supports modp1024s160 (Group 22), modp2048s224 (Group 23), and modp2048s256 (Group 24) for compatibility but they should also be avoided as they have a questionable source of primes.

IKE Proposal Example

This example configures one proposal. This proposal uses AES-128 encryption, SHA-1 for integrity hashing, and DH group 14 (2048 bit modulus).

tnsr(config-ipsec-crypto-ike)# proposal 1
tnsr(config-ike-proposal)# encryption aes128
tnsr(config-ike-proposal)# integrity sha1
tnsr(config-ike-proposal)# group modp2048
tnsr(config-ike-proposal)# exit