Tip To ensure a successful configuration of your VPN using the IPSec VPN SPA, read all of the configuration summaries and guidelines before you perform any configuration tasks.

Overview of IKE

Internet Key Exchange (IKE) is a key management protocol standard that is used in conjunction with the IPSec standard. IPSec can be configured without IKE, but IKE enhances IPSec by providing additional features, flexibility, and ease of configuration for the IPSec standard.

Because IKE negotiations must be protected, 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. You must create an IKE policy at each peer participating in the IKE negotiation.

If you do not configure any IKE policies, your router will use the default policy, which is always set to the lowest priority and contains the default value of each parameter.

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

You can configure multiple, prioritized policies on each peer, each with a different combination of parameter values. However, 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. For each policy that you create, you assign a unique priority (1 through 10,000, with 1 being the highest priority).

Differences Between IKEv1 and IKEv2

IKE is available in two versions, IKEv1 and IKEv2. The complexity of IKEv1 made its widespread implementation difficult. IKEv2 had improved upon IKEv1 in the number of exchange messages and the renewed choices of the encryption and authentification algorithms. IKEv1 had many RFCs, IKE (RFC2409), ISAKMP (RFC2408), DOI (RFC2407), and others. IKEv2 has fewer and more consolidated RFCs.

IKEv2 has fewer phases and fewer number of messages to be exchanged during the phases, thus making it more flexible and simpler than IKEv1.

IKEv2 offers enhanced security by means of mechanisms that reduce the possibility of DoS type of attacks. To discourage DoS attacks, the responder may ask the initiator for a cookie as assurance that the connection is normal.

The restructuring of the interrelationship of attributes, transforms, and proposals in IKEv1 to a hierarchy ensures better understanding of the version. Greater flexibility in IKEv2 ensures that the communicating parties can choose SA lifetimes that are independent of each other.

NoteCisco no longer recommends using DES or MD5 (including the HMAC variant); instead, use AES and SHA-256. For more information about the latest Cisco cryptographic recommendations, see “Next Generation Encryption” available at:http://csio.cisco.com/blog/2011/10/14/next-generation-encryption/

IKEv2 CLI Constructs

IKEv2 Proposal

An Internet Key Exchange Version 2 (IKEv2) proposal is a collection of transforms used in the negotiation of Internet Key Exchange (IKE) security associations (SAs) as part of the IKE_SA_INIT exchange. The transform types used in the negotiation are as follows:

Encryption algorithm

Integrity algorithm

Pseudo-random function (PRF) algorithm

DH group

IKEv2 Policy

An IKEv2 policy contains proposals that are used to negotiate the encryption, integrity, PRF algorithms, and DH group in the IKE_SA_INIT exchange. It can have match statements that are used as selection criteria to select a policy during negotiation.

IKEv2 Profile

An IKEv2 profile is a repository of nonnegotiable parameters of IKE SA, such as local or remote identities, and authentication methods and services that are available to authenticated peers that match the profile. An IKEv2 profile must be attached to either a crypto map or an IPSec profile on the initiator. An IKEv2 profile is not mandatory on the responder.

IKEv2 Key Ring

An IKEv2 key ring is a repository of symmetric and asymmetric preshared keys and is independent of the IKEv1 key ring. The IKEv2 key ring is associated with an IKEv2 profile, and hence supports a set of peers that match the IKEv2 profile.

IKEv2 Smart Defaults

The IKEv2 Smart Defaults feature minimizes the FlexVPN configuration by covering most of the use cases. IKEv2 smart defaults can be customized for specific use cases, although customization is not recommended.

The following rules apply to the IKEv2 Smart Defaults feature:

A default configuration is displayed in the corresponding show command with default as a keyword and with no argument. For example, the show crypto ikev2 proposal default command displays the default IKEv2 proposal and the show crypto ikev2 proposal command displays the default IKEv2 proposal, along with user-configured proposals, if any.

The default configuration is displayed in the show running-config all command; it is not displayed in the show running-config command.

You can modify the default configuration, which is displayed in the show running-config all command.

A default configuration can be disabled using the no form of the corresponding command, for example, no crypto ikev2 proposal default . A disabled default configuration is not used in negotiation, but the configuration is displayed in the show running-config command. A disabled default configuration loses user modification, if any, and restores the system-configured values.

