Tip
This is the documentation for the 20.02 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