Configure a Router for IKE Using Pre-shared Keys
Step 2 – Create IKE policies

IKE policies must be created at each peer. An IKE policy defines a combination of security parameters to be used during the IKE negotiation. An IKE policy is created with the crypto isakmp policy priority command .

Why Do These Policies Need to Be Created?
IKE negotiations must be protected, so each IKE negotiation begins by agreement of both peers on a common shared IKE policy. This policy states which security parameters will be used to protect subsequent IKE negotiations and mandates how the peers are authenticated.

After the two peers agree upon a policy, the security parameters of the policy are identified by a security association (SA) established at each peer, and these security associations apply to all subsequent IKE traffic during the negotiation.

Multiple, prioritized policies must be created at each peer to ensure that at least one policy will match the policy of a remote peer.

Parameters Defined in a Policy
There are five parameters to define in each IKE policy, as shown in Figure . These parameters apply to the IKE negotiations when the IKE security association is established.

Multiple IKE policies can be created, each with a different combination of parameter values. A unique priority number is assigned for each policy that is created. At least one of these policies must contain exactly the same encryption, hash, authentication, and Diffie-Hellman parameter values as one of the policies on the remote peer.

If no policies are configured, the router will use the default policy, which is always set to the lowest priority, and which contains the default value of each parameter. To configure a policy, use the commands shown in Figure , beginning in global configuration mode . If a value for a parameter is not specified, the default value is assigned.

NOTE:

The default policy and the default values for configured policies do not show up in the configuration when a show running configuration command is issued. Instead, to see the default policy and any default values within configured policies, use the show crypto isakmp policy command.

ISAKMP Policy Negotiation
ISAKMP peers negotiate acceptable ISAKMP policies before agreeing upon the SA to be used for IPSec. When the ISAKMP negotiation begins in IKE phase one main mode, ISAKMP looks for an ISAKMP policy that is the same on both peers. The peer that initiates the negotiation sends all its policies to the remote peer, and the remote peer tries to find a match with its policies. The remote peer looks for a match by comparing its own highest priority policy against the policies received from the peer. The remote peer checks each of its policies in order of its priority, checking the highest priority first, until a match is found.

A match is made when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer's policy specifies a lifetime less than or equal to the lifetime in the policy being compared. If the lifetimes are not identical, the shorter lifetime from the remote peer's policy is used. Assign the most secure policy the lowest priority number so that the most secure policy will find a match before any less secure policies configured .

If no acceptable match is found, ISAKMP refuses negotiation and IPSec is not established. If a match is found, ISAKMP completes the main mode negotiation, and IPSec SAs are created during IKE phase two quick mode.

ISAKMP Identity
The ISAKMP identity should be set for each peer that uses pre-shared keys in an IKE policy . When two peers use IKE to establish IPSec security associations, each peer sends its identity to the remote peer. Each peer sends either its host name or its IP address, depending on how the ISAKMP identity of the router has been set up.

By default, a peer's ISAKMP identity is the IP address of the peer. If appropriate, the identity could be changed to be the peer's host name instead . As a general rule, set the identities of all peers the same way. Either all peers should use their IP addresses or all peers should use their host names. If some peers use their host names and some peers use their IP addresses to identify themselves to each other, IKE negotiations could fail if the identity of a remote peer is not recognized and a DNS lookup is unable to resolve the identity.