Table Of Contents
Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software
Contents
Prerequisites
General Information About Implementing IKE Security Protocol Configurations for IPSec Networks
Supported Standards
Concessions for Not Enabling IKE
IKE Policies
IKE Policy Creation
Definition of Policy Parameters
IKE Peer Agreement for Matching Policies
Value Selection for Parameters
Policy Creation
Additional Configuration Required for IKE Policies
ISAKMP Identity
ISAKMP Profile Overview
ISAKMP Profile Considerations
Mask Preshared Keys
Preshared Keys Using a AAA Server
Internet Key Exchange Mode Configuration
Internet Key Exchange Extended Authentication
Call Admission Control
IKE Session
Security Association Limit
Information About IKE for the Cisco IPSec VPN SPA on Cisco IOS XR Software
IPSec Dead Peer Detection Periodic Message Option
How to Implement IKE Security Protocol Configurations for IPSec Networks
Enabling or Disabling IKE
Configuring IKE Policies
Defining Group Policy Information for Mode Configuration
Manually Configuring RSA Keys
RSA Keys Generation
Configuring ISAKMP Identity
Configuring RSA Public Keys of All the Other Peers
Configuring ISAKMP Preshared Keys in ISAKMP Keyrings
Prerequisites
Configuring Call Admission Control
Configuring the IKE Security Association Limit
Configuring the System Resource Limit
Configuring Crypto Keyrings
Crypto Keyrings Configuration Guidelines and Restrictions
How to Implement IKE for Locally Sourced and Destined Traffic
Configuring the ISAKMP Profile for Locally Sourced and Destined Traffic
How to Implement IKE for Cisco IPSec VPN SPAs on Cisco IOS XR Software
Configuring a Periodic Dead Peer Detection Message
Configuring the ISAKMP Profile for Service Interfaces
Configuration Examples for Implementing IKE Security Protocol
Creating IKE Policies: Example
Configuring a service-ipsec Interface with a Dynamic Profile: Example
Configuring Easy VPN with a Local AAA: Example
Configuring VRF-Aware: Example
Additional References
Related Documents
Standards
MIBs
RFCs
Technical Assistance
Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software
Internet Key Exchange (IKE) is a key management protocol standard that is used in conjunction with the IP Security (IPSec) standard. IPSec is a feature that provides robust authentication and encryption of IP packets.
IKE is a hybrid protocol that implements the Oakley key exchange and the Skeme key exchange inside the Internet Security Association and Key Management Protocol (ISAKMP) framework. (ISAKMP, Oakley, and Skeme are security protocols implemented by IKE.)
IPSec can be configured without IKE, but IKE enhances IPSec by providing additional features, flexibility, and ease of configuration for the IPSec standard.
This module describes the new and revised tasks you need to implement IKE on your Cisco IOS XR network.
Note 
For a complete description of the IKE commands used in this chapter, see the Internet Key Exchange Security Protocol Commands on Cisco IOS XR Software module of the Cisco IOS XR System Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index, or search online.
Feature History for Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software
Release
|
Modification
|
Release 2.0
|
This feature was introduced on the Cisco CRS-1.
|
Release 3.0
|
No modification.
|
Release 3.2
|
Support was added for the Cisco XR 12000 Series Router.
|
Release 3.3.0
|
No modification.
|
Release 3.4.0
|
•Support was added for IKE for the Cisco XR 12000 Series Router IPSec VPN SPA.
•Support was added to implement IKE for locally sourced and destined traffic on both the Cisco CRS-1 and Cisco XR 12000 Series Router.
|
Contents
•Prerequisites
•General Information About Implementing IKE Security Protocol Configurations for IPSec Networks
•Information About IKE for the Cisco IPSec VPN SPA on Cisco IOS XR Software
•How to Implement IKE Security Protocol Configurations for IPSec Networks
•How to Implement IKE for Locally Sourced and Destined Traffic
•How to Implement IKE for Cisco IPSec VPN SPAs on Cisco IOS XR Software
•Configuration Examples for Implementing IKE Security Protocol
•Additional References
Prerequisites
The following prerequisites are required to implement Internet Key Exchange:
•You must be in a user group associated with a task group that includes the proper task IDs for security commands. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide.
•You must install and activate the package installation envelope (PIE) for the security software.
For detailed information about optional PIE installation, see the Cisco IOS XR System Management Guide.
General Information About Implementing IKE Security Protocol Configurations for IPSec Networks
To implement IKE, you should understand the following concepts:
•Supported Standards
•Concessions for Not Enabling IKE
•IKE Policies
•ISAKMP Identity
•ISAKMP Profile Overview
•Mask Preshared Keys
•Preshared Keys Using a AAA Server
•Internet Key Exchange Mode Configuration
•Internet Key Exchange Extended Authentication
•Call Admission Control
Supported Standards
Cisco implements the following standards:
•IKE—Internet Key Exchange. A hybrid protocol that implements Oakley and Skeme key exchanges inside the ISAKMP framework. IKE can be used with other protocols, but its initial implementation is with the IPSec protocol. IKE provides authentication of the IPSec peers, negotiates IPSec keys, and negotiates IPSec security associations (SAs).
IKE is implemented following RFC 2409, The Internet Key Exchange.
•IPSec—IP Security Protocol. IPSec is a framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at the IP layer; it uses IKE to handle negotiation of protocols and algorithms based on local policy and to generate the encryption and authentication keys to be used by IPSec. IPSec is used to protect one or more data flows between a pair of hosts, a pair of security gateways, or a security gateway and a host.
For more information on IPSec, see the Implementing IPSec Network Security on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide.
•ISAKMP—Internet Security Association and Key Management Protocol. A protocol framework that defines payload formats, the mechanics of implementing a key exchange protocol, and the negotiation of a security association.
ISAKMP is implemented following the latest version of the Internet Security Association and Key Management Protocol (ISAKMP) Internet Draft (RFC 2408).
•Oakley—A key exchange protocol that defines how to derive authenticated keying material.
•Skeme—A key exchange protocol that defines how to derive authenticated keying material, with rapid key refreshment.
The component technologies implemented for use by IKE include the following:
•DES—Data Encryption Standard. An algorithm that is used to encrypt packet data. IKE implements the 56-bit DES-CBC with Explicit IV standard. Cipher Block Chaining (CBC) requires an initialization vector (IV) to start encryption. The IV is explicitly given in the IPSec packet.
Cisco IOS XR software also implements Triple DES (168-bit) encryption, depending on the software versions available for a specific platform. Triple DES (3DES) is a strong form of encryption that allows sensitive information to be sent over untrusted networks. It enables customers, particularly in the finance industry, to use network-layer encryption.
•AES—Advanced Encryption Standard. 128-bit, 192-bit, and 256-bit AESs are supported.
Note Cisco IOS XR images that have strong encryption (including, but not limited to, 56-bit data encryption feature sets) are subject to U.S. government export controls, and have a limited distribution. Images that are to be installed outside the United States require an export license. Customer orders might be denied or subject to delay because of U.S. government regulations. Contact your sales representative or distributor for more information, or send e-mail to export@cisco.com.
•Diffie-Hellman—A public-key cryptography protocol that allows two parties to establish a shared secret over an unsecure communications channel. Diffie-Hellman is used within IKE to establish session keys. 768-bit, 1024-bit, and 1536-bit Diffie-Hellman groups are supported.
•MD5 (HMAC variant)—Message Digest 5. A hash algorithm used to authenticate packet data. HMAC is a variant that provides an additional level of hashing.
•SHA (HMAC variant)—Secure Hash Algorithm. A hash algorithm used to authenticate packet data. HMAC is a variant that provides an additional level of hashing.
•RSA signatures and RSA encrypted nonces—RSA is the public key cryptographic system developed by Ron Rivest, Adi Shamir, and Leonard Adelman. RSA signatures provide nonrepudiation, and RSA encrypted nonces provide repudiation. (Repudiation and nonrepudiation are associated with traceability.)
IKE interoperates with the X.509v3 certificates standard. It is used with the IKE protocol when authentication requires public keys. This certificate support allows the protected network to scale by providing the equivalent of a digital ID card to each device. When two devices want to communicate, they exchange digital certificates to prove their identity (thus removing the need to manually exchange public keys with each peer or to manually specify a shared key at each peer).
Concessions for Not Enabling IKE
IKE is disabled by default in Cisco IOS XR software. If you do not enable IKE, you must make these concessions at the peers:
•You must manually specify all IPSec security associations in the crypto profiles at all peers. (Crypto profile configuration is described in the module Implementing IPSec Network Security on Cisco IOS XR Software.)
•The IPSec security associations of the peers never time out for a given IPSec session.
•During IPSec sessions between the peers, the encryption keys never change.
•Antireplay services are not available between the peers.
•Certification authority (CA) support cannot be used.
IKE Policies
You must create IKE policies at each peer. An IKE policy defines a combination of security parameters to be used during the IKE negotiation.
Before you create and configure IKE policies you should understand the following concepts:
•IKE Policy Creation
•Definition of Policy Parameters
•IKE Peer Agreement for Matching Policies
•Value Selection for Parameters
•Policy Creation
•Additional Configuration Required for IKE Policies
IKE Policy Creation
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 on a policy, the security parameters of the policy are identified by a security association established at each peer, and these security associations apply to all subsequent IKE traffic during the negotiation.
You can create multiple, prioritized policies at each peer to ensure that at least one policy matches the policy of a remote peer.
Definition of Policy Parameters
Table 2 lists the five parameters to define in each IKE policy.
Table 2 IKE Policy Parameter Definitions
Parameter
|
Accepted Values
|
Keyword
|
Default Value
|
Encryption algorithm
|
56-bit DES-CBC
168-bit DES
128-bit AES
192-bit AES
256-bit AES
|
des
3des
aes
aes 192
aes 256
|
56-bit DES-CBC
|
Hash algorithm
|
SHA-1 (HMAC variant)
MD5 (HMAC variant)
|
sha
md5
|
SHA-1
|
Authentication method
|
RSA signatures
RSA encrypted nonces
Preshared keys
|
rsa-sig
rsa-encr
pre-share
|
RSA signatures
|
Diffie-Hellman group identifier
|
768-bit Diffie-Hellman or
1024-bit Diffie-Hellman
1536-bit Diffie-Helman
|
1
2
5
|
768-bit Diffie-Hellman
|
Lifetime of the security association1
|
Any number of seconds
|
—
|
86400 seconds (1 day)
|
I
These parameters apply to the IKE negotiations when the IKE security association is established.
IKE Peer Agreement for Matching Policies
When the IKE negotiation begins, IKE looks for an IKE policy that is the same on both peers. The peer that initiates the negotiation will send all its policies to the remote peer, and the remote peer will try to find a match. The remote peer looks for a match by comparing its own highest priority policy against the policies received from the other peer. The remote peer checks each of its policies in order of its priority (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 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). 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.
–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).
–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.)
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.
•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.
Unlike RSA signatures, the RSA encrypted nonces method cannot use certificates to exchange public keys. Instead, you ensure that each peer has the others' public keys by one of the following methods:
–Manually configuring RSA keys, as described in the "Manually Configuring RSA Keys" section.
–Ensuring that an IKE exchange using RSA signatures with certificates has already occurred between the peers. (The peers' public keys are exchanged during the RSA-signatures-based IKE negotiations if certificates are used.)
To make this happen, specify two policies: a higher-priority policy with RSA encrypted nonces and a lower-priority policy with RSA signatures. When IKE negotiations occur, RSA signatures are used the first time because the peers do not yet have each other's public keys. Then future IKE negotiations are able to use RSA encrypted nonces because the public keys will have been exchanged.
This alternative requires that you have certification authority support configured.
•Preshared keys authentication method. If you specify preshared keys as the authentication method in a policy, you must configure these preshared keys as described in the "Configuring ISAKMP Preshared Keys in ISAKMP Keyrings" section.
If RSA encryption is configured and signature mode is negotiated (and certificates are used for signature mode), the peer requests both signature and encryption keys. Basically, the router requests as many keys as the configuration supports. If RSA encryption is not configured, it just requests a signature key.
ISAKMP Identity
You should set the ISAKMP identity for each peer that uses preshared 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 hostname or its IP address, depending on how you have set the ISAKMP identity of the router.
By default, the ISAKMP identity of a peer is the IP address of the peer. If appropriate, you could change the identity to be the peer's hostname 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 domain name server (DNS) lookup is unable to resolve the identity.
ISAKMP Profile Overview
The ISAKMP profile is an enhancement to Internet Security Association and Key Management Protocol (ISAKMP) configurations. It enables modularity of ISAKMP configuration for phase 1 negotiations. This modularity allows mapping different ISAKMP parameters to different IP Security (IPSec) tunnels, and mapping different IPSec tunnels to different VPN forwarding and routing (VRF) instances. Currently, many applications and enhancements use the ISAKMP profile, including quality of service (QoS), router certificate management, and Multiprotocol Label Switching (MPLS) VPN configurations.
An ISAKMP profile is a repository for IKE Phase 1 and IKE Phase 1.5 configuration for a set of peers. An ISAKMP profile applies parameters to an incoming IPSec connection identified uniquely through its concept of match identity criteria. These criteria are based on the IKE identity that is presented by incoming IKE connections and includes IP address, fully qualified domain name (FQDN), and group (the Virtual Private Network [VPN] remote client grouping). The granularity of the match identity criteria imposes the granularity of applying the specified parameters. The ISAKMP profile applies parameters specific to each profile, such as trust points, peer identities, and XAUTH authentication, authorization, and accounting (AAA) list, and so forth.
ISAKMP Profile Considerations
The following considerations are listed on when to use the ISAKMP profile:
•Any router with two or more IPSec connections that requires different phase 1 parameters for different sites (for example, configuring site-to-site and remote access on the same router).
•Custom Internet Key Exchange (IKE) Phase 1 policies might be needed for different peers. For example, whether XAUTH is applied to a specific peer, rather than being applied on every connection.
•IPSec configuration using VRF-aware IPSec, which allows the use of single IP address to connect to different peers with different IKE Phase 1 parameters.
Mask Preshared Keys
A mask preshared key lets a group of remote users with the same level of authentication share an IKE preshared key. The preshared key of the remote peer must match the preshared key of the local peer for IKE authentication to occur.
A mask preshared key is usually distributed through a secure out-of-band channel. In a remote peer-to-local peer scenario, any remote peer with the IKE preshared key configured can establish IKE SAs with the local peer.
If you specify a subnet-address value with the crypto keyring command, it is up to you to use a subnet address, which allows more peers to share the same key. That is, the preshared key is no longer restricted to use between two users.
Note We do not recommend using 0.0.0.0 as a subnet address, because it encourages group preshared keys, which allow all peers to have the same group key, thereby reducing the security of your user authentication.
Mask preshared keys have the following restrictions:
•The SA cannot be established between the IPSec peers until all IPSec peers are configured for the same preshared key.
•The mask preshared key must be distinctly different for remote users requiring varying levels of authorization. You must configure a new preshared key for each level of trust and assign the correct keys to the correct parties. Otherwise, an untrusted party may obtain access to protected data.
Preshared Keys Using a AAA Server
Preshared keys do not scale well when you are trying to deploy a large scale Virtual Private Network (VPN) without using a CA. When dynamic IP addressing such as DHCP or PPP dialups is used, the changing IP address can make key lookup difficult or impossible unless a mask preshared key is used. However, mask preshared keys are not very secure because a large number of users are given the same secret, thus reducing the security of the secret.
Configuring preshared keys using an authentication, authorization, and accounting (AAA) server allows each user to have his or her own key, which is stored on an external AAA server. This allows for central management of the user database, linking it to an existing AAA database, in addition to allowing every user to have a unique, more secure preshared key.
To configure this feature, you must perform the following tasks at each peer:
•Configure AAA.
•Configure a dynamic crypto ISAKMP profile.
•Configure extended authentication (optional)
•Configure ISAKMP policy.
For information on configuring crypto ISAKMP profiles, including enabling an IPSec peer for preshared keys using a AAA server, see both "Configuring Crypto Keyrings" section and "Configuring the ISAKMP Profile for Locally Sourced and Destined Traffic" section. Preshared keys using an AAA server have the following restrictions:
•The shared secret can be accessed only in aggressive mode. The ID of the IKE exchange is used as the username to query AAA if no local key can be found on the Cisco IOS XR router to which the user is trying to connect. Aggressive mode provides the ID in the first part of the IKE exchange; main mode does not provide the ID until the latter part of the IKE exchange, which is too late for key lookup.
•Only the following ID types can be used:
–IPv4 address (can be different from the one assigned by the Internet service provider [ISP])
–FQDN (fully qualified domain name)
–E-mail address
Internet Key Exchange Mode Configuration
IKE mode configuration, as defined by the Internet Engineering Task Force (IETF), allows a gateway to download an IP address (and other network level configuration) to the client as part of an IKE negotiation. Using this exchange, the gateway gives IP addresses to the IKE client to be used as an "inner" IP address encapsulated under IPSec. This method provides a known IP address for the client that can be matched against IPSec policy.
To implement the Cisco IPSec VPN SPAs between remote access clients that have dynamic IP addresses and a corporate gateway, you have to dynamically administer scalable IPSec policy on the gateway once each client is authenticated. With IKE mode configuration, the gateway can set up scalable policy for a very large set of clients irrespective of the IP addresses of those clients.
The client initiation type of IKE mode configuration is supported. The client initiates the configuration mode with the gateway. The gateway responds with an IP address that it has allocated for the client.
Mode configuration must be applied to a crypto ISAKMP profile to be enforced.
For instructions on how to apply mode configuration to a crypto ISAKMP profile, see the "Defining Group Policy Information for Mode Configuration" section.
Interfaces with crypto ISAKMP profiles, which are configured for IKE mode configuration, may experience a slightly longer connection setup time. This longer setup time is true even for IKE peers that refuse to be configured or do not respond to the configuration mode request. In both cases, the gateway initiates the configuration of the client.
Internet Key Exchange Extended Authentication
IKE extended authentication (Xauth) is a draft RFC based on the IKE protocol. Xauth allows all Cisco IOS XR software AAA authentication methods to perform user authentication in a separate phase after the IKE authentication phase 1 exchange. The AAA configuration list name must match the Xauth configuration list name for user authentication to occur.
Xauth does not replace IKE. IKE allows for device authentication and Xauth allows for user authentication, which occurs after IKE device authentication. Xauth occurs after IKE authentication phase 1 but before IKE IPSec SA negotiation phase 2.
To configure Xauth, perform the following tasks:
•Configure AAA (you must set up an authentication list).
•Configure a static crypto ISAKMP profile.
•Configure ISAKMP policy.
•Configure a dynamic crypto ISAKMP profile (optional).
For information on configuring crypto ISAKMP profiles, see the "Configuring the ISAKMP Profile for Locally Sourced and Destined Traffic" section.
Call Admission Control
The Call Admission Control (CAC) for Internet Key Exchange (IKE) feature describes the application of CAC to the IKE protocol in Cisco IOS XR software. CAC limits the number of simultaneous IKE security associations (SAs) (that is, calls to CAC) that a router can establish. In addition, there is an option to limit the maximum number of active IKE SAs allowed in the system and the CPU usage that is consumed by the IKE process or global CPU. The main function of CAC is to protect the router from severe resource depletion and to prevent crashes.
IKE Session
You can configure the absolute IKE SA limit by using the crypto isakmp call admission limit command. The router drops new IKE SA requests when the value has been reached.
Security Association Limit
An SA is a description of how two or more entities use security services to communicate securely on behalf of a particular data flow. IKE requires and uses SAs to identify the parameters of its connections. IKE can negotiate and establish its own SA. An IKE SA is used by IKE only, and it is bidirectional. An IKE SA cannot limit IPsec.
IKE drops SA requests based on a user-configured SA limit. To configure an IKE SA limit, use the crypto isakmp call admission limit command. When there is a new SA request from a peer router, IKE determines if the number of active IKE SAs plus the number of SAs being negotiated meets or exceeds the configured SA limit. If the number is greater than or equal to the limit, the new SA request is rejected and a system log is generated. This log contains the source destination IP address of the SA request.
Information About IKE for the Cisco IPSec VPN SPA on Cisco IOS XR Software
To implement IKE for the Cisco IPSec VPN SPAs, you should understand the following concept:
•IPSec Dead Peer Detection Periodic Message Option
IPSec Dead Peer Detection Periodic Message Option
The IPSec Dead Peer Detection (DPD) Periodic Message Option feature allows you to configure your router to query the liveliness of its Internet Key Exchange (IKE) peer at regular intervals. The benefit of this approach over the default approach (on-demand dead peer detection) is earlier detection of dead peers.
DPD, which is defined in RFC 3706, is a mechanism used to detect dead IPSec peers. IPSec is a peer-to-peer technology. IP connectivity can be lost between the peers due to routing problems, peer reloading, or some other situation that can result in black holes in which traffic is lost. DPD, based on a traffic-detection method, is one possible mechanism to remedy this situation.
How to Implement IKE Security Protocol Configurations for IPSec Networks
To configure the IKE security protocol for IPSec networks, perform the tasks described in the following sections. The tasks in the first two sections are required; the remaining may be optional, depending on which parameters are configured.
•Enabling or Disabling IKE (required)
•Configuring IKE Policies (required)
•Defining Group Policy Information for Mode Configuration (optional)
•Manually Configuring RSA Keys (optional, depending on IKE parameters)
•Configuring ISAKMP Preshared Keys in ISAKMP Keyrings (optional, depending on IKE parameters)
•Configuring Call Admission Control
•Configuring Crypto Keyrings
Enabling or Disabling IKE
This task enables or disables the Internet Key Exchange protocol.
IKE is disabled by default. IKE need not be enabled for individual interfaces, but it is enabled globally for all interfaces at the router.
SUMMARY STEPS
1. configure
2. crypto isakmp
3. no crypto isakmp
4. end
or
commit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto isakmp
Example:
RP/0/RP0/CPU0:router(config)# crypto isakmp
|
Globally enables IKE at the peer router.
|
Step 3
|
no crypto isakmp
Example:
RP/0/RP0/CPU0:router(config)# no crypto isakmp
|
(Optional) Disables IKE at the peer router.
|
Step 4
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Configuring IKE Policies
This task configures IKE policies.
SUMMARY STEPS
1. configure
2. crypto isakmp policy priority
3. encryption {des | 3des | aes | aes 192 | aes 256}
4. hash {sha | md5}
5. authentication {pre-share | rsa-sig | rsa-encr}
6. group {1 | 2 | 5}
7. lifetime seconds
8. end
or
commit
9. show crypto isakmp policy
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto isakmp policy priority
Example:
RP/0/RP0/CPU0:router(config)# crypto isakmp
policy 5
|
Identifies the policy to create.
•Each policy is uniquely identified by the priority number you assign.
•This command places the router in ISAKMP policy configuration mode.
|
Step 3
|
encryption {des | 3des | aes | aes 192 | aes
256}
Example:
RP/0/RP0/CPU0:router(config-isakmp)# encryption
aes
|
Specifies the encryption algorithm.
|
Step 4
|
hash {sha | md5}
Example:
RP/0/RP0/CPU0:router(config-isakmp)# hash md5
|
Specifies the hash algorithm.
|
Step 5
|
authentication {pre-share | rsa-sig | rsa-encr}
Example:
RP/0/RP0/CPU0:router(config-isakmp)#
authentication rsa-sig
|
Specifies the authentication method.
|
Step 6
|
group {1 | 2 | 5}
Example:
RP/0/RP0/CPU0:router(config-isakmp)# group 5
|
Specifies the Diffie-Hellman group identifier.
|
Step 7
|
lifetime seconds
Example:
RP/0/RP0/CPU0:router(config-isakmp)# lifetime
50000
|
Specifies the lifetime of the security association. The range, in seconds, is from 60 to 86400.
|
Step 8
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config-isakmp)# end
or
RP/0/RP0/CPU0:router(config-isakmp)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 9
|
show crypto isakmp policy
Example:
RP/0/RP0/CPU0:router# show crypto isakmp policy
|
(Optional) Displays all existing IKE policies.
|
Defining Group Policy Information for Mode Configuration
Although users can belong to only one group for each connection, they may belong to specific groups with different policy requirements. Thus, users may decide to connect to the client using a different group ID by changing their client profile on the VPN device.
This task defines the group policy attributes that are pushed to the client through mode configuration.
SUMMARY STEPS
1. configure
2. crypto isakmp client configuration group group-name
3. key preshared-key
4. acl acl-name
5. backup-server {ip-address | hostname}
6. dns primary-server [secondary-server]
7. domain name
8. firewall are-u-there
9. group-lock
10. include-local-lan
11. max-logins number-of-logins
12. max-users number-of-users
13. netmask mask
14. pfs
15. pool name
16. save-password
17. split-dns domain-name
18. wins primary-server [secondary-server]
19. end
or
commit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto isakmp client configuration group
group-name
Example:
RP/0/RP0/CPU0:router(config)# crypto isakmp
client configuration group cisco
|
Specifies which group's policy profile is defined and enters ISAKMP group configuration mode.
•If no specific group matches and a default group is defined, users are automatically given the default group's policy.
|
Step 3
|
key preshared-key
Example:
RP/0/RP0/CPU0:router(config-group)# key
samplekey
|
Specifies the IKE preshared key for group policy attribute definition.
Note This command must be enabled if the client identifies itself with a preshared key.
|
Step 4
|
acl acl-name
Example:
RP/0/RP0/CPU0:router(config-group)# acl group1
|
(Optional) Configures split tunneling.
•Use the acl-name argument to specify a group of ACL rules that represent protected subnets for split tunneling purposes.
|
Step 5
|
backup-server {ip-address | hostname}
Example:
RP/0/RP0/CPU0:router(config-group)#
backup-server 10.1.1.1
|
Specifies the backup server.
•Use the ip-address argument to specify the IP address of the server.
•Use the hostname argument to specify the hostname of the server.
|
Step 6
|
dns primary-server [secondary-server]
Example:
RP/0/RP0/CPU0:router(config-group)# dns 2.2.2.2
2.3.2.3
|
Specifies the primary and secondary Domain Name Service (DNS) addresses.
•Use the primary-server argument to specify the IP address of the primary DNS.
•(Optional) Use the secondary-server argument to specify the IP address of the secondary DNS.
|
Step 7
|
domain name
Example:
RP/0/RP0/CPU0:router(config-group)# domain
cisco.com
|
Specifies the DNS domain to which a group belongs.
•Use the name argument to specify the default name of the DNS domain.
|
Step 8
|
firewall are-u-there
Example:
RP/0/RP0/CPU0:router(config-group)# firewall
are-u-there
|
Adds the Firewall-Are-U-There attribute to the server group if your PC is running the Black Ice or Zone Alarm personal firewalls.
|
Step 9
|
group-lock
Example:
RP/0/RP0/CPU0:router(config-group)# group-lock
|
Allows you to enter your extended authentication (Xauth) username, including the group name, when preshared key authentication is used with IKE.
|
Step 10
|
include-local-lan
Example:
RP/0/RP0/CPU0:router(config-group)#
include-local-lan
|
Configures the Include-Local-LAN attribute to allow a nonsplit-tunneling connection to access the local subnetwork at the same time as the client.
|
Step 11
|
max-logins number-of-logins
Example:
RP/0/RP0/CPU0:router(config-group)# max-logins
8
|
Specifies the maximum number of concurrent logins that are allowed for a certain user.
•Use the number-of-logins argument to specify the number of logins. The value ranges from 0 to 16 and 384.
|
Step 12
|
max-users number-of-users
Example:
RP/0/RP0/CPU0:router(config-group)# max-users
1200
|
Limits the number of connections to a specific server group.
•Use the number-of-users argument to specify the number of connected users. The value ranges from 0 to 16 and 384.
|
Step 13
|
netmask mask
Example:
RP/0/RP0/CPU0:router(config-group)# netmask
255.255.255.0
|
Sets the IP network mask.
•Use the mask argument to specify the IP network mask.
|
Step 14
|
pfs
Example:
RP/0/RP0/CPU0:router(config-group)# pfs
|
Configures a server to notify the client of the central-site policy regarding whether PFS is required for any IP Security (IPSec) Security Association (SA).
|
Step 15
|
pool name
Example:
RP/0/RP0/CPU0:router(config-group)# pool dog
|
Defines the name of an address-pool in which an address is allocated if required.
•Use the name argument to specify the name of the local pool address.
|
Step 16
|
save-password
Example:
RP/0/RP0/CPU0:router(config-group)#
save-password
|
Saves your extended authentication (Xauth) password locally on your PC or Easy VPN client.
|
Step 17
|
split-dns domain-name
Example:
RP/0/RP0/CPU0:router(config-group)# split-dns
green.com
RP/0/RP0/CPU0:router(config-group)# split-dns
acme.org
|
Specifies a domain name that must be tunneled or resolved to the private network.
•Use the domain-name argument to specify the name of the DNS domain that must be tunneled or resolved to the private network.
Note If you have to configure more than one domain name, you have to add a split-dns command line for each.
|
Step 18
|
wins primary-server [secondary-server]
Example:
RP/0/RP0/CPU0:router(config-group)# wins
10.1.1.2 10.1.1.3
|
Specifies the primary and secondary Windows Internet Naming Service (WINS) servers.
•Use the primary-server argument to specify the name of the primary WINS server.
•(Optional) Use the secondary-server argument to specify the name of the secondary WINS server.
|
Step 19
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config-group)# end
or
RP/0/RP0/CPU0:router(config-group)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Manually Configuring RSA Keys
Manually configure RSA keys when you specify RSA encrypted nonces as the authentication method in an IKE policy and you are not using a CA.
To manually configure RSA keys, perform these tasks at each IPSec peer that uses RSA encrypted nonces in an IKE policy:
•RSA Keys Generation
•Configuring ISAKMP Identity
•Configuring RSA Public Keys of All the Other Peers
RSA Keys Generation
For instructions on how to generate RSA keys, see the "Generating an RSA Key Pair" section in the Implementing Certification Authority Interoperability on Cisco IOS XR Software module.
Configuring ISAKMP Identity
This task configures the ISAKMP identity of a peer.
Remember to repeat these tasks at each peer that uses preshared keys in an IKE policy.
SUMMARY STEPS
1. configure
2. crypto isakmp identity {address | hostname}
3. host hostname address1 [address2...address8]
4. end
or
commit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto isakmp identity {address | hostname}
Example:
RP/0/RP0/CPU0:router(config)# crypto isakmp
identity address
|
(At the local peer) Specifies the peer's ISAKMP identity by IP address or by hostname. See the crypto isakmp identity command description for guidelines for when to use the IP address and when to use the hostname.
|
Step 3
|
host hostname address1 [address2...address8]
Example:
RP/0/RP0/CPU0:router(config)# host host1
10.0.0.5
|
(At all remote peers) Maps the peer's hostname to its IP addresses at all the remote peers.
•This command is used if the local peer's ISAKMP identity was specified using a hostname.
•This step might be unnecessary if the hostname or address is already mapped in a DNS server.
|
Step 4
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Configuring RSA Public Keys of All the Other Peers
This task configures the RSA public keys of all the other peers.
Remember to repeat these tasks at each peer that uses RSA encrypted nonces in an IKE policy.
SUMMARY STEPS
1. configure
2. crypto keyring keyring-name [vrf fvrf-name]
3. rsa-pubkey {address address | name fqdn} [encryption | signature]
4. address ip-address
5. key-string key-string
6. quit
7. end
or
commit
8. show crypto key pubkey-chain rsa [name key-name | address key-address]
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto keyring keyring-name [vrf fvrf-name]
Example:
RP/0/RP0/CPU0:router(config)# crypto keyring
vpnkeyring
RP/0/RP0/CPU0:router(config-keyring)#
|
Defines a crypto keyring during IKE authentication
•Enters keyring configuration mode.
•Use the keyring-name argument to specify the name of the crypto keyring.
•(Optional) Use the vrf keyword to specify that the front door virtual routing and forwarding (FVRF) name is the keyring that is referenced.
|
Step 3
|
rsa-pubkey {address address | name fqdn}
[encryption | signature]
Example:
RP/0/RP0/CPU0:router(config-keyring)#
rsa-pubkey name host.vpn.com
RP/0/RP0/CPU0:router(config-pubkey)
|
Defines the Rivest, Shamir, and Adelman (RSA) manual key to be used for encryption or signature during Internet Key Exchange (IKE) authentication.
•Use the address keyword to specify the IP address of the RSA public key of the remote peer. The address argument is the IP address of the remote RSA public key of the remote peer that you manually configure.
•Use the name keyword to specify the fully qualified domain name (FQDN) of the peer.
•Use the encryption keyword to specify that the key is used for encryption.
•Use the signature keyword to specify that the key is used for a signature. The signature keyword is the default
|
Step 4
|
address ip-address
Example:
RP/0/RP0/CPU0:router(config-pubkey)# address
10.5.5.1
|
Specifies the remote peer's IP address.
•You can use this command if you used a fully qualified domain name to name the remote peer.
|
Step 5
|
key-string key-string
Example:
RP/0/RP0/CPU0:router(config-pubkey)# key-string
005C300D 06092A86 4886F70D 01010105 ...
|
Specifies the remote peer's RSA public key.
•This is the key previously displayed by the remote peer's administrator when the remote router's RSA keys were generated.
•To avoid mistakes, you should cut and paste the key data (instead of attempting to enter in the data).
•Enter a key on each line. You must enter the key-string command before the key.
•When you have finished specifying the remote peer's RSA key, return to global configuration mode by entering quit at the public key configuration prompt.
|
Step 6
|
quit
Example:
RP/0/RP0/CPU0:router(config-pubkey)# quit
|
Returns to global configuration mode.
|
Step 7
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 8
|
show crypto pubkey-chain rsa [name key-name |
address key-address]
Example:
RP/0/RP0/CPU0:router# show crypto pubkey-chain
rsa
|
(Optional) Displays a list of all the RSA public keys stored on your router.
•Use the optional name or address keyword to display details about a particular RSA public key stored on your router.
|
Configuring ISAKMP Preshared Keys in ISAKMP Keyrings
This task configures ISAKMP preshared keys in ISAKMP keyrings.
Prerequisites
To configure ISAKMP preshared keys in ISAKMP keyrings, perform these tasks at each peer that uses preshared keys in an IKE policy:
•Set the ISAKMP identity of each peer. Each peer's identity should be set either to its hostname or by its IP address. By default, a peer's identity is set to its IP address. Setting ISAKMP identities is described in the "Configuring ISAKMP Identity" section.
•Specify the shared keys at each peer. Note that a given preshared key is shared between two peers. At a given peer you could specify the same key to share with multiple remote peers; however, a more secure approach is to specify different keys to share between different pairs of peers.
You must specify the support for masked preshared keys.
Remember to repeat these tasks at each peer that uses preshared keys in an IKE policy.
SUMMARY STEPS
1. configure
2. crypto keyring keyring-name [vrf fvrf-name]
3. pre-shared-key {address address [mask] | hostname hostname} key key
4. end
or
commit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto keyring keyring-name [vrf fvrf-name]
Example:
RP/0/RP0/CPU0:router(config)# crypto keyring
vpnkeyring
RP/0/RP0/CPU0:router(config-keyring)#
|
Defines a crypto keyring during IKE authentication.
•Use the keyring-name argument to specify the name of the crypto keyring.
•(Optional) Use the vrf keyword to specify that the front door virtual routing and forwarding (FVRF) name is the keyring that is referenced.
|
Step 3
|
pre-shared-key {address address [mask] |
hostname hostname} key key
Example:
RP/0/RP0/CPU0:router(config-keyring)#
pre-shared-key address 10.72.23.11 key vpnkey
RP/0/RP0/CPU0:router(config-keyring)#
pre-shared-key hostname mycisco.com key vpnkey
|
Defines a preshared key for IKE authentication.
•Use the address keyword to specify the IP address of the remote peer or a subnet and mask.
•(Optional) Use the mask argument to match the range of the address.
•Use the hostname keyword to specify the fully qualified domain name (FQDN) of the peer.
•(Optional) Use the key keyword to specify the key.
|
Step 4
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config-keyring)# end
or
RP/0/RP0/CPU0:router(config-keyring)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Configuring Call Admission Control
These tasks are used to configure Call Admission Control (CAC):
•Configuring the IKE Security Association Limit
•Configuring the System Resource Limit
Configuring the IKE Security Association Limit
This task configures the IKE security admission limit.
SUMMARY STEPS
1. configure
2. crypto isakmp call admission limit {in-negotiation-sa number | sa number}
3. end
or
commit
4. show cyrpto isakmp call admission statistics
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto isakmp call admission limit
{in-negotiation-sa number | sa number}
Example:
RP/0/RP0/CPU0:router(config)# crypto isakmp call
admission limit sa 25
|
Specifies the maximum number of IKE SAs that the router can establish before IKE begins rejecting new SA requests.
•Use the in-negotiation-sa keyword to specify the maximum number of in-negotiation (embryonic) IKE security associations (SAs) that the router can establish before IKE begins rejecting new SA requests. The range for the number argument is from 1 to 100000.
•Use the sa keyword to specify the maximum number of active IKE SAs that the router can establish. The range for the number argument is from 1 to 100000.
|
Step 3
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 4
|
show cyrpto isakmp call admission statistics
Example:
RP/0/RP0/CPU0:router# show cyrpto isakmp call
admission statistics
|
Monitors crypto CAC statistics.
|
Configuring the System Resource Limit
This task configures the system resource limit.
SUMMARY STEPS
1. configure
2. crypto isakmp call admission limit {cpu {total percent | ike percent} }
3. end
or
commit
4. show cyrpto isakmp call admission statistics
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto isakmp call admission limit {cpu {total
percent | ike percent} }
Example:
RP/0/RP0/CPU0:router(config)# crypto isakmp call
admission limit cpu total 90
|
Specifies the maximum number of IKE SAs that the router can establish before IKE begins rejecting new SA requests.
•Use the cpu keyword to specify the total resource limit for the CPU usage.
•Use the total keyword to specify the maximum total CPU usage to accept new calls. The range for the percent argument is from 1 to 100.
•Use the ike keyword to specify the maximum IKE CPU usage to accept new calls. The range for the percent argument is from 1 to 100.
|
Step 3
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 4
|
show cyrpto isakmp call admission statistics
Example:
RP/0/RP0/CPU0:router# show cyrpto isakmp call
admission statistics
|
Monitors crypto CAC statistics.
|
Configuring Crypto Keyrings
A crypto keyring is a repository of preshared and Rivest, Shamir, and Adelman (RSA) public keys. The router can have zero or more keyrings. Each keyring optionally allows the specification of a VRF in which the keys defined in the keyring belong.
This task configures crypto keyrings.
Crypto Keyrings Configuration Guidelines and Restrictions
Follow these guidelines and restrictions when configuring crypto keyrings:
•The VRF associated with a crypto keyring cannot be changed. A different keyring must be configured with the new VRF value.
•Address overlapping in a keyring is not allowed and must be enforced during configuration.
•A crypto keyring is attached to one or more ISAKMP profiles and cannot be deleted while in use.
SUMMARY STEPS
1. configure
2. crypto keyring keyring-name [vrf fvrf-name]
3. description string
4. local-address ip-address
5. pre-shared-key {address address [mask] | hostname hostname} key key
6. rsa-pubkey {address address | name fqdn} [encryption | signature]
7. key-string key-string
8. quit
9. end
or
commit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto keyring keyring-name [vrf fvrf-name]
Example:
RP/0/RP0/CPU0:router(config)# crypto keyring vpnkey
|
Defines a crypto keyring to be used during IKE authentication.
•Use the keyring-name argument as the name of the crypto keyring.
•Use the vrf keyword to specify that the front door virtual routing and forwarding (FVRF) name is the keyring that is referenced. The fvrf-name argument must match the FVRF name that was defined during a (VRF) configuration.
|
Step 3
|
description string
Example:
RP/0/RP0/CPU0:router(config-keyring# description
this is a sample keyring
|
Creates a one-line description for a keyring.
•Use the string argument to specify the character string that describes the keyring.
|
Step 4
|
local-address ip-address
Example:
RP/0/RP0/CPU0:router(config-keyring)# local-address
130.40.1.1
|
Limits the scope of an ISAKMP keyring configuration to a local termination address or interface.
•Use the ip-address argument to specify the IP address to which to bind.
|
Step 5
|
pre-shared-key {address address [mask] | hostname
hostname} key key
Example:
RP/0/RP0/CPU0:router(config-keyring)# pre-shared-key
address 10.72.23.11 key vpnkey
|
Defines a preshared key to be used for IKE authentication.
•Use the address keyword to specify the IP address of the remote peer or a subnet and mask. The mask argument is optional.
•Use the hostname keyword to specify the fully qualified domain name (FQDN) of the peer.
•Use the key keyword to specify the secret.
|
Step 6
|
rsa-pubkey {address address | name fqdn} [encryption
| signature]
Example:
RP/0/RP0/CPU0:router(config-keyring)# rsa-pubkey
name host.vpn.com
RP/0/RP0/CPU0:router(config-keyring)# rsa-pubkey
name host.vpn.com
|
Defines a Rivest, Shamir, and Adelman (RSA) public key by address or hostname.
•Use the address keyword to specify the IP address of the RSA public key of the remote peer. The address argument is the IP address of the remote RSA public key of the remote peer that you manually configure.
•Use the name keyword to specify the FQDN of the peer.
•(Optional) Use the encryption keyword to specify that the key is used for encryption.
•(Optional) Use the signature keyword to specify that the key is used for a signature. The signature keyword is the default.
|
Step 7
|
key-string key-string
Example:
RP/0/RP0/CPU0:router(config-pubkey)# key-string
005C300D 06092A86 4886F70D 01010105
|
Manually specifies the RSA public key of a remote peer.
|
Step 8
|
quit
Example:
RP/0/RP0/CPU0:router(config-pubkey)# quit
|
Returns to global configuration mode.
|
Step 9
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
How to Implement IKE for Locally Sourced and Destined Traffic
This section contains the following procedure:
•Configuring the ISAKMP Profile for Locally Sourced and Destined Traffic
Configuring the ISAKMP Profile for Locally Sourced and Destined Traffic
An ISAKMP profile is a repository of commands for a set of peers.
This task configures the ISAKMP profile for locally sourced and destined traffic.
SUMMARY STEPS
1. configure
2. crypto isakmp profile [local] profile-name
3. description string
4. keepalive disable
5. self-identity {address | fqdn | user-fqdn user-fqdn}
6. keyring keyring-name
7. match identity {group group-name | address address [mask] vrf [fvrf] | host hostname | host domain domain-name | user username | user domain domain-name}
8. set interface tunnel-ipsec intf-index
9. set ipsec-profile profile-name
10. end
or
commit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto isakmp profile [local] profile-name
Example:
RP/0/RP0/CPU0:router(config)# crypto isakmp profile
local vpnprofile
RP/0/RP0/CPU0:router(config-isa-prof)#
|
Defines an ISAKMP profile and audits IPSec user sessions.
•(Optional) Use the local keyword to specify that the profile is used for locally sourced or terminated traffic.
Note The local keyword is specific only to the Cisco IPSec VPN SPA.
•Use the profile-name argument to specify the name of the user profile.
|
Step 3
|
description string
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# description
this is a sample profile
|
Creates a description for a keyring.
•Use the string argument to specify the character string that describes the keyring.
|
Step 4
|
keepalive disable
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# keepalive
disable
|
Lets the gateway send DPD messages to the Cisco IOS XR peer.
•Use the disable keyword to disable the keepalive global declarations.
|
Step 5
|
self-identity {address | fqdn | user-fqdn user-fqdn}
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# self-identity
user-fqdn user@vpn.com
|
Defines the identity that the local IKE uses to identify itself to the remote peer.
•Use the address keyword to specify the IP address of the local endpoint.
•Use the fqdn keyword to specify the fully qualified domain name (FQDN) of the host.
•Use the user-fqdn keyword to specify that the user FQDN was sent to the remote endpoint.
|
Step 6
|
keyring keyring-name
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# keyring
vpnkeyring
|
Configures a keyring with an ISAKMP profile.
•Use the keyring-name argument to specify the keyring name, which must match the keyring name that was defined in the global configuration.
|
Step 7
|
match identity {group group-name | address address
[mask] vrf [fvrf] | host hostname | host domain
domain-name | user username | user domain
domain-name}
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# match
identity group vpngroup
RP/0/RP0/CPU0:router(config-isa-prof-match)#
|
Matches the identity from a peer in an ISAKMP profile.
•Use the group keyword to specify a Unity group that matches identification (ID) type ID_KEY_ID. If RSA signatures are used, the group-name argument matches the organizational unit (OU) field of the distinguished name (DN).
•Use the address keyword to match the address argument with the ID type ID_IPV4_ADDR.
•Use the mask argument to specify a range of addresses.
•Use the vrf keyword to specify the front door virtual router forwarding (VRF) of the peer.
•Use the fvrf argument to match the address in the front door virtual router forwarding (FVRF) Virtual Private Network (VPN) space.
•Use the host keyword to specify an identity that matches the type ID_FQDN, whose fully qualified domain name (FQDN) ends with the domain name.
•Use the host domain keyword to specify an identity that matches type ID_FQDN. The domain name is the same as the domain-name argument.
•Use the user keyword to specify an identity that matches the FQDN.
•Use the user domain keyword to specify an identity that matches the type ID_USER_FQDN. When the user domain keyword is present, all users having identities of the type ID_USER_FQDN and ending with domain-name are matched.
|
Step 8
|
set interface tunnel-ipsec intf-index
Example:
RP/0/RP0/CPU0:router(config-isa-prof-match)# set
interface tunnel-ipsec 50
|
Predefines the interface instance when IKE negotiates for IPSec service associations (SAs) for the traffic that is locally sourced or terminated and the local endpoint is the IKE responder.
•Use the intf-index argument to set the range from 0 to 4294967295.
|
Step 9
|
set ipsec-profile profile-name
Example:
RP/0/RP0/CPU0:router(config-isa-prof-match)# set
ipsec-profile myprofile
|
Predefines the IPSec profile instance when IKE negotiates for IPSec service associations (SAs) for the traffic that is locally sourced or terminated and the local endpoint is the IKE responder.
•Use the profile-name argument to set the name of the IPSec profile.
|
Step 10
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config-isa-prof-match)# end
or
RP/0/RP0/CPU0:router(config-isa-prof-match)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
How to Implement IKE for Cisco IPSec VPN SPAs on Cisco IOS XR Software
This section contains the following procedures:
•Configuring a Periodic Dead Peer Detection Message
•Configuring the ISAKMP Profile for Service Interfaces
Configuring a Periodic Dead Peer Detection Message
This task configures a periodic dead peer detection (DPD) message.
SUMMARY STEPS
1. configure
2. crypto isakmp keepalive seconds retry-seconds [periodic | on-demand]
3. end
or
commit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto isakmp keepalive seconds retry-seconds
[periodic | on-demand]
Example:
RP/0/RP0/CPU0:router(config)# crypto isakmp
keepalive 20 20 on-demand
|
Uses the IKE security association (SA) feature to provide a mechanism to detect loss of connectivity between two IP Security (IPSec) peers.
•Use the seconds argument to specify the number of seconds between keepalive messages. The range is from 10 to 3600.
•Use the retry-seconds argument to specify the number of seconds between retries if keepalive fails. The range is from 2 to 60.
•(Optional) Use the periodic keyword to specify the keepalive messages that are sent at regular intervals for DPD messages.
•(Optional) Use the on-demand keyword to specify the DPD retries that are sent on demand.
|
Step 3
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Configuring the ISAKMP Profile for Service Interfaces
This task configures the ISAKMP profile for service interfaces.
SUMMARY STEPS
1. configure
2. crypto isakmp profile [local] profile-name
3. description string
4. keepalive disable
5. self-identity {address | fqdn | user-fqdn user-fqdn}
6. keyring keyring-name
7. match identity {group group-name | address address [mask] vrf [fvrf] | host hostname | host domain domain-name | user username | user domain domain-name}
8. set interface {service-ipsec | service-gre} intf-index
9. end
or
commit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
crypto isakmp profile [local] profile-name
Example:
RP/0/RP0/CPU0:router(config)# crypto isakmp profile
vpnprofile
RP/0/RP0/CPU0:router(config-isa-prof)#
|
Defines an ISAKMP profile and audits IPSec user sessions.
•(Optional) Use the local keyword to specify that the profile is used for locally sourced or terminated traffic.
Note The local keyword is specific only to the Cisco IPSec VPN SPA.
•Use the profile-name argument to specify the name of the user profile.
|
Step 3
|
description string
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# description
this is a sample profile
|
Creates a description for a keyring.
•Use the string argument to specify the character string that describes the keyring.
|
Step 4
|
keepalive disable
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# keepalive
disable
|
Lets the gateway send DPD messages to the Cisco IOS XR peer.
•Use the disable keyword to disable the keepalive global declarations.
|
Step 5
|
self-identity {address | fqdn | user-fqdn user-fqdn}
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# self-identity
user-fqdn user@vpn.com
|
Defines the identity that the local IKE uses to identify itself to the remote peer.
•Use the address keyword to specify the IP address of the local endpoint.
•Use the fqdn keyword to specify the fully qualified domain name (FQDN) of the host.
•Use the user-fqdn keyword to specify that the user FQDN was sent to the remote endpoint.
|
Step 6
|
keyring keyring-name
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# keyring
vpnkeyring
|
Configures a keyring with an ISAKMP profile.
•Use the keyring-name argument to specify the keyring name, which must match the keyring name that was defined in the global configuration.
|
Step 7
|
match identity {group group-name | address address
[mask] vrf [fvrf] | host hostname | host domain
domain-name | user username | user domain
domain-name}
Example:
RP/0/RP0/CPU0:router(config-isa-prof)# match
identity group vpngroup
RP/0/RP0/CPU0:router(config-isa-prof-match)#
|
Matches the identity from a peer in an ISAKMP profile.
•Use the group keyword to specify a Unity group that matches identification (ID) type ID_KEY_ID. If RSA signatures are used, the group-name argument matches the organizational unit (OU) field of the distinguished name (DN).
•Use the address keyword to match the address argument with the ID type ID_IPV4_ADDR.
•Use the mask argument to specify a range of addresses.
•Use the vrf keyword to specify the front door virtual router forwarding (VRF) of the peer.
•Use the fvrf argument to match the address in the front door virtual router forwarding (FVRF) Virtual Private Network (VPN) space.
•Use the host keyword to specify an identity that matches the type ID_FQDN, whose fully qualified domain name (FQDN) ends with the domain name.
•Use the host domain keyword to specify an identity that matches type ID_FQDN. The domain name is the same as the domain-name argument.
•Use the user keyword to specify an identity that matches the FQDN.
•Use the user domain keyword to specify an identity that matches the type ID_USER_FQDN. When the user domain keyword is present, all users having identities of the type ID_USER_FQDN and ending with domain-name are matched.
|
Step 8
|
set interface {service-ipsec | service-gre}
intf-index
Example:
RP/0/RP0/CPU0:router(config-isa-prof-match)# set
interface service-ipsec 50
or
RP/0/RP0/CPU0:router(config-isa-prof-match)# set
interface service-gre 1000
|
Predefines the virtual interface when IKE negotiates for IPSec SAs and the local endpoint is the IKE responder.
•Use the service-ipsec keyword to specify the IPSec service interfaces.
•Use the service-gre keyword to specify the GRE service interfaces.
•Use the intf-index argument to set the range from 1 to 65535.
|
Step 9
|
end
or
commit
Example:
RP/0/RP0/CPU0:router(config-isa-prof-match)# end
or
RP/0/RP0/CPU0:router(config-isa-prof-match)# commit
|
Saves configuration changes.
•When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)?
[cancel]:
–Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
–Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
–Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
•Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Configuration Examples for Implementing IKE Security Protocol
This section provides the following configuration examples:
•Creating IKE Policies: Example
•Configuring a service-ipsec Interface with a Dynamic Profile: Example
•Configuring Easy VPN with a Local AAA: Example
•Configuring VRF-Aware: Example
Creating IKE Policies: Example
This example shows how to create two IKE policies with policy 15 as the highest priority, policy 20 as the next priority, and the existing default priority as the lowest priority.
In the example, the encryption des of policy 15 would not appear in the written configuration because this is the default value for the encryption algorithm parameter.
If the show crypto isakmp policy command is issued with this configuration, the output is as follows:
Protection suite priority 15
encryption algorithm: DES - Data Encryption Standard (56 bit keys)
hash algorithm: Message Digest 5
authentication method: Rivest-Shamir-Adelman Signature
Diffie-Hellman group: #2 (1024 bit)
lifetime: 5000 seconds, no volume limit
Protection suite priority 20
encryption algorithm: DES - Data Encryption Standard (56 bit keys)
hash algorithm: Secure Hash Standard
authentication method: preshared Key
Diffie-Hellman group: #1 (768 bit)
lifetime: 10000 seconds, no volume limit
encryption algorithm: DES - Data Encryption Standard (56 bit keys)
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adelman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
Note Although the output shows "no volume limit" for the lifetimes, you can configure only a time lifetime (such as 86,400 seconds); volume-limit lifetimes are not configurable.
Configuring a service-ipsec Interface with a Dynamic Profile: Example
The following shows how to configure a service-ipsec interface with a dynamic profile:
ipv4 address 44.44.44.44 255.255.255.0
service-location preferred-active 0/4/0
crypto keyring ring1 vrf default
pre-shared-key address 40.0.0.1 255.255.255.255 key key1
crypto isakmp profile ike-profile1
match identity address 40.0.0.0/16 vrf default
set interface service-ipsec1
crypto isakmp keepalive 60 5
crypto ipsec transform-set tsfm1 esp-3des esp-md5-hmac
crypto ipsec profile ipsec-profile1
match acl1 transform-set tsfm1
Configuring Easy VPN with a Local AAA: Example
The following example shows how to configure Easy VPN with a local AAA:
aaa authorization network author-net-local local
aaa authentication login authen-net-local local
aaa authentication login author-net-local local
ipv4 pool-1 20.20.20.4 20.20.20.255
ipv4 address 10.20.100.1 255.255.255.255
ipv4 address 2.1.0.5 255.255.255.255
ipv4 address 10.20.100.3 255.255.255.255
interface MgmtEth0/0/CPU0/0
ipv4 address 3.1.73.1 255.255.0.0
interface GigabitEthernet0/1/0/0.1
ipv4 address 10.0.83.2 255.255.255.0
interface GigabitEthernet0/1/0/0.2
ipv4 address 10.0.81.4 255.255.255.0
interface GigabitEthernet0/1/0/1
ipv4 address 2.0.0.1 255.0.0.0
ipv4 address 30.3.3.3 255.255.0.0
tunnel source 10.20.100.3
service-location preferred-active 0/2/0
crypto isakmp client configuration group group-a
crypto isakmp profile isakmp-prof3
client authentication list authen-net-local
match identity group group-a
set interface service-ipsec3
isakmp authorization list author-net-local
crypto ipsec transform-set tsfm3
transform esp-3des esp-sha-hmac
crypto ipsec profile ipsec-prof-ezvpn
match acl-3 transform-set tsfm3
Configuring VRF-Aware: Example
The following example shows how to configure VRF-aware:
ipv4 access-list acl-2_5-1
ipv4 access-list acl-2_5-4
10 permit ipv4 host 2.6.1.3 host 1.7.1.3
interface GigabitEthernet0/1/0/0.1
ipv4 address 10.0.83.2 255.255.255.0
interface GigabitEthernet0/1/0/1.1
ipv4 address 2.6.0.1 255.255.0.0
interface GigabitEthernet0/1/0/1.2
ipv4 address 2.6.1.1 255.255.0.0
interface GigabitEthernet0/1/0/1.3
ipv4 address 2.6.0.1 255.255.0.0
interface GigabitEthernet0/1/0/0.11
ipv4 address 10.0.91.1 255.255.255.0
interface GigabitEthernet0/1/0/0.12
ipv4 address 10.0.92.1 255.255.255.0
interface GigabitEthernet0/1/0/0.13
ipv4 address 10.0.93.1 255.255.255.0
interface service-ipsec15
ipv4 address 115.115.115.115 255.255.0.0
service-location preferred-active 0/2/0
profile ipsec-prof15 tunnel vrf FVRF
tunnel source 10.20.100.15
interface service-ipsec16
ipv4 address 116.116.116.116 255.255.0.0
service-location preferred-active 0/2/0
profile ipsec-prof16 tunnel vrf FVRF
tunnel source 10.20.100.16
tunnel destination 10.0.85.2
address-family ipv4 unicast
1.7.0.3/32 service-ipsec15
1.7.0.4/32 service-ipsec15 vrf FVRF
address-family ipv4 unicast
crypto keyring kr11 vrf FVRF
pre-shared-key address 10.0.91.2 255.255.255.255 key key-vrf
pre-shared-key address 10.0.92.2 255.255.255.255 key key-vrf
pre-shared-key address 10.0.93.2 255.255.255.255 key key-vrf
crypto keyring kr12 vrf FVRF
local-address 10.20.100.16
pre-shared-key address 0.0.0.0 0.0.0.0 key key16
crypto isakmp profile isakmp-prof6
match identity address 10.0.91.2/32 vrf FVRF
set interface service-ipsec15
match identity address 10.0.92.2/32 vrf FVRF
set interface service-ipsec15
match identity address 10.0.93.2/32 vrf FVRF
set interface service-ipsec15
crypto isakmp profile isakmp-prof7
match identity address 10.0.85.2/32 vrf FVRF
set interface service-ipsec16
crypto ipsec transform-set tsfm5
transform ah-sha-hmac esp-aes
crypto ipsec transform-set tsfm15
transform esp-3des esp-md5-hmac
crypto ipsec transform-set tsfm16
transform esp-aes esp-sha-hmac
crypto ipsec profile ipsec-prof15
match acl-2_5-1 transform-set tsfm15
crypto ipsec profile ipsec-prof16
match acl-2_5-4 transform-set tsfm16
Additional References
The following sections provide references related to implementing the IKE security protocol.
Related Documents
Related Topic
|
Document Title
|
IKE security protocol commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples
|
Internet Key Exchange Security Protocol Commands on Cisco IOS XR Software
|
IPSec conceptual information and configuration tasks
|
Implementing IPSec Network Security on Cisco IOS XR Software
|
Standards
Standards
|
Title
|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
|
—
|
MIBs
RFCs
RFCs
|
Title
|
RFC 2409
|
The Internet Key Exchange
|
RFC 2408
|
Internet Security Association and Key Management Protocol (ISAKMP) Internet Draft
|
Technical Assistance
Description
|
Link
|
The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
|
http://www.cisco.com/techsupport
|
Feedback
