This is the documentation for the 19.02 version. Looking for the documentation of the latest version? Have a look here.
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
integrity / authentication hash algorithms, and Diffie-Hellman (DH)
group specifications. These choices must be coordinated between both
To see a list of supported choices for each option, follow the initial command
?, such as
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.
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 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
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 (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.