Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software
Information About Implementing IKE Security Protocol Configurations for IPSec Networks
SC-25
Cisco IOS XR System Security Configuration Guide
–
If your local peer has previously used RSA signatures with certificates during a successful IKE
negotiation with a remote peer, your local peer already possesses the remote peer’s public key.
(The peers’ public keys are exchanged during the RSA-signatures-based IKE negotiations, if
certificates are used.)
–
Preshared keys are clumsy to use if your secured network is large, and they do not scale well
with a growing network. However, they do not require use of a certification authority, as do RSA
signatures, and might be easier to set up in a small network with fewer than ten nodes. RSA
signatures also can be considered more secure when compared with preshared key
authentication.
• The Diffie-Hellman group identifier has three options: 768-bit, 1024-bit Diffie-Hellman, and
1536-bit Diffie Helman.
The 1024-bit Diffie-Hellman and 1536-bit Diffie Helman options are harder to crack but require
more CPU time to execute.
• The lifetime of the security association can be set to any value.
As a general rule, the shorter the lifetime (up to a point), the more secure your IKE negotiations.
However, with longer lifetimes, future IPSec security associations can be set up more quickly. For
more information about this parameter and how it is used, see the command description for the
lifetime command.
Policy Creation
You can create multiple IKE policies, each with a different combination of parameter values. For each
policy that you create, assign a unique priority (1 through 10,000, with 1 being the highest priority).
You can configure multiple policies on each peer—but 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. (The lifetime parameter need not necessarily be the same; see details in the “IKE
Peer Agreement for Matching Policies” section on page 23.)
If you do not configure any policies, your router uses the default policy, which is always set to the lowest
priority and contains the default value of each parameter.
Additional Configuration Required for IKE Policies
Depending on the authentication method you specify in your IKE policies, you must perform certain
additional configuration tasks before IKE and IPSec can successfully use the IKE policies.
Each authentication method requires additional companion configuration as follows:
• RSA signatures method. If you specify RSA signatures as the authentication method in a policy, you
may configure the peers to obtain certificates from a CA. (The CA must be properly configured to
issue the certificates.) Configure this certificate support as described in the module “Implementing
Certification Authority Interoperability.”
The certificates are used by each peer to exchange public keys securely. (RSA signatures require that
each peer has the public signature key of the remote peer.) When both peers have valid certificates,
they automatically exchange public keys with each other as part of any IKE negotiation in which
RSA signatures are used.
You may also want to exchange the public keys manually, as described in the “Manually Configuring
RSA Keys” section on page 44.
• RSA encrypted nonces method. If you specify RSA encrypted nonces as the authentication method
in a policy, you must ensure that each peer has the public keys of the other peers.
To Next Page
Loading...
Need help?
General
