Tip
This is the documentation for the 19.02 version. Looking for the documentation of the latest version? Have a look here.
- orphan:
IKE Proposal¶
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
IKE Proposals instruct TNSR how the key exchange will be encrypted and
authenticated. TNSR supports a variety of encryption algorithms,
integrity / authentication hash algorithms, and Diffie-Hellman (DH)
group specifications. These choices must be coordinated between both
endpoints.
To see a list of supported choices for each option, follow the initial command
with a ?, such as encryption ?.
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.
Encryption Algorithms¶
TNSR supports many common, secure encryption algorithms. Some older, insecure, algorithms are not supported such as 3DES.
Algorithms based on AES are the most common, 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 be accelerated by AES-NI in most cases.
A full list of encryption algorithms supported by TNSR :
tnsr(config-ike-proposal)# encryption ?
<cr>
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 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, ensuring that packets are authentic and were not altered by a third party before arriving.
When an authenticated encryption algorithm type such as AES-GCM is used, then
for IKE/ISAKMP this option defines the Pseudo-Random Function (PRF) instead.
In these cases aesxcbc is likely the most appropriate choice as it is solely
a PRF, it can be accelerated by AES-NI, and it is more widely supported than its
improved successor aescmac.
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.
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
Diffie-Hellman Group¶
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)
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.