A default configuration can be reenabled using the default form of the corresponding command, for example, default crypto ikev2 proposal .

The default mode for the default transform set is transport; the default mode for all other transform sets is tunnel.

NoteWe recommend you do not use MD5 (including the HMAC variant) and DH groups 1, 2 and 5; use SHA-256 and DH Groups 14 or higher instead. For more information about the latest Cisco cryptographic recommendations, see “Next Generation Encryption” available at:http://csio.cisco.com/blog/2011/10/14/next-generation-encryption/

The following table lists the commands that are enabled with the IKEv2 Smart Defaults feature, along with the default values.

Information About IKEv2 Exchanges

IKE communications consist of pairs of messages, a request, and a response each, called exchanges. The first exchange of messages, the IKE_SA_INIT and IKE_AUTH exchanges establish an IKE SA. The initial exchanges normally consist of four messages. Subsequent IKE exchanges are called the CREATE_CHILD_SA or INFORMATIONAL exchanges. It is imperative that all IKE_SA_INIT exchanges be completed before any other exchange type, after which all IKE_AUTH exchanges must be completed. Thereafter, any number of CREATE_CHILD_SA and INFORMATIONAL exchanges occur in no preordained order.

An IKE message flow always consists of a request followed by a response. The requester ensures reliability. If the response is not received within a timeout interval, the requester either retransmits the request, or abandons the connection.

IKE_AUTH exchanges are crypto protected. They exchange identities, and prove knowledge of the secrets related to those identities. They also establish the IKE and the first, and usually the only, AH and, or or ESP CHILD-SA.

Informational exchanges happen only after the initial exchanges. They are status and control messages that are crypto protected. They delete SAs, report error conditions, check SA liveliness, and perform other SA housekeeping functions.

Configuring Basic IKEv2 CLI Constructs

To enable IKEv2 on a crypto interface, attach an IKEv2 profile to the crypto map or IPsec profile applied to the interface.

NoteThis step is optional on the IKEv2 responder.

Restrictions for Configuring IKEv2

You cannot configure an option that is not supported on a specific platform. For example, in a security protocol, the capability of the hardware crypto engine is important, and you cannot specify the Triple Data Encryption Standard (3DES) or the AES type of encryption transform in a nonexportable image, or specify an encryption algorithm that a crypto engine does not support.

NoteThe difference between IKEv1 and IKEv2 is that you need not enable IKEv1 on individual interfaces because IKEv1 is enabled globally on all the interfaces on a device.

When IPsec SA is created by IKEv2, idle timeout does not work for IKEv2 IPsec SA.

To manually configure basic IKEv2 constructs, perform the following tasks:

Configuring IKEv2 Key Rings

Perform this task to configure the IKEv2 key ring if the local or remote authentication method is a preshared key.

IKEv2 key rings must be configured in the peer configuration submode that defines a peer subblock.

An IKEv2 key ring can have multiple peer subblocks. A peer subblock contains a single symmetric or asymmetric key pair for a peer or peer group identified by any combination of the hostname, identity, and IP address.

IKEv2 key rings are independent of IKEv1 key rings. The key differences are as follows:

IKEv2 key rings support symmetric and asymmetric preshared keys.

IKEv2 key rings do not support Rivest, Shamir, and Adleman (RSA) public keys.

IKEv2 key rings are specified in the IKEv2 profile and are not looked up, unlike IKEv1, where keys are looked up on receipt of MM1 to negotiate the preshared key authentication method. The authentication method is not negotiated in IKEv2.

IKEv2 key rings are not associated with VPN routing and forwarding (VRF) during configuration. The VRF of an IKEv2 key ring is the VRF of the IKEv2 profile that refers to the key ring.

A single key ring can be specified in an IKEv2 profile, unlike an IKEv1 profile, which can specify multiple key rings.

A single key ring can be specified in more than one IKEv2 profile, if the same keys are shared across peers matching different profiles.

An IKEv2 key ring is structured as one or more peer sub-blocks.

On an IKEv2 initiator, the key lookup for the IKEv2 key ring is performed using the hostname of the peer or the address, in that order. On an IKEv2 responder, the key lookup is performed using the IKEv2 identity of the peer or the address, in that order.

Note The identity is available for key lookup on the IKEv2 responder only.

Step 9

pre-shared-key {
local |
remote } {
0 |
6 | line | hex }

