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.