Usage Guidelines

Note	Security 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 the Next Generation Encryption (NGE) white paper.

There is no limit to the number of lists that can be defined (except for NVRAM storage limits).

Usage Guidelines

This command is required when you initially configure CA support at your router.

This command authenticates the CA to your router by obtaining the self-signed certificate of the CA that contains the public key of the CA. Because the CA signs its own certificate, you should manually authenticate the public key of the CA by contacting the CA administrator when you perform this command.

If you are using RA mode (using the enrollment mode ra command) when you issue the crypto ca authenticate command, then registration authority signing and encryption certificates will be returned from the CA as well as the CA certificate.

This command is not saved to the router configuration. However. the public keys embedded in the received CA (and RA) certificates are saved to the configuration as part of the RSA public key record (called the “RSA public key chain”).

If the CA does not respond by a timeout period after this command is issued, the terminal control will be returned so it will not be tied up. If this happens, you must re-enter the command. Cisco IOS software will not recognize CA certificate expiration dates set for beyond the year 2038. If the validity period of the CA certificate is set to expire after the year 2038, the following error message will be displayed when authentication with the CA server is attempted:

error retrieving certificate :incomplete chain

The following messages are displayed when you attempt to debug the error:

CRYPTO_PKI: Unable to read CA/RA certificates.

PKI-3-GETCARACERT Failed to receive RA/CA certificates.

If you receive an error message similar to this one, check the expiration date of your CA certificate. If the expiration date of your CA certificate is set after the year 2038, you must reduce the expiration date by a year or more.

Usage Guidelines

The crypto ca cert validate command validates the router's own certificate for a given trustpoint. Use this command as a sanity check after enrollment to verify that the trustpoint is properly authenticated, a certificate has been requested and granted for the trustpoint, and that the certificate is currently valid. A certificate is valid if it is signed by the trustpoint certification authority (CA), not expired, and so on.

Usage Guidelines

This command puts you into certificate chain configuration mode. When you are in certificate chain configuration mode, you can delete certificates using the certificate command.

Usage Guidelines

Issuing this command places the router in CA certificate map configuration mode where you can specify several certificate fields together with their matching criteria. The general form of these fields is as follows:

field-name match-criteria match-value

The field-name in the above example is one of the certificate fields. Field names are similar to the names used in the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) X.509 standard. The name field is a special field that matches any subject name or related name field in the certificate, such as the alt-subject-name, subject-name , and unstructured-subject-name fields.

• alt-subject-name -- Case-insensitive string.

• expires-on --Date field in the format dd mm yyyy hh:mm:ss or mmm dd yyyy hh:mm:ss.

• issuer-name -- Case-insensitive string.

• name -- Case-insensitive string.

• subject-name --Case-insensitive string.

• unstructured-subject-name -- Case-insensitive string.

• valid-start --Date field in the format dd mm yyyy hh:mm:ss or mmm dd yyyy hh:mm:ss.

Note

The time portion is optional in both the expires-on date and valid-start field and defaults to 00:00:00 if not specified. The time is interpreted according to the time zone offset configured for the router. The string utc can be appended to the date and time when they are configured as Universal Time, Coordinated (UTC) rather than local time.

The match-criteria in the example is one of the following logical operators:

• eq --equal (valid for name and date fields)

• ne --not equal (valid for name and date fields)

• co --contains (valid only for name fields)

• nc --does not contain (valid only for name fields)

• lt --less than (valid only for date fields)

• ge --greater than or equal to (valid only for date fields)

The match-value is a case-insensitive string or a date.

Usage Guidelines

Normally, certain certificates are stored locally in the router’s NVRAM, and each certificate uses a moderate amount of memory. To save NVRAM space, you can use this command to put the router into query mode, preventing certificates from being stored locally; instead, they are retrieved from a specified CA trustpoint when needed. This will save NVRAM space but could result in a slight performance impact.

The crypto ca certificate query command is a subcommand for each trustpoint; thus, this command can be disabled on a per-trustpoint basis.