Example:

Router(config-ikev2-keyring-peer)#pre-shared-key local key 1

Specifies the preshared key of the peer.

Step 10

end

Example:

Router(config-ikev2-keyring-peer)# end

Exits the IKEv2 key ring peer configuration mode.

Configuration Example for Keyring

Router#enable

Router#conf t

Router(config)#crypto ikev2 keyring keyring-1

Router(config-ikev2-keyring)#peer company

Router(config-ikev2-keyring-peer)#description first keyring

Router(config-ikev2-keyring-peer)#hostname host-1

Router(config-ikev2-keyring-peer)#address 10.0.0.1

% Address/Mask 10.0.0.1/255.255.255.255 is configured in peer 'cisco'

Router(config-ikev2-keyring-peer)#identity address 10.0.0.5

Router(config-ikev2-keyring-peer)#pre-shared key local 5

Router(config-ikev2-keyring-peer)#end

Configuring an IKEv2 Profile (Basic)

An IKEv2 profile is a repository of nonnegotiable parameters of the IKE SA such as:

Local or remote identities

Authentication methods

Services available to authenticated peers that match the profile

An IKEv2 profile must be configured and associated with either a crypto map or an IPsec profile on the IKEv2 initiator. Use the set ikev2-profile profile-name command to associate a profile with a crypto map or an IPsec profile. To disassociate the profile, use the no form of the command.

The following rules apply to match statements:

An IKEv2 profile must contain a match identity or a match certificate statement; otherwise, the profile is considered incomplete and is not used. An IKEv2 profile can have more than one match identity or match certificate statements.

An IKEv2 profile must have a single-match Front Door VPN routing and forwarding (FVRF) statement.

When a profile is selected, multiple match statements of the same type are logically used with the operator OR, and multiple match statements of different types are logically used with the AND operator.

The match identity and match certificate statements are considered to be the same type of statements and are used with the OR operator.

The configuration of overlapping profiles is considered a misconfiguration. In the case of multiple profile matches, no profile is selected.

Note If the local authentication method is a preshared key, the default local identity is the IP address. If the local authentication method is an RSA signature, the default local identity is a Distinguished Name.

Step 9

initial-contact [ force ]

Example:

Router(config-ikev2-profile)#initial-contact force

Enforces initial contact processing if the initial contact notification is not received in the IKE_AUTH exchange.

Step 10

ivrf name

Example:

Router(config-ikev2-profile)#ivrf vrf1

(Optional) Specifies a user-defined VPN routing and forwarding (VRF) or global VRF if the IKEv2 profile is attached to a crypto map.

If the IKEv2 profile is used for tunnel protection, the Inside VRF (IVRF) for the tunnel interface should be configured on the tunnel interface.

Note IVRF specifies the VRF for cleartext packets. The default value for IVRF is FVRF.

Step 11

keyring { local keyring-name | aaa list-name }

Example:

Router(config-ikev2-profile)#keyring local keyring-1

Specifies the local or AAA-based key ring that must be used with the local and remote preshared key authentication method.

Note You can specify only one key ring. Local AAA is not supported for AAA-based preshared keys.

(Optional) Enables NAT keepalive and specifies the duration in seconds.

Note NAT is disabled by default.

Step 15

pki trustpoint trustpoint-label [ sign | verify ]

Example:

Router(config-ikev2-profile)# pki trustpoint cisco sign

Specifies Public Key Infrastructure (PKI) trustpoints for use with the RSA signature authentication method.

Note If the sign or verify keyword is not specified, the trustpoint is used for signing and verification.

Note In contrast to IKEv1, a trustpoint must be configured in an IKEv2 profile for certificate-based authentication to succeed. There is no fallback for globally configured trustpoints if this command is not present in the configuration. The trustpoint configuration applies to the IKEv2 initiator and responder.

Step 16

redirect gateway auth

Example:

Router(config-ikev2-profile)# redirect gateway auth

Enables the redirect mechanism on the gateway after SA authentication.

Note The redirect mechanism is specific to the IKEv2 profiles.

Step 17

end

Example:

Router(config-ikev2-profile)#end

Exits the IKEv2 profile configuration mode and returns to the privileged EXEC mode.

Sample Configuration: IKEv2 Profile

Router#enable

Router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)#crypto ikev2 profile profile-1

