IKE Aggressive Mode Behavior

IKE Aggressive Mode Behavior

This section describes IKE aggressive mode behavior occurring when Cisco IOS software is used.

IKE has two phases of key negotiation: phase 1 and phase 2. Phase 1 negotiates a security association (a key) between two IKE peers. The key negotiated in phase 1 enables IKE peers to communicate securely in phase 2. During phase 2 negotiation, IKE establishes keys (security associations) for other applications, such as IPSec.

Phase 1 negotiation can occur using one of two modes: main mode and aggressive mode. Main mode tries to protect all information during the negotiation, meaning that no information is available to a potential attacker. When main mode is used, the identities of the two sides are hidden. Although this mode of operation is very secure, it is relatively costly in terms of the time it takes to complete the negotiation. Aggressive mode takes less time to negotiate keys between peers; however, it gives up some of the security provided by main mode negotiation. For example, the identities of the two parties trying to establish a security association are exposed to an eavesdropper.

The two modes serve different purposes and have different strengths. Main mode is slower than aggressive mode, but main mode is more secure and more flexible because it can offer an IKE peer more security proposals than aggressive mode. Aggressive mode is less flexible and not as secure, but much faster.

In Cisco IOS software, the two modes are not configurable. The default action for IKE authentication (rsa-sig, rsa-encr, or preshared) is to initiate main mode; however, in cases where there is no corresponding information to initiate authentication, and there is a preshared key associated with the host name of the peer, Cisco IOS software can initiate aggressive mode. Cisco IOS software will respond in aggressive mode to an IKE peer that initiates aggressive mode.

Whether Cisco IOS software initiates main mode or aggressive mode, the following restrictions are applicable:

•The initiating router must not have a certificate associated with the remote peer.

•The preshared key must be by fully qualified domain name (FQDN) on both peers.; thus, you have to enter the crypto isakmp key keystring hostname peer-address command in configuration mode.

•The communicating routers must have a FQDN host entry for each other in their configurations.

•The communicating routers must be configured to authenticate by hostname, not by IP address; thus, you should use the crypto isakmp identity hostname command.