Before you can configure this command, you must enable the crypto pki trustpoint command , which puts you in ca-trustpoint configuration mode.

Note	This command replaces the crypto ca certificate query command in global configuration mode. Although you can still enter the global configuration command, the configuration mode and command will be written back as ca-trustpoint.

Usage Guidelines

A CRL lists all the certificates of the network device that have been revoked. Revoked certificates will not be honored by your router; therefore, any IPSec device with a revoked certificate cannot exchange IP Security traffic with your router.

The first time your router receives a certificate from a peer, it will download a CRL from the CA. Your router then checks the CRL to make sure the certificate of the peer has not been revoked. (If the certificate appears on the CRL, it will not accept the certificate and will not authenticate the peer.)

A CRL can be reused with subsequent certificates until the CRL expires. If your router receives the certificate of a peer after the applicable CRL has expired, it will download the new CRL.

If your router has a CRL which has not yet expired, but you suspect that the contents of the CRL are out of date, use the crypto ca crl request command to request that the latest CRL be immediately downloaded to replace the old CRL.

This command is not saved to the configuration.

Note	This command should be used only after the trustpoint is enrolled.

Usage Guidelines

This command requests certificates from the CA for all of your router’s RSA key pairs. This task is also known as enrolling with the CA. (Technically, enrolling and obtaining certificates are two separate events, but they both occur when this command is issued.)

Your router needs a signed certificate from the CA for each RSA key pairs of your router; if you previously generated general purpose keys, this command will obtain the one certificate corresponding to the one general purpose RSA key pair. If you previously generated special usage keys, this command will obtain two certificates corresponding to each of the special usage RSA key pairs.

If you already have a certificate for your keys you will be unable to complete this command; instead, you will be prompted to remove the existing certificate first. (You can remove existing certificates with the no certificate command.)

The crypto ca enroll command is not saved in the router configuration.

Note	If your router reboots after you issue the crypto ca enroll command but before you receive the certificate(s), you must reissue the command.

Responding to Prompts

When you issue the crypto ca enroll command, you are prompted a number of times.

First, you are prompted to create a challenge password. This password can be up to 80 characters in length. This password is necessary in the event that you ever need to revoke your router’s certificate(s). When you ask the CA administrator to revoke your certificate, you must supply this challenge password as a protection against fraudulent or mistaken revocation requests.

Note	This password is not stored anywhere, so you need to remember this password.

If you lose the password, the CA administrator may still be able to revoke the router’s certificate but will require further manual authentication of the router administrator identity.

You are also prompted to indicate whether or not your router’s serial number should be included in the obtained certificate. The serial number is not used by IP Security or Internet Key Exchange but may be used by the CA to either authenticate certificates or to later associate a certificate with a particular router. (Note that the serial number stored is the serial number of the internal board, not the one on the enclosure.) Ask your CA administrator if serial numbers should be included. If you are in doubt, include the serial number.

Normally, you would not include the IP address because the IP address binds the certificate more tightly to a specific entity. Also, if the router is moved, you would need to issue a new certificate. Finally, a router has multiple IP addresses, any of which might be used with IPSec.

If you indicate that the IP address should be included, you will then be prompted to specify the interface of the IP address. This interface should correspond to the interface that you apply your crypto map set to. If you apply crypto map sets to more than one interface, specify the interface that you name in the crypto map local-address command.

Usage Guidelines

Note	Security 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 the Next Generation Encryption (NGE) white paper.

The crypto ca export pem command allows you to export certificate and RSA key pairs in PEM-formatted files. The PEM files can then be imported back into the Cisco IOS router (via the crypto pki import pem command) or other public key infrastructure (PKI) applications.

Usage Guidelines

The crypto ca export pkcs12 command creates a PKCS 12 file that contains an RSA key pair. The PKCS12 file, along with a certificate authority (CA), is exported to the location that you specify with the destination URL. If you decide not to import the file to another router, you must delete the file.