Router(config-ikev2-profile)#description This is an ikev2 profile.

Router(config-ikev2-profile)#aaa authentication eap list-1

Router(config-ikev2-profile)#authentication remote pre-share

Router(config-ikev2-profile)#dpd 20 5 on-demand

Router(config-ikev2-profile)#identity local email xyz@example.com

Router(config-ikev2-profile)#initial-contact force

Router(config-ikev2-profile)#ivrf global

Router(config-ikev2-profile)#keyring local keyring-1

% Profile already contains this keyring

Router(config-ikev2-profile)#lifetime 200

Router(config-ikev2-profile)#match address 10.10.10.10

Router(config-ikev2-profile)#nat keepalive 100

Router(config-ikev2-profile)#redirect gateway auth

! (IKEv2 Cluster load-balancer is not enabled)

Router(config-ikev2-profile)#end

Verification of IKEv2 Profile Configuration

Use the show crypto ikev2 profile command to verify the configuration of an IKEv2 profile.

Router#show crypto ikev2 profile profile-1

IKEv2 profile: profile-1

Ref Count: 1

Description: This is an ikev2 profile.

Match criteria:

Fvrf: global

Local address/interface: none

Identities:

address 0.0.0.0

Certificate maps: none

Local identity: email xyz@example.com

Remote identity: none

Local authentication method: pre-share

Remote authentication method(s): pre-share

EAP options: none

Keyring: keyring-1

Trustpoint(s): none

Lifetime: 200 seconds

DPD: interval 20, retry-interval 5, on-demand

NAT-keepalive: 100 seconds

Ivrf: global

Virtual-template: none

AAA EAP authentication mlist: list-1

Information About IKEv2 Proposal

An IKEv2 proposal is a set of transforms used in the negotiation of IKEv2 SA as part of the IKE_SA_INIT exchange. An IKEv2 proposal is regarded as complete only when it has at least an encryption algorithm, an integrity algorithm, and a DH group configured. If no proposal is configured and attached to an IKEv2 policy, the default proposal in the default IKEv2 policy is used in negotiation.

NoteSecurity threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see theNext Generation Encryption white paper.

Although the IKEv2 proposal works like the crypto isakmp policy command, the IKEv2 proposal is different in the following respects:

An IKEv2 proposal allows the configuration of one or more transforms

An IKEv2 proposal does not have any associated priority.

Configuring an IKEv2 Proposal

Perform this task to override the default IKEv2 proposal, or to manually configure the proposal, if you do not want to use the default proposal.

The sha256 keyword specifies SHA-2 family 256-bit (HMAC variant) as the hash algorithm.

The sha384 keyword specifies SHA-2 family 384-bit (HMAC variant) as the hash algorithm.

The sha512 keyword specifies SHA-2 family 512-bit (HMAC variant) as the hash algorithm.

Step 6

group {
1 } { 14 } {
15 } {
16 } {
19 }{
2 } {
20 }{
24 } {
5 }

Example:

Router(config-ikev2-proposal)#group 14

Specifies the DH group identifier.

The default DH group identifiers are group 2 and group 5 in the IKEv2 proposal:

1—768-bit DH. (No longer recommended.)

2—1024-bit DH. (No longer recommended.)

5—1536-bit DH. (No longer recommended.)

14—Specifies the 2048-bit DH group.

15—Specifies the 3072-bit DH group.

16—Specifies the 4096-bit DH group.

19—Specifies the 256-bit elliptic curve DH (ECDH) group.

20—Specifies the 384-bit ECDH group.

24—Specifies the 2048-bit DH group.

The group that is chosen must be strong enough (have enough bits) to protect the IPsec keys during negotiation. A generally accepted guideline recommends the use of a 2048-bit group after 2013 (until 2030). Either group 14 or group 24 can be selected to meet this guideline. Even if a longer-lived security method is needed, the use of elliptic curve cryptography is recommended, but group 15 and group 16 can also be considered.

Step 7

end

Example:

Router(config-ikev2-proposal)#end

Exits the IKEv2 proposal configuration mode and returns to the privileged EXEC mode.

NoteAfter you create the IKEv2 proposal, attach it to a policy so that the proposal is picked for negotiation. For information about completing this task, see the“Configuring IKEv2 Policies” section.

Configuration Example: IKEv2 Proposal

