ISR Computing -

CCIE Security - Basic LAN-to-LAN VPN Setup

IKE (Internet Key Exchange) is an implementation of ISAKMP Framework. IKE has 2 phases:

1. IKE Phase 1 deals with (uses bidirectional UDP/500):

   • Authenticates and protects the identities of the IPSec peers

   • Negotiates a matching IKE SA policy between peers to protect the IKE exchange

   • Performs an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys

   • Sets up a secure tunnel to negotiate IKE phase 2 parameters

2. IKE Phase 2 deals with (uses ESP-50, or AH-51, or UDP/4500:

   • Negotiates IPSec SA parameters protected by an existing IKE SA

   • Establishes IPSec security associations

   • Periodically renegotiates IPSec SAs to ensure security

   • Optionally performs an additional Diffie-Hellman exchange

IKE Phase 1 has 2 modes:

1. Main mode has three two-way exchanges between the initiator and the receiver:

   • First exchange: The algorithms and hashes used to secure the IKE communications are agreed upon in matching IKE SAs in each peer.

   • Second exchange: Uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret keys and to pass nonces—random numbers sent to the other party and then signed and returned to prove their identity.

   • Third exchange: Verifies the other side's identity. The identity value is the IPSec peer's IP address in encrypted form. The main outcome of main mode is matching IKE SAs between peers to provide a protected pipe for subsequent protected ISAKMP exchanges between the IKE peers. The IKE SA specifies values for the IKE exchange: the authentication method used, the encryption and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA in seconds or kilobytes, and the shared secret key values for the encryption algorithms. The IKE SA in each peer is bi-directional.

   • ISAKMP SA peers must agree on keys, encryption type (des/3des/aes), integrity check (md5/sha), DH Group (1/2/5/7)

2. Aggressive Mode
   • Fewer exchanges are made, and with fewer packets. The weakness of using the aggressive mode is that both sides have exchanged information before there's a secure channel. Therefore, it's possible to "sniff" the wire and discover who formed the new SA. However, it is faster than main mode.

Deffie-Helman is a way to establish secure tunnel between two endpoints.

When Lifetime expires, Phase 1 and 2 will be renegotiated, but Deffie-Helman keys stay the same.
To force system to renegotiate Deffie-Helman keys, we can use Perfect Forward Secrecy (PFS), which ensures that each new cryptographic key is unrelated to any previous key.

There are two protocols employed by IKE Phase 2:

• Encapsulating Security Payload (ESP)
• Authentication Header (AH)

Both of them can run in two modes:

• Transport - AH/ESP is run only on payload, can only be used for RFC1918, no the Internet. All the host in the VPN path must know routes for both source and destination of the packet.
• Tunnel - AH/ESP is run on entire packet. Used for LAN-to-LAN traffic.

Debugging

• Phase I:

  # show crypto isakmp sa
  # debug crypto isakmp

• Phase II:

  # show crypto ipsec sa
  # debug crypto ipsec

Basic IOS IPSec Configuration consists of the following

1. define access-list to match interesting traffic
2. define ISAKMP policy: keys/encryption/hash/DH (most secure first)
3. define IPSec policy: transform sets
4. apply crypto map on the interface
5. verification and troubleshooting