Traditional IPsec Versus Cisco SD-WAN IPsec

In traditional IPsec, two IKE tunnels are built in order to establish a VPN Site to Site:

Phase 1 Isakmp Tunnel: Negociated between peers to protect the Phase 2 IPsec Tunnel negociation. In this step the authentication occurs between peers using either PSK or Certificates, the type of encryption and hashing.

Phase 2 IPsec Tunnel: parameters are negociated securely through the Tunnel of Phase 1 such as Encryption Algorithm and HMAC, AH or ESP protocols. This tunnel is to protect the users’s Data.

Now the Encrypted Key of the Encryption Algorithm that will be used to protect our Data in the IPsec Tunnel is negociated via Diffie-Hellman in the Phase 1 and protected by the ISAKMP Tunnel.

In SD-WAN, the developpers changed and optimized the IPsec Operation by removing the Phase 1 (ISAKAMP Tunnel) which traditionally handles key exchanges because the IKE negociation can become a scalability issue when a network grows larger and larger and impact the CPU.

-First: there is no need for peers to authenticate each other, since the vEdges routers are initially joined the Overlay SD-WAN by authenticatin these devices.

-Second: a secure control plane with DTLS is already built between vEdges and vSmart and we can leverage this for Data Plane negociation (our Phase 2 IPsec Tunnel), so instead of having several IKE negociation and phases 1 between each pair of vEdges, each vEdge will generate its own encrypted key and sent it to vSmart through OMP Route inside the DTLS tunnel, the vSmart replicates these encrypted keys between vEdges using also the same DTLS.

In short the traditional phase 1 negociation is done within the control plane. Since the vEdges has already a Tunnel (DTLS) to the Control Plane vSmart.

Removing the Phase 1 optimizes the IPsec negociation by reducing CPU resources for vEdges by centralizing the KEY exchanges negociation through vSmart.

But we lost the RFC 3947 Negotiation of NAT-Traversal built-in in the Traditional IPsec in order to solve the NAT issue when a peer is behing a NAT device.

To overcome this problem, a Stun Protocol is introduced to replace the traditional NAT-T mechanism. Like in Collaboration either in MRA deployment or WebRTC with Cisco CMS where Cisco Expressway-E plays a role of the Stun/Turn Server. The vBond is the Expressway in the SD-WAN architecture, it is the Stun server that the vEdge behind the NAT will solicit in order to discover its own Public IP.

Published by:

Redouane MEDDANE

Redouane MEDDANE is Cisco Instructor CCSI #35458, 3xCCNP Collaboration, Security and Enterprise and he a published author of some of the most important OSPF Protocol, Security and Collaboration books in the world titled OSPF Demystified With RFC, Network Security All-in-one, and Dial Plan and Call Routing Demystified on CUCM. He is also a blogger at ipdemystify.com and writes articles about collaboration and security to demystify the most complex topics. His books are known for their technical depth and accuracy especially the OSPF Demystified With RFC book, which is considered as the best OSPF book in the world and named "One of the best OSPF ebooks of all time" by BookAuthority It gives you a hint at the ability to explain complex topics with remarkable ease. He worked as a Cisco Instructor and consultant indifferent Cisco Learning Partner and awarded twice as Cisco Distinguished Instructor Award and Cisco Security Instructor Excellence Award on 2018 and 2019, and Cisco Collaboration Instructor Excellence Award on 2020. The Distinguished Instructor Award recognizes the top 5% of Cisco's most influential CCSI's who provide the highest quality training experience and demonstrate the best overall instructor performance across multiple Cisco technologie and Instructor Excellence Award recognizes the top 25% of elite CCSIs being recognized for delivering top quality training and maintaining high customer satisfaction in their field of expertise.

Categories SecurityLeave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s