Router#enable

Router#conf t

Router(config)#crypto ikev2 proposal proposal-2

Router(config-ikev2-proposal)#encryption aes-cbc-192

Router(config-ikev2-proposal)#integrity sha1

Router(config-ikev2-proposal)#group 14

Router(config-ikev2-proposal)#end

Verification of IKEv2 Proposal Configuration

Use the show crypto ikev2 proposal [ name | default ] command to verify all the IKEv2 proposals. To verify the default proposal, use the command with the option ‘default’. To verify a user-defined proposal, use the command with the proposal name.

The following examples show sample output for the show crypto ikev2 proposal command:

Default Proposal

IKEv2 proposal: default

Encryption : AES-CBC-256 AES-CBC-192 AES-CBC-128

Integrity : SHA512 SHA384 SHA256 SHA96 MD596

PRF : SHA512 SHA384 SHA256 SHA1 MD5

DH Group : DH_GROUP_1536_MODP/Group 5 DH_GROUP_1024_MODP/Group 2

User-defined Proposal

IKEv2 proposal: proposal-2

Encryption : AES-CBC-192

Integrity : SHA96

PRF : SHA1

DH Group : DH_GROUP_2048_MODP/Group 14

Information About IKEv2 Policies

An IKEv2 policy must contain at least one proposal to be considered as complete and can have match statements, which are used as selection criteria to select a policy for negotiation. During the initial exchange, the local address (IPv4 or IPv6) and the Front Door VRF (FVRF) of the negotiating SA are matched with the policy and the proposal is selected.

The following rules apply to the match statements:

An IKEv2 policy without any match statements will match all peers in the global FVRF.

An IKEv2 policy can have only one match FVRF statement.

An IKEv2 policy can have one or more match address local statements.

When a policy is selected, multiple match statements of the same type are logically ORed and match statements of different types are logically ANDed.

There is no precedence between match statements of different types.

Configuration of overlapping policies is considered a misconfiguration. In the case of multiple, possible policy matches, the first policy is selected.

Configuring Advanced Encryption Standard in an IKE Policy Map

The Advanced Encryption Standard (AES) is a privacy transform for IPSec and Internet Key Exchange (IKE) that has been developed to replace Data Encryption Standard (DES). AES is designed to be more secure than DES. AES offers a larger key size, while ensuring that the only known approach to decrypt a message is for an intruder to try every possible key. AES has a variable key length. The algorithm can specify a 128-bit key (the default), a 192-bit key, or a 256-bit key.

To configure the AES encryption algorithm within an IKE policy map, perform this task beginning in global configuration mode:

Command

Purpose

Step 1

Router(config)# crypto isakmp policy priority

Defines an ISAKMP policy and enters ISAKMP policy configuration mode.

priority —Identifies the IKE policy and assigns a priority to the policy. Use an integer from 1 to 10000, with 1 being the highest priority and 10000 the lowest.

Step 2

Router(config-isakmp)# encryption { aes | aes 192 | aes 256 }

Specifies the encryption algorithm within an IKE policy.

aes —Specifies 128-bit AES as the encryption algorithm.

aes 192 —Specifies 192-bit AES as the encryption algorithm.

aes 256 —Specifies 256-bit AES as the encryption algorithm.

Step 3

...

Router(config-isakmp)# exit

Specifies any other policy values appropriate to your configuration, and then exits ISAKMP policy configuration mode.

For details on configuring an ISAKMP policy, see the Cisco IOS Security Configuration Guide .

Verifying the AES IKE Policy

To verify the configuration of the AES IKE policy, enter the show crypto isakmp policy command:

Configuring ISAKMP Keyrings

A crypto keyring is a collection of preshared and RSA public keys. You can configure a keyring and then associate it with the Internet Security Association and Key Management Protocol (ISAKMP) profile. The crypto ISAKMP profile may contain zero, one, or more than one keyring.

The ISAKMP keyrings feature (also known as the SafeNet IPSec VPN Client Support feature) allows you to use the local-address command to limit the scope of an ISAKMP profile or ISAKMP keyring configuration to a local termination address or interface. The benefit of this feature is that different customers can use the same peer identities and ISAKMP keys by using different local termination addresses.

ISAKMP Keyrings Configuration Guidelines and Restrictions

