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.
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.
config-ipsec-crypto-ike mode, use the
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.
To see a list of supported choices for each option, follow the initial
command with a
?, such as
Each of these is described in more detail in the following sections.
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.
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 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.
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
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.
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
A full list of pseudo-random function 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 (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.
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> 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)
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),
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