Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software
Information About Implementing IKE Security Protocol Configurations for IPSec Networks
SC-24
Cisco IOS XR System Security Configuration Guide
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 that is 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.)
If no acceptable match is found, IKE refuses negotiation and IPSec is not established.
If a match is found, IKE completes negotiation, and IPSec security associations are created.
Note Depending on which authentication method is specified in a policy, additional configuration might be
required (as described in the “Additional Configuration Required for IKE Policies” section on page 25).
If a peer’s policy does not have the required companion configuration, the peer does not submit the
policy when attempting to find a matching policy with the remote peer.
Value Selection for Parameters
You can select certain values for each parameter, following the IKE standard. But why choose one value
over another?
If you are interoperating with a device that supports only one of the values for a parameter, your choice
is limited to the value supported by the other device. Aside from this, a trade-off between security and
performance often exists, and many of these parameter values represent such a trade-off. You should
evaluate the level of security risks for your network and your tolerance for these risks. Then the
following tips might help you select which value to specify for each parameter:
• The encryption algorithm has five options: 56-bit DES-CBC, 168-bit DES, 128-bit AES, 192-bit
AES, and 256-bit AES.
• The hash algorithm has two options: SHA-1 and MD5.
MD5 has a smaller digest and is considered to be slightly faster than SHA-1. A demonstrated
successful (but extremely difficult) attack has been demonstrated against MD5; however, the HMAC
variant used by IKE prevents this attack.
• The authentication method has three options: RSA signatures, RSA encrypted nonces, and preshared
keys.
–
RSA signatures provide nonrepudiation for the IKE negotiation (you can prove to a third party
after the fact that you did indeed have an IKE negotiation with the remote peer).
RSA signatures allow the use of a CA. Using a CA can dramatically improve the manageability
and scalability of your IPSec network. Additionally, RSA signature-based authentication uses
only two public key operations, whereas RAS encryption uses four public key operations,
making it costlier in terms of overall performance.
You can also exchange the public keys manually, as described in the “Manually Configuring
RSA Keys” section on page 44.
–
RSA encrypted nonces provide repudiation for the IKE negotiation (you cannot prove to a third
party that you had an IKE negotiation with the remote peer).
RSA encrypted nonces require that peers possess each other’s public keys but do not use a
certification authority. Instead, two ways exist for peers to get each other’s public keys:
–
During configuration, you manually configure RSA keys (as described in the “Manually
Configuring RSA Keys” section on page 44).
To Next Page
Loading...
Need help?
General