When configuring ISAKMP keyrings, follow these guidelines and restrictions:

The local address option works only for the primary address of an interface.

If an IP address is provided, the administrator must ensure that the connection of the peer terminates to the address that is provided.

If the IP address does not exist on the device, or if the interface does not have an IP address, the ISAKMP profile or ISAKMP keyring will be effectively disabled.

Limiting an ISAKMP Profile to a Local Termination Address or Interface

To configure an ISAKMP profile and limit it to a local termination address or interface, perform this task beginning in global configuration mode:

Configuring Certificate to ISAKMP Profile Mapping

The Certificate to ISAKMP Profile Mapping feature enables you to assign an Internet Security Association and Key Management Protocol (ISAKMP) profile to a peer on the basis of the contents of arbitrary fields in the certificate. In addition, this feature allows you to assign a group name to those peers that are assigned an ISAKMP profile.

NoteCertificate to ISAKMP Profile Mapping is only supported as of Cisco IOS Release 12.2(33)SRA.

Follow these guidelines and restrictions when configuring Certificate to ISAKMP Profile Mapping:

This feature will not be applicable if you use Rivest, Shamir, and Adelman (RSA)- signature or RSA-encryption authentication without certificate exchange. ISAKMP peers must be configured to do RSA-signature or RSA-encryption authentication using certificates.

Mapping the Certificate to the ISAKMP Profile

To map the certificate to the ISAKMP profile, perform the following task beginning in global configuration mode:

Verifying the Certificate to ISAKMP Profile Mapping Configuration

To verify that the subject name of the certificate map has been properly configured, enter the show crypto pki certificates and the debug crypto isakmp commands.

The show crypto pki certificates command displays all current IKE security associations (SAs) at a peer. The debug crypto isakmp command displays messages about IKE events.

The following examples show that a certificate has been mapped to an ISAKMP profile. The examples include the configurations for the responder and initiator, the show crypto pki certificates command output verifying that the subject name of the certificate map has been configured, and the debug crypto isakmp command output showing that the certificate has gone through certificate map matching and been matched to the ISAKMP profile.

Responder Configuration

crypto pki certificate map cert_map 10

! The above line is the certificate map definition.

subject-name co ou = green

! The above line shows that the subject name must have "ou = green."

!

crypto isakmp profile certpro

! The above line shows that this is the ISAKMP profile that will match if the certificate

of the peer matches cert_map (shown on third line below).

ca trust-point 2315

ca trust-point LaBcA

match certificate cert_map

Initiator Configuration

crypto ca trustpoint LaBcA

enrollment url http://10.76.82.20:80/cgi-bin/openscep

subject-name ou=green,c=IN

! The above line ensures that the subject name "ou = green" is set.

revocation-check none

Command Output for show crypto pki certificates for the Initiator

Router# show crypto pki certificates

Certificate

Status: Available

Certificate Serial Number: 21

Certificate Usage: General Purpose

Issuer:

cn=blue-lab CA

o=CISCO

c=IN

Subject:

Name: Router.cisco.com

c=IN

ou=green

! The above line is a double check that "ou = green" has been set as the subject name.

Configuring an Encrypted Preshared Key

Encrypted Preshared Key Configuration Guidelines and Restrictions

Follow these guidelines and restrictions when configuring an encrypted preshared key:

Old ROM monitors (ROMMONs) and boot images cannot recognize the new type 6 passwords. If you boot from an old ROMMON, you can expect errors.

If the password (master key) is changed, or reencrypted, using the key config-key password-encryption command, the list registry passes the old key and the new key to the application modules that are using type 6 encryption.

If the master key that was configured using the key config-key password-encryption command is deleted from the system, a warning is printed (and a confirm prompt is issued) that states that all type 6 passwords will become useless. As a security measure, after the passwords have been encrypted, they will never be decrypted in the Cisco IOS software. However, passwords can be reencrypted.

Caution If the password configured using the
key config-key password-encryption command is lost, it cannot be recovered. The password should be stored in a safe location.

If you later unconfigure password encryption using the no password encryption aes command, all existing type 6 passwords are left unchanged, and as long as the password (master key) that was configured using the key config-key password-encryption command exists, the type 6 passwords will be decrypted as and when required by the application.

