multi-cloud networking

Cisco C8000v Autonomous IPSEC Configuration

Recommended 

crypto ikev2 proposal IKEV2-PROP 
 encryption aes-gcm-256
 prf sha512
 group 19
!
crypto ikev2 policy IKEV2-POLICY 
 proposal IKEV2-PROP
!
crypto ikev2 keyring IKEV2-KEYRING
 peer SITEB
  address 162.43.158.29
  pre-shared-key local Str0ngSecret!
  pre-shared-key remote Str0ngSecret!
 !
!
crypto ikev2 profile IKEV2-PROFILE
 match identity remote address 162.43.158.29 255.255.255.255 
 identity local address 162.43.158.41
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEV2-KEYRING
 dpd 10 5 on-demand
!
crypto ipsec transform-set TS-ESP-GCM esp-gcm 256 
 mode tunnel
!
crypto ipsec profile IPSEC-PROFILE
 set transform-set TS-ESP-GCM 
 set ikev2-profile IKEV2-PROFILE
!         
interface Tunnel10
 description IKEv2 VTI to 162.43.158.29
 ip address 10.10.10.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel mode ipsec ipv4
 tunnel destination 162.43.158.29
 tunnel protection ipsec profile IPSEC-PROFILE
!

For environments where GCM is not supported:


crypto ikev2 proposal oracle_v2_proposal 
 encryption aes-cbc-256
 integrity sha384
 group 14
!
crypto ikev2 policy oracle_v2_policy 
 proposal oracle_v2_proposal
!
crypto ikev2 keyring oracle_keyring_tunnel1
 peer oracle_vpn
  address 129.146.159.116
  pre-shared-key local <pre-shared key>
  pre-shared-key remote <pre-shared key>
 !      
!
crypto ikev2 profile oracle_ike_profile_tunnel1
 match identity remote address 129.146.159.116 255.255.255.255 
 identity local address 162.43.155.57
 authentication remote pre-share
 authentication local pre-share
 keyring local oracle_keyring_tunnel1
!
crypto ipsec transform-set oracle-vpn-transform esp-aes 256 esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile oracle_ipsec_profile_tunnel1
 set transform-set oracle-vpn-transform 
 set pfs group14
 set ikev2-profile oracle_ike_profile_tunnel1
!
interface Tunnel100
 ip address 169.254.0.1 255.255.255.252
 tunnel source 162.43.155.57
 tunnel mode ipsec ipv4
 tunnel destination 129.146.159.116
 tunnel protection ipsec profile oracle_ipsec_profile_tunnel1
!

IKEv2/IPSec Algorithm Cheat Sheet

Phase 1 – IKEv2 (Control Channel)

Purpose: Establish a secure, authenticated channel for negotiating IPsec.

CategoryAlgorithm OptionsExplanation
EncryptionAES-CBC-128 / AES-CBC-256AES in CBC mode; strong encryption but needs separate integrity (HMAC).
AES-GCM-128 / AES-GCM-256AES in Galois/Counter Mode; provides encryption + integrity (AEAD).
PRFSHA1Legacy; avoid for new deployments.
SHA256Recommended minimum; widely supported.
SHA384 / SHA512Stronger hash for high-security environments; more CPU cost.
Diffie-HellmanGroup 14 (MODP 2048-bit)Classic DH; secure but slower than elliptic curve.
Group 19 (ECDH P-256)Elliptic Curve DH; fast and secure; best practice for modern VPNs.
Group 20 (ECDH P-384)Higher security elliptic curve; more CPU cost.

Phase 2 – IPsec (Data Channel)

Purpose: Encrypt and protect actual traffic between sites.

CategoryAlgorithm OptionsExplanation
Encryption (ESP)AES-CBC-128 / AES-CBC-256Encrypts payload; requires separate integrity algorithm (HMAC).
AES-GCM-128 / AES-GCM-256Encrypts + authenticates in one step; preferred for performance/security.
Integrity (ESP)HMAC-SHA1Adds integrity/authentication; legacy, avoid for new deployments.
HMAC-SHA256 / SHA384 / SHA512Strong integrity checks; used with AES-CBC (not needed with GCM).
ModeTunnelEncrypts entire original IP packet; standard for site-to-site VPNs.
TransportEncrypts only payload; used for host-to-host or GRE over IPsec.
PFSSame DH group as Phase 1Adds extra DH exchange for forward secrecy; recommended for high security.

Why GCM is Faster

  • AES-GCM uses Counter mode (CTR) for encryption and Galois field multiplication for authentication, which can be parallelized.
  • AES-CBC encrypts blocks sequentially (each block depends on the previous), so it cannot be parallelized for encryption.
  • GCM also eliminates the need for a separate integrity algorithm (HMAC), reducing overhead.

Why ECDH is Faster

  1. Smaller Key Sizes for Same Security
    • Classic DH (MODP) needs very large primes (e.g., 2048-bit for Group 14) to achieve strong security.
    • ECDH achieves equivalent security with much smaller keys (e.g., 256-bit for Group 19).
    • Smaller keys mean less data to exchange and fewer operations.
  2. Efficient Mathematical Operations
    • MODP DH uses modular exponentiation, which is computationally expensive and grows with key size.
    • ECDH uses elliptic curve point multiplication, which is much more efficient for the same security level.
  3. Lower CPU Cycles
    • Modular exponentiation involves repeated multiplications and reductions on large integers.
    • Elliptic curve operations are optimized and require fewer CPU cycles, especially with hardware acceleration.
  4. Better Hardware Support
    • Modern CPUs and crypto libraries often include optimized routines for elliptic curve math.
    • ECDH benefits from acceleration (e.g., Intel AES-NI and ECC instructions), while MODP DH gains less.

Leave a Reply