Security Measures

Keep the PKCS12 file stored in a secure place with restricted access.

An RSA keypair is more secure than a passphrase because the private key in the key pair is not known by multiple parties. When you export an RSA key pair to a PKCS#12 file, the RSA key pair now is only as secure as the passphrase.

To create a good passphrase, be sure to include numbers, as well as both lowercase and uppercase letters. Avoid publicizing the passphrase by mentioning it in e-mail or cell phone communications because the information could be accessed by an unauthorized user.

Usage Guidelines

You must enter the crypto ca import command twice if usage keys (signature and encryption keys) are used. The first time the command is entered, one of the certificates is pasted into the router; the second time the command is entered, the other certificate is pasted into the router. (It does not matter which certificate is pasted first.)

Usage Guidelines

The crypto ca import pem command allows you import certificates and RSA key pairs in PEM-formatted files. The files can be previously exported from another router or generated from other public key infrastructure (PKI) applications.

Usage Guidelines

When you enter the cyrpto ca import pkcs12 command, a ke pair and a trustpoint are generated. If you then decide you want to remove the key pair and trustpoint that were generated, enter the crypto key zeroize rsa command to zeroize the key pair and enter the no crypto ca trustpoint command to remove the trustpoint.

Note	After you import RSA keys to a target router, you cannot export those keys from the target router to another router.

Usage Guidelines

Before entering this command, you must specify a named enrollment profile using the enrollment profile in ca-trustpoint configuration mode.

After entering the crypto ca profile enrollment command, you can use any of the following commands to define the profile parameters:

• authentication command --Specifies the HTTP command that is sent to the certification authority (CA) for authentication.

• authentication terminal --Specifies manual cut-and-paste certificate authentication requests.

• authentication url --Specifies the URL of the CA server to which to send authentication requests.

• enrollment command --Specifies the HTTP command that is sent to the CA for enrollment.

• enrollment terminal --Specifies manual cut-and-paste certificate enrollment.

• enrollment url --Specifies the URL of the CA server to which to send enrollment requests.

• parameter --Specifies parameters for an enrollment profile. This command can be used only if the authentication command or the enrollment command is used.

Note	The authentication url , enrollment url , authentication terminal , and enrollment terminal commands allow you to specify different methods for certificate authentication and enrollment, such as TFTP authentication and manual enrollment.

Usage Guidelines

Use the crypto ca trustpoint command to declare a CA, which can be a self-signed root CA or a subordinate CA. Issuing the crypto ca trustpoint command puts you in ca-trustpoint configuration mode.

You can specify characteristics for the trustpoint CA using the following subcommands:

• crl --Queries the certificate revocation list (CRL) to ensure that the certificate of the peer has not been revoked.

• default (ca-trustpoint) --Resets the value of ca-trustpoint configuration mode subcommands to their defaults.

• enrollment --Specifies enrollment parameters (optional).

• enrollment http-proxy --Accesses the CA by HTTP through the proxy server.

• match certificate --Associates a certificate-based access control list (ACL) defined with the crypto ca certificate map command.

• primary --Assigns a specified trustpoint as the primary trustpoint of the router.

• root --Defines the Trivial File Transfer Protocol (TFTP) to get the CA certificate and specifies both a name for the server and a name for the file that will store the CA certificate.

Note

Beginning with Cisco IOS Release 12.2(8)T, the crypto ca trustpoint command unified the functionality of the crypto ca identity and crypto ca trusted-root commands, thereby replacing these commands. Although you can still enter the crypto ca identity and crypto ca trusted-root commands, the configuration mode and command will be written in the configuration as “crypto ca trustpoint .”

Usage Guidelines

Use this command to limit the number of IKE SAs permitted to or from a device. By limiting the number of IKE SAs that can be created on the device, you can prevent the device from being impacted due to sudden inflow of IKE SA requests. The ideal limit depends on the particular platform, the network topology, the application, and traffic patterns. When the specified limit is reached, IKE rejects all new SA requests. If you specify an IKE SA limit that is less than the current number of active IKE SAs, a warning is displayed, but SAs are not terminated. New SA requests are rejected until the active SA count is below the configured limit.