Because no one can “read” the password (configured using the key config-key password-encryption command), there is no way that the password can be retrieved from the router. Existing management stations cannot “know” what it is unless the stations are enhanced to include this key somewhere, in which case the password needs to be stored securely within the management system. If configurations are stored using TFTP, the configurations are not standalone, meaning that they cannot be loaded onto a router. Before or after the configurations are loaded onto a router, the password must be manually added (using the key config-key password-encryption command). The password can be manually added to the stored configuration but is not recommended because adding the password manually allows anyone to decrypt all passwords in that configuration.

If you enter or cut and paste cipher text that does not match the master key, or if there is no master key, the cipher text is accepted or saved, but the following alert message is printed:

ciphertext>[for username bar>] is incompatible with the configured master key

If a new master key is configured, all the plain keys are encrypted and made type 6 keys. The existing type 6 keys are not encrypted. The existing type 6 keys are left as is.

If the old master key is lost or unknown, you have the option of deleting the master key using the no key config-key password-encryption command. Deleting the master key using the no key config-key password-encryption command causes the existing encrypted passwords to remain encrypted in the router configuration. The passwords will not be decrypted.

When an IKE SA limit is defined, the router no longer accepts or initiates new IKE SA requests when this value has been reached as follows: 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 syslog is generated. This log contains the source destination IP address of the SA request.

Configure a system resource limit by entering the call admission limit command.

When a system resource limit is defined, the router no longer accepts or initiates new IKE SA requests when the specified level of system resources is being used as follows: Call Admission Control (CAC) polls a global resource monitor so that IKE knows when the router is running short of CPU cycles or memory buffers. You can configure a resource limit, from 1 to 100000, that represents a level of system resources. When that level of the system resources is being used, IKE no longer accepts or initiates new IKE SA requests.

CAC is applied to new SAs (that is, when an SA does not already exist between the peers) and rekeying SAs. Every effort is made to preserve existing SAs. Only new SA requests will ever be denied due to a lack of system resources or because the configured IKE SA limit has been reached.

Configuring the IKE Security Association Limit

To configure an IKE Security Association limit, perform the following steps beginning in global configuration mode. When an IKE SA limit is defined, the router no longer accepts or initiates new IKE SA requests when the limit has been reached:

Specifies the maximum number of IKE SAs that the router can establish before IKE no longer accepts or initiates new SA requests.

sa number —Number of active IKE SAs allowed on the router. The range is 0 to 99999.

in-negotiation-sa number —Number of in-negotiation IKE SAs allowed on the router. The range is 10 to 99999.

Note An ISAKMP connection needs to be built in two directions. If you have 500 spokes in your network, you should set this value at a minimum of 1000 (500 x 2).

Step 2

Router(config)# exit

Returns to privileged EXEC mode.

Configuring a System Resource Limit

To configure a system resource limit, perform the following steps beginning in global configuration mode. When an IKE SA limit is defined, the router no longer accepts or initiates new IKE SA requests when the specified level of system resources is being used.

Command

Purpose

Step 1

Router(config)# call admission limit charge

Instructs IKE to stop initiating or accepting new SA requests (that is, calls for CAC) when the specified level of system resources is being used.

charge —Level of the system resources that, when used, causes IKE to stop accepting new SA requests. Valid values are 1 to 100000.

Step 2

Router(config)# exit

Returns to privileged EXEC mode.

Clearing Call Admission Statistics

To clear the Call Admission Control counters that track the number of accepted and rejected Internet Key Exchange (IKE) requests, use the clear crypto call admission statistics command in global configuration mode:

Router(config)# clear crypto call admission statistics

Verifying the Call Admission Control for IKE Configuration

To verify that Call Admission Control has been configured, enter the show call admission statistics and the show crypto call admission statistics commands.

The show call admission statistics command monitors the global CAC configuration parameters and the behavior of CAC.

Configuring Dead Peer Detection

Dead Peer Detection (DPD), defined in RFC 3706, is a mechanism used to detect dead IPSec peers. IPSec is a peer-to-peer type of technology. It is possible that IP connectivity may be lost between peers due to routing problems, peer reloading, or some other situation. This lost connectivity can result in black holes where traffic is lost. DPD, based on a traffic-detection method, is one possible mechanism to remedy this situation.

NoteThe periodic option of the crypto isakmp keepalive command is only supported as of Cisco IOS Release 12.2(33)SRA; the on-demand option is supported in all releases.

DPD supports two options: on-demand or periodic. The on-demand approach is the default. With on-demand DPD, messages are sent on the basis of traffic patterns. For example, if a router must send outbound traffic and the liveliness of the peer is questionable, the router sends a DPD message to query the status of the peer. If a router has no traffic to send, it never sends a DPD message. If a peer is dead, and the router never has any traffic to send to the peer, the router will not find out until the IKE or IPSec security association (SA) has to be rekeyed (the liveliness of the peer is unimportant if the router is not trying to communicate with the peer). On the other hand, if the router has traffic to send to the peer, and the peer does not respond, the router will initiate a DPD message to determine the state of the peer.

With the periodic option, you can configure your router so that DPD messages are “forced” at regular intervals. This forced approach results in earlier detection of dead peers. For example, if a router has no traffic to send, a DPD message is still sent at regular intervals, and if a peer is dead, the router does not have to wait until the IKE SA times out to find out.

DPD is configured using the crypto isakmp keepalive command. DPD and Cisco IOS keepalives function on the basis of a timer. If the timer is set for 10 seconds, the router will send a “hello” message every 10 seconds (unless, of course, the router receives a “hello” message from the peer). The benefit of Cisco IOS keepalives and periodic DPD is earlier detection of dead peers. However, Cisco IOS keepalives and periodic DPD rely on periodic messages that have to be sent with considerable frequency. The result of sending frequent messages is that the communicating peers must encrypt and decrypt more packets.

DPD and Cisco IOS keepalive features can be used in conjunction with multiple peers in the crypto map to allow for stateless failover. DPD allows the router to detect a dead IKE peer, and when the router detects the dead state, the router deletes the IPSec and IKE SAs to the peer. If you configure multiple peers, the router will switch over to the next listed peer for a stateless failover.

DPD Configuration Guidelines and Restrictions

When configuring DPD, follow these guidelines and restrictions:

When the crypto isakmp keepalive command is configured, the Cisco IOS software negotiates the use of Cisco IOS keepalives or DPD, depending on which protocol the peer supports.

If you do not configure the periodic option using the crypto isakmp keepalive command, the router defaults to the on-demand approach.

Using periodic DPD potentially allows the router to detect an unresponsive IKE peer with better response time when compared to on-demand DPD. However, use of periodic DPD incurs extra overhead. When communicating to large numbers of IKE peers, you should consider using on-demand DPD instead.

When you configure DPD using the crypto isakmp keepalive seconds command, the seconds argument specifies the interval between DPD messages. In the case of on-demand DPD, the actual interval may be up to twice the configured value.

Configuring a Dead Peer Detection Message

To allow the router to send DPD messages to the peer, perform the following task:

Understanding IPSec NAT Transparency

The IPSec NAT transparency feature introduces support for IP Security (IPSec) traffic to travel through Network Address Translation (NAT) or Port Address Translation (PAT) points in the network by addressing many known incompatibilities between NAT and IPSec.

Before the introduction of this feature, a standard IPSec virtual private network (VPN) tunnel would not work if there were one or more NAT or PAT points in the delivery path of the IPSec packet. This feature allows IPSec to operate through a NAT/PAT device.

For detailed information on NAT Transparency, refer to the following URL:

IPSec NAT Transparency Configuration Guidelines and Restrictions

When configuring IPSec NAT transparency, follow these guidelines and restrictions:

For non-GRE over IPSec configurations, NAT transparency is supported in both tunnel and transport modes.

For point-to-point GRE over IPSec configurations, NAT transparency is supported only in tunnel mode.

For DMVPN configurations, NAT transparency is supported only in transport mode.

Configuring NAT Transparency

NAT transparency is a feature that is auto-detected by the IPSec VPN SPA. There are no configuration steps. If both VPN devices are NAT transparency-capable, NAT transparency is auto-detected and auto-negotiated.

Disabling NAT Transparency

You might want to disable NAT transparency if you already know that your network uses IPSec-awareness NAT (SPI-matching scheme). To disable NAT transparency, use the following command in global configuration mode:

Advanced Encryption Standard Configuration Example

ISAKMP Keyrings Configuration Examples

The following examples show how to limit the scope of an Internet Security Association and Key Management Protocol (ISAKMP) profile or ISAKMP keyring configuration to a local termination address or interface: