CCIE Study Notes

ISAKMP stands for Internet Security Association and Key Management Protocol. Cisco's document on Configuring IPsec and ISAKMP seems to equate IKE and ISAKMP. This is not exactly true, but is close enough for the most part. ISAKMP is a part of IKE, and is also the keyword used to configure IPsec.

ISAKMP Phase 1 creates the first tunnel - which protects ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data. There are 5 steps to create an ISAKMP Policy (this could be a drag-and-drop question). Since I have configured this in production and have familiarity with it, I am going to list the steps and an example (versus all the possible values).

Step 1. Specify the encryption algorithm.
crypto isakmp policy 10 encryption aes-192

Step 2. Specify the hash algorithm.
crypto isakmp policy 10 hash md5

Step 3. Specify the authentication method.
crypto isakmp policy 10 authentication pre-share

Step 4. Specify the Diffie-Helman group identifier.
crypto isakmp policy 10 group 5

Step 5. Specify the SA lifetime.
crypto isakmp policy 10 lifetime 14400

I guess one way to remember the order is EHADS - which is similar to EGADS (expression of surprise that this is on the test). Lame, but might work. I've seen (created) worse mnemonics.

Negotiated Parameters that need to match:
* Authentication
* Encryption
* Hashing
* D-H group

I have some notes about ASA vs IOS regarding ISAKMP. For ASA you must enable ISAKMP on the interface where the crypto map will be applied. IOS has this enabled by default. Also, for ASA you must configure ISAKMP policies - it has no default policy (IOS has a default policy). For psk, create tunnel-group/connection profile and specify the pre-shared key. For rsa-sig, perform PKI enrollment, create tunnel-group/connection profile and bind the certificate. [For Phase 2, IOS and ASA are the same.]

So let's continue with IKEv1 Phase 1. It can use Main Mode or Aggressive Mode. Main mode uses 6 message types and Aggressive Mode uses 3 message types. The diagram below represents these messages. The blue is one direction and the green is the opposite direction. [It does not matter who really initiates this exchange.]

Aggressive mode has limited SA negotiation capabilities. The DH group cannot be negotiated and authentication with public key cryptography cannot be negotiated. Nothing is encrypted and identities are sent in the clear. If you use this, you have to know and agree on settings in advance. Not easy to troubleshoot and will fail if all is not exactly correct. [You can see why this is not often used.]

I have some notes about IKEv1 Extensions:
* CRACK - Challenge Response Authentication for Cryptographic Keys (yes, this is real and not a distractor)
* Extended Authentication xauth
* PIC - Pre-IKE Credential Provisioning Protocol
* Mode Configuration config mode
* DHCP Configuration
* Dead peer detection
* NAT Traversal -- uses UDP encapsulation on port 4500 (versus 500)

IKEv1 Phase 2 only has Quick Mode. All messages are encrypted using the encryption key derived from the Phase 1 exchange.

Phase 2 concerns what to protect and how to protect it. Two additional keys are derived from Phase 1 keying material by default (unless PFS is enabled). These keys are used to encrypt data through the IPsec tunnel. The things that need to match are what to protect (proxy-ACL/encryption domain) and how to protect it (transform-set). There must be a match for the Encapsulation Protocol, Encryption, Hashing and Tunnel mode. What does not need to match are the SA lifetime in seconds and traffic volume. The end with the higher values needs to initiate the tunnel.

IKEv1 IPsec VPN Types: Crypto-map (static and dynamic) [IOS & ASA], SVTI [IOS], DVTI [IOS] and GRE with IPsec (P2P and P2M - includes DMVPN) [IOS]. Note: GETVPN on IOS only!

The Cisco Doc for IKEv2 and some of the study materials are a bit outdated. Things move so quickly in the world of computing. I went to the RFCs and found that (as in the study materials) RFC 4306 [IKEv2] did indeed replace RFC 2407 [DOI], RFC 2408 [ISAKMP] and RFC 2409 [IKEv1] of IKEv1. However, RFC 4306 [IKEv2] was obsoleted by RFC 5996 - which was further obsoleted by RFC 7296 (the current version today). As I clicked from one RFC to the other, it reminded me of the Twilight Zone episode - The Obsolete Man. Perhaps that is a way to remember this.

IKEv2 runs in a SINGLE phase. There are mandatory messages and optional messages. It can push routes into IPsec peer routing table (similar to, but different from RRI). Xauth not implemented in IKEv2 - EAP is used instead.

## MANDATORY MESSAGES ##

IKE_SA_INIT - This first pair of messages negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Helman exchange.

IKE_AUTH - This second pair of messages authenticate the previous messages, exchange identities and certificates, and establish the first Child SA.

## OPTIONAL MESSAGES ##

CREATE_CHILD_SA - This is any other message that comes after the IKE_AUTH. This is how rekeying is performed. A Child SA is created and the old one deleted.

INFORMATIONAL - These are normally exchanges that are error messages. They can also be used to delete SAs or have a null payload and be used for some type of "keepalive" or more accurately an "alive" verification.

So I'm looking at the IKEv2 configuration section of the Cisco Doc and thinking that maybe that those details would be more likely on the lab exam than the written exam. And I do remember the videos that went over this in detail, so I'm going to paint this with broad strokes.

++ Configure the IKEv2 Proposal {encryption, integrity, group}
++ Configure the IKEv2 Policy {the proposal is attached to a policy}
++ Configure the IKEv2 Keyring {if using preshared key}
++ Configure the IKEv2 Profile {nonnegotiable parameters of the IKE SA}
++ Configure the IKEv2 Name Mangler {used to derive a name for the authorization requests}
++ Configure the IKEv2 Authorization Policy {local AAA group authorization parameters}
++ Configure the IKEv2 Fragmentation {to avoid fragmentation after encryption}

And there is one last graphic that I want to add and discuss:

One note on the above - the training materials all say that IKEv1 does not support NAT-T but IKEv2 does. When I looked at the RFCs and Cisco Docs, I saw them mention that IKEv1 does actually support NAT-T. And from what I've seen, the biggest thing that everyone is pointing out about the difference is that IKEv2 supports EAP!!! I've seen that mentioned a lot, so that may be something important to remember.