CCNA Security 210-260: Module 2: Virtual Private Networks (VPNs), Lesson 4: Fundamentals of IP Security


Lesson 4: Fundamentals of IP Security
4.1 IPsec Concepts, Components, and Operations
4.2 IKE version 1 Fundamentals
4.3 IKE version 2 Fundamentals


4.1 IPsec Concepts, Components, and Operations

The Internet Key Exchange (IKE) Protocol
– IPsec uses IKE protocol to negotiate and establish secured site-to-site or remote access virtual private network (VPN) tunnels.

– IKE is a framework provided by the Internet Security Association and Key Management Protocol (ISAKMP) and parts of two other key management protocols, namely Oakley and Secure Key Exchange Mechanism (SKEME).

– In IKE Phase 1: IPsec peers negotiate and authenticate each other. In Phase 2, they negotiate keying materials and algorithms for the encryption of the data being transferred over the IPsec tunnel.
Two versions of IKEs.
IKE v1: Defined in RFC 2409
IKE v2: Defined in RFC 4306

IKE Protocol Details:
– IKE v2 enhances the function of performing dynamic key exchange and peer authentication.
– IKE v2 simplifies the key exchange flows and introduces measures to fix vulnerabilities present in IKEv1.
– Both IKEv1 and IKEv2 protocols operate in two phases.
– IKEv2 provides a simpler and more efficient exchange.


4.2 IKE version 1 Fundamentals

IKEv1: Who begins the negotiation?
– The initiator sends over all of its IKE Phase 1 policies, and the other VPN peer looks at all of those policies to see whether any of its own policies match the ones it just received.
– If there is a matching policy, the recipient of the negotiations sends back information about which received policy matches, and they use that matching policy for the IKE Phase 1 tunnel.

IKEv1 Phase 1
A handy way to recall the five pieces involved in the negotiation of the IKE Phase 1 tunnel, you might want to remember that the two devices HAGLE over IKE Phase 1:

H: Hash
A: Authentication Method
G: DH group (a stretch, but it works)
L: Lifetime of the IKE Phase 1 tunnel
E: Encryption algorithm to use for the IKE Phase 1 tunnel
The DH (Diffie-Hellman) Exchange
– Now having agreed to the IKEv1 Phase 1 policy of the peer, the two devices run the DH key exchange.
– They use the DH group (DH key size for the exchange) they agreed to during the negotiations, and at the end of this key exchange they both have symmetrical keying material (which is a fancy way of saying they both have the same secret keys that they can use with symmetrical algorithms).
– DH allows two devices that do not yet have a secure connection to establish shared secret keying material (keys that can be used with symmetrical algorithms, such as AES).
Authenticating the peer (last step in IKEv1 phase 1)
– The last step of IKE Phase 1 is to validate or authenticate the peer on the other side.
– For Authentication, they use whatever they agreed to in the initial proposal/policy, and if they successfully authenticate with each other, we now have an IKE Phase 1 tunnel in place between the two VPN gateways.
– The authentication could be done either using a PSK or using RSA digital signatures.


Phase 1:
– The next step is to complete the IKEv1 Phase 2 negotiation.
– The entire conversation and negotiation of the IKEv1 Phase 2 tunnel are completely done in private because of the IKEv1 Phase 1 tunnel protection the negotiated traffic.
– The IKE Phase 2 tunnel includes the hashing and encryption algorithms.
– The name of the mode for building the IKE Phase 2 tunnel is called “Quick Mode“.
4.3 IKE version 2 Fundamentals

What’s different in IKEv2?

* IKEv2 does not consume as much bandwidth as IKEv1.
* IKEv2 supports EAP authentication while IKEv1 doesn’t.
* IKEv2 supports the Mobility and Multi-homing (MOBIKE) protocol while IKEv1 doesn’t.
* IKEv2 has built-in NAT traversal while IKEv1 doesn’t.

** UDP port 4500 is used.
*** Protocol 50 (ESP) or 51 (AH)
*** NAT Transversal need to be used on UDP port 4500

IKEv2 Phase 2
* Phase 2 in IKEv2 is CHILD_SA (Child Security Association)
* The first CHILD_SA is the IKE_AUTH message pair.
* This phase is comparable to IKEv1 Phase 2.
* Additional CHILD_SA message pairs can be sent for rekey and informational messages.
* The CHILD_SA attributes are defined in the Data Policy.




Leave a Reply

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

You are commenting using your 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