Usage Guidelines

You can enter the crypto connect vlan command only from the following:

• The associated port VLAN interface when the EtherChannel interface (port-channel interface) and participating interfaces are switch ports.

• The EtherChannel interface when the EtherChannel interface (port-channel interface) and participant interfaces are routed ports.

The crypto engine subslot command is only available for VLANs prior to the VLANs being made interface VLANs by the crypto connect vlan command.

When you enter the crypto connect vlan command, a target VLAN is made an interface VLAN if and only if the target VLAN is not currently an interface VLAN, and the target VLAN has been added to an inside trunk port using the crypto engine subslot command. If the VLAN has been added to more than one inside trunk port, the crypto connect vlan command is rejected.

The no crypto engine subslot command is allowed only after you enter the no crypto connect vlan command, or before you enter the crypto connect vlan command.

When you remove an interface VLAN from an inside trunk port and a corresponding crypto engine subslot configuration state exists, then that crypto engine subslot configuration state is not removed. If you remove a VLAN that has a crypto engine subslot configuration state, you need to manually add it back to recover. While in this inconsistent state, any attempt to enter the no crypto connect vlan command is rejected.

When you enter the no crypto connect vlan command, the interface VLAN status is removed from a VLAN. Any associated crypto engine subslot configuration state is not altered.

Usage Guidelines

If cTCP is enabled on a port, any application that uses that port will not function.

When cTCP encapsulation is enabled on the router, only packets less than or equal to 1407 in size can pass through the IPsec tunnel with the Don’t Fragment (DF) bit set. If an attempt is made to send a larger size packet, the following syslog message is generated:

CRYPTO_ENGINE: locally-sourced pkt w/DF bit set is too big,ip->tl=1450, mtu=1407

Note	If a Cisco IOS device is acting as a remote device, it has to send keepalives periodically to keep Network Address Translation (NAT) or firewall sessions from timing out.

Usage Guidelines

Use dynamic crypto maps to create policy templates that can be used when processing negotiation requests for new security associations from a remote IP security peer, even if you do not know all of the crypto map parameters required to communicate with the remote peer (such as the peer’s IP address). For example, if you do not know about all the IPsec remote peers in your network, a dynamic crypto map allows you to accept requests for new security associations from previously unknown peers. (However, these requests are not processed until the Internet Key Exchange authentication has completed successfully.)

When a router receives a negotiation request via IKE from another IPsec peer, the request is examined to see if it matches a crypto map entry. If the negotiation does not match any explicit crypto map entry, it will be rejected unless the crypto map set includes a reference to a dynamic crypto map.

The dynamic crypto map is a policy template; it will accept “wildcard” parameters for any parameters not explicitly stated in the dynamic crypto map entry. This allows you to set up IPsec security associations with a previously unknown IPsec peer. (The peer still must specify matching values for the nonwildcard IPsec security association negotiation parameters.)

If the router accepts the peer’s request, at the point that it installs the new IPsec security associations it also installs a temporary crypto map entry. This entry is filled in with the results of the negotiation. At this point, the router performs normal processing, using this temporary crypto map entry as a normal entry, even requesting new security associations if the current ones are expiring (based upon the policy specified in the temporary crypto map entry). Once the flow expires (that is, all of the corresponding security associations expire), the temporary crypto map entry is removed.

If changes are made to the Perfect Forward Secrecy (PFS) settings in the dynamic crypto map template,the changes are passed on to the PFS settings in the instantiated crypto map. During the next rekey process the new settings are used to negotiate with the remote peer.

Dynamic crypto map sets are not used for initiating IPsec security associations. However, they are used for determining whether or not traffic should be protected.

The only configuration required in a dynamic crypto map is the set transform-set command. All other configuration is optional.

Dynamic crypto map entries, like regular static crypto map entries, are grouped into sets. After you define a dynamic crypto map set (which commonly contains only one map entry) using this command, you include the dynamic crypto map set in an entry of the “parent” crypto map set using the crypto map (IPsec global configuration) command. The parent crypto map set is then applied to an interface.

You should make crypto map entries referencing dynamic maps the lowest priority map entries, so that negotiations for security associations will try to match the static crypto map entries first. Only after the negotiation request does not match any of the static map entries do you want it to be evaluated against the dynamic map.

To make a dynamic crypto map the lowest priority map entry, give the map entry referencing the dynamic crypto map the highest seq-num of all the map entries in a crypto map set.

For both static and dynamic crypto maps, if unprotected inbound traffic matches a permit statement in an access list, and the corresponding crypto map entry is tagged as “IPsec,” then the traffic is dropped because it is not IPsec protected. (This is because the security policy as specified by the crypto map entry states that this traffic must be IPsec protected.)

For static crypto map entries, if outbound traffic matches a permit statement in an access list and the corresponding security association (SA) is not yet established, the router will initiate new SAs with the remote peer. In the case of dynamic crypto map entries, if no SA existed, the traffic would simply be dropped (because dynamic crypto maps are not used for initiating new SAs).

Note

Use care when using the any keyword in permit entries in dynamic crypto maps. If it is possible for the traffic covered by such a permit entry to include multicast or broadcast traffic, the access list should include deny entries for the appropriate address range. Access lists should also include deny entries for network and subnet broadcast traffic, and for any other traffic that should not be IPsec protected.

Usage Guidelines

Once you enter the crypto-engine command, the prompt changes to the following:

Router(config-crypto-engine)#

The following crypto engine configuration commands are available when you enter the crypto-engine command:

• default --Sets a command to its defaults.

• exit --Exit service-flow submode.

• no --Negates a command or set its defaults.

• service-policy output policy-map-name --Configures the service policy by assigning a policy map to the output of an interface.

Usage Guidelines

This command is not normally needed for typical operations because the onboard hardware accelerator of the router is enabled for IPsec encryption by default. The hardware accelerator should not be disabled except on instruction from Cisco Technical Assistance Center (TAC) personnel.

Usage Guidelines

The crypto engine accelerator command will still be usable for a while, but if it is used, only the crypto engine aim command will be saved to the running and startup (nonvolatile memory) configuration.

Usage Guidelines

Weak cryptographic algorithms are insecure and do not provide adequate protection from modern threats when used with features such as IPsec, SSH, etc.

Cisco does not recommend using this command to bypass a weak crypto algorithm check and should only be used as last resort.

For more information on which cryptographic algorithms are considered weak, please refer to the sections on algorithms with a status of “Avoid” or “Legacy” in the Next Generation Cryptography document.

Changing the compliance shield status will require a device reboot to take effect.

Usage Guidelines

The crypto engine accelerator command will still be usable for a while, but if it is used, only the crypto engine em command will saved to the running and startup (nonvolatile memory) configuration.

Usage Guidelines

The VRF-Aware IPSec feature introduces IPSec tunnel mapping to Multiprotocol Label Switching (MPLS) VPNs.

Using the VRF-Aware IPSec feature, you can map IPSec tunnels to VPN routing and forwarding instances (VRFs) using a single public-facing address.

Unlike other IPSec VPN SPA feature configurations, when configuring VRF-Aware features, you do not use the crypto connect vlan command.

Usage Guidelines

The crypto engine accelerator command will still be usable for a while, but if it is used, only the crypto engine nm command will saved to the running and startup (nonvolatile memory) configuration.

Usage Guidelines

The crypto engine accelerator command will still be usable for a while, but if it is used, only the crypto engine onboard command will saved to the running and startup (nonvolatile memory) configuration.

Usage Guidelines

The crypto engine accelerator command will still be usable for a while, but if it is used, only the crypto engine slot command will be saved to the running and startup (nonvolatile memory) configuration.

Usage Guidelines

Usage guidelines vary based on whether you are in crypto-connect mode or VRF mode:

Crypto-Connect Mode Usage Guidelines

With this command, you do not need to explicitly add interface VLANs to the IPSec VPN SPA inside trunk port.

It is strongly recommended that you use the crypto engine slot command instead of manually adding and removing VLANs from the inside trunk port.

When you add an interface VLAN to an inside trunk port and that interface VLAN is not already added to another inside trunk port, the crypto engine slot configuration state on the interface VLAN is combined. If the interface VLAN is already added to another inside trunk port, the command is rejected.

You should not try to add all VLANs at one time (If you attempt this, you can recover by manually removing the VLANs from the inside trunk port.)

In crypto-connect mode, the crypto engine slot command is used in conjunction with the crypto connect vlan command.

In crypto-connect mode, the crypto engine slot command is only available for VLANs prior to the VLANs being made interface VLANs by the crypto connect vlan command.

The crypto engine slot command is rejected if you enter it on a crypto-connected interface VLAN whose current crypto engine slot configuration is different from the subslot specified in the crypto engine slot command. To change the crypto engine slot configuration on an interface VLAN, you must ensure that the VLAN is not crypto-connected.

If you change the crypto engine slot configuration on an interface VLAN, any IPSec and IKE SAs that are currently active on that interface VLAN are deleted.

If you enter the no crypto engine slot command and the interface VLAN is crypto-connected, the no crypto engine slot command is rejected. The no crypto engine slot command is allowed only after you enter the no crypto connect vlan command, or before you enter the crypto connect vlan command.

When you remove an interface VLAN from an inside trunk port and a corresponding crypto engine slot configuration state exists, then that crypto engine slot configuration state is not removed. If you remove a VLAN that has a crypto engine slot configuration state, you need to manually add it back to recover. While in this inconsistent state, any attempt to enter the no crypto connect vlan command is rejected.

When you enter the no crypto connect vlan command, the interface VLAN status is removed from a VLAN. Any associated crypto engine slot configuration state is not altered.

When you write the configuration or show the configuration, the crypto engine slot configuration state is expressed in the context of the associated interface VLAN. The interface VLAN is also shown as having been added to the appropriate inside trunk port. This is the case even if the configuration was loaded from a legacy (pre-crypto engine slot) configuration file, or if VLANs were manually added instead of being added through the crypto engine slot command.

By editing the crypto engine slot commands and inside trunk port VLANs, it is possible to produce an inconsistent configuration file.

VRF Mode Usage Guidelines

When configuring an interface VLAN or tunnel interface in VRF mode, the crypto-engine slot inside command must be specified.

When configuring an FVRF interface in VRF mode, the crypto-engine slot outside command must be specified.

In VRF mode, the crypto-connect vlan command is not used.

In Cisco IOS Release 12.2(33)SRE and later releases the subslot argument was removed.

Usage Guidelines

When you change the policy (for example, from DES to AES) on the key server (KS) and exit from global configuration mode, a syslog message appears on the primary KS indicating that the policy has changed and a rekey is needed. You can enter the crypto gdoi ks command to send a rekey based on the latest security policy in the running configuration.

When each GM receives this triggered rekey, it installs the new SAs (for example, for AES) and shortens the lifetimes of the old SAs (for example, for DES). The GM continues to encrypt and decrypt traffic using the old SAs until their shortened lifetimes expire.

For GMs that are running older versions that do not yet support the crypto gdoi ks command, the primary KS uses the software versioning feature to detect those versions and only triggers a rekey without sending instruction for policy replacement. Therefore, when a GM receives the rekey, it installs the new SAs but does not shorten the lifetimes of the old SAs. (This behavior is the same as the prior rekey method and ensures backward compatibility for devices that cannot support policy replacement.)

If the replace-now keyword is used, the GM that receives the rekey will immediately remove the old TEKs and KEK and install the new TEKs and KEK. Therefore, the new policy takes effect immediately without waiting for existing policy SAs to expire.

You must use this command on the KS or primary KS. If you try to use this command on the secondary KS, it rejects the command as shown below:

Device# crypto gdoi ks rekey

ERROR for group GET: This command must be executed on Pri-KS

Note	The replace-now keyword could cause a temporary traffic discontinuity, because all GMs may not receive the rekey message at the same time.

Usage Guidelines

This command is executed on group members. This command and its various keywords aid in testing individual group members and verifies that the group members are encrypting or decrypting traffic. This command and its keywords can be used only after the sa receive-only command has been configured on the key server.

The ipsec direction inbound optional keyword is used for situations in which all group members have been instructed to install the IPsec SAs as inbound only but for which a group member wants to install the IPsec SAs as inbound optional.

The ipsec direction inbound only keyword is used when a group member wants to change a previously set IPsec SA status to inbound only.

The ipsec direction both keyword is used when a group member has to change a previously set IPsec SA status to both inbound and outbound. In this setting, the group member accepts only cipher text.

Usage Guidelines

There are more options for configuring a group on a key server than there are for configuring a group member. The group is identified by an identity and by the server. If the GDOI group is a group member, the address of the server is specified. If the GDOI group is a key server, “server local” is specified, which indicates that this is the key server.

Usage Guidelines

The crypto identity command allows you to configure the identity of a router with a given list of DNs. Thus, when used with the dn and fqdn commands, you can set restrictions in the router configuration that prevent peers with specific certificates, especially certificates with particular DNs, from having access to selected encrypted interfaces.

Note	The identity of the peer must be the same as the identity in the exchanged certificate.

Usage Guidelines

Use the crypto ikev2 authorization policy command to specify the group for which a policy profile must be defined and the group policy information that needs to be defined or changed. You may wish to change the group policy on your router if you decide to connect to the client using a group ID that does not match the policy-name argument. The authorization policy is referred from the IKEv2 profile using the aaa authorization group command where the group name can be directly specified or derived from the remote identities using a name mangler.

If AAA authorization is configured as local, AAA derives the authorization attributes from IKEv2 client configuration group through the callback to crypto component.

After enabling this command, which puts the networking device in IKEv2 group authorization policy mode, you can specify the characteristics for the authorization policy using the following commands:

• dhcp-- Configures an IP address on the remote access client for the Dynamic Host Configuration Protocol (DHCP) to use.

• dns --Specifies the primary and secondary Domain Name Service (DNS) servers for the group.

• netmask --Subnet mask to be used by the client for local connectivity.

• pool --Refers to the IP local pool address used to allocate internal IP addresses to clients.

• subnet-acl --Configures split tunneling.

• wins --Specifies the primary and secondary Windows Internet Naming Service (WINS) servers for the group.

You can modify the default authorization policy using the crypto ikev2 authorization policy default command. You can either modify the entire authorization policy or modify one of the above commands.

You can disable the default authorization policy using the no crypto ikev2 authorization policy default command. When disabled, the values in the default authorization policy are copied and the default proposal remains inactive.

Usage Guidelines

Use this command to set the cache to store the maximum number of certificates fetched from the HTTP URLs.

Usage Guidelines

Use the crypto ikev2 cluster command to define an IKEv2 cluster policy and to enter IKEv2 cluster configuration mode.

After enabling this command, you can specify the characteristics for the cluster policy by using the following commands:

• holdtime

• master

• port

• slave

• standby-group

To view the cluster configuration, use the show crypto ikev2 cluster command.

Usage Guidelines

Use this command to enable the IKEv2 cookie challenge. A cookie challenge mitigates the effect of a DoS attack when an IKEv2 responder is flooded with session initiation requests from forged IP addresses.

Usage Guidelines

Note	Security 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 the Next Generation Encryption (NGE) white paper.

This command applies to all sessions on the router. If IPsec inline tagging is disabled, the new negotiated sessions do not negotiate the vendor ID (VID). However, the current SA and the subsequent SA rekey are enabled with the feature until the lifetime of the SA. This applies to the new IPsec SA and the rekey of the IPsec SA established using the parent or rekeyed IKE SA.

Usage Guidelines

Use this command to enable IKEv2 error path tracing and to specify the number of entries in the exit path database. When the number exceeds the specified number, new entries replace the old entries.

Usage Guidelines

Use this command to configure DPD globally for all peers. The DPD configuration in a Internet Key Exchange Version 2 (IKEv2) profile overrides the global DPD configuration.

Usage Guidelines

Use this command to fragment the IKEv2 packets at IKEv2 layer and to avoid fragmentation after encryption. The MTU size refers to the IP or UDP encapsulated IKEv2 packets. The formula for fragmenting a packet is calculated as follows:

Specified MTU - UDP header - IP header = fragment packet size.

Using the above formula, if the MTU size is 100, specified in the command as crypto ikev2 fragmentation mtu 100 , an IKE packet is fragmented if the packet size is greater than 72 bytes.

100 (specified MTU) - 8 (UDP header) - 20 (IP header) = 72 bytes.

Usage Guidelines

Use this command to enable certificate lookup based on the HTTP URL. HTTP CERT indicates that the node is capable of looking up certificates based on the URL. This avoids the fragmentation that results when transferring large certificates.

Usage Guidelines

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

• IKEv2 keyrings support symmetric and asymmetric preshared keys.

• IKEv2 keyrings do not support Rivest, Shamir and Adleman (RSA) public keys.

• IKEv2 keyrings 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 keyrings are not associated with VPN routing and forwarding (VRF) during configuration. The VRF of an IKEv2 keyring is the VRF of the IKEv2 profile that refers the keyring.

• A single keyring can be specified in an IKEv2 profile, unlike an IKEv1 profile, which can specify multiple keyrings.

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

• An IKEv2 keyring is structured as one or more peer subblocks.

On an IKEv2 initiator, IKEv2 keyring key lookup is performed using the peer’s hostname or the address, in that order. Use the hostname (ikev2 keyring) and address (ikev2 keyring) commands to configure the hostname and address in the IKEv2 keyring peer configuration mode.

On an IKEv2 responder, the key lookup is performed using the peer’s IKEv2 identity or the address, in that order. Use the address (ikev2 keyring) and identity (ikev2 keyring) command to configure the address and identity in IKEv2 keyring peer configuration mode.

Note	You cannot configure the same identity in more than one peer.

The best match is only performed for address configurations and a key lookup is performed for the remaining peer identification, including identity address.

Usage Guidelines

Call admission control limits the in-negotiation and total number of IKEv2 SA on a node.

Note	In IKEv2, rekey is not a new security association (SA) unlike in IKEv1. Hence, the rekey SA is not counted.

The queue sa-init limit keyword-argument pair limits the queue size to improve performance if you encounter packet drops from the initiating client due to response timeout. The packets are dropped when a source device sends IKEv2 INIT packets to a destination device to establish a tunnel, and the destination device is unable to process IKEv2 INIT packets faster due to a large queue of packets for processing on the responder device.

Usage Guidelines

The IKEv2 name mangler is used to derive a name for the AAA group or user authorization requests. The name mangler contains multiple statements--one for each identity type. The name mangler is derived from the specified portions of different forms of remote IKE identities or EAP identity. The name mangler is referred in the IKEv2 profile using the aaa authorization command.

After enabling this command, which puts the networking device in IKEv2 name mangler configuration mode, you can specify the characteristics for the name mangler using the following commands:

• dn-- Derives the name from the remote identity of type distinguished name (DN).

• eap --Derives the name from remote identities of type Extensible Authentication Protocol (EAP).

• email --Derives the name from the remote identity of type e-mail.

• fqdn --Derives the name from the remote identity of type Fully Qualified Domain Name (FQDN).