Chapter 5. IKEv2 Configuration
This chapter introduces IKEv2 configuration on Cisco IOS devices. The chapter assumes that the reader is familiar with the basics of IPsec VPNs, the IKEv2 protocol, and Cisco IOS IPsec implementation covered in the previous chapters. The chapter covers the foundational IKEv2 configuration topics in detail, with a focus on the rationale behind configuration and how it relates to the IKEv2 protocol. The chapter also covers smart defaults and the relevant PKI and IPsec configurations required to set up point-to-point IKEv2-based IPsec VPN tunnels between Cisco IOS devices.
The IKEv2 configuration topics that are specific to FlexVPN Client, FlexVPN Server, and IKEv2 Server Load Balancing are covered in the respective chapters.
The chapter covers the following main topics
IKEv2 Configuration Overview
This section provides a high-level overview of the IKEv2 configuration, including the guiding principle, the scope, and the purpose of the IKEv2 configuration constructs.
The Guiding Principle
One of the goals of the Cisco IKEv2 configuration is to keep the configuration intuitive and minimal. The user needs to configure only the mandatory parameters, while smart defaults are used wherever possible. Smart defaults use default values that cater to most of the use cases and can be customized to meet the needs of specific users.
Scope of IKEv2 Configuration
IKEv2 configurations have a well-defined scope, which is either context-specific or global. The context-specific configuration is used for a specific group of peers and/or negotiation context, such as VRF and local address, and this configuration is either defined in or is referenced from an IKEv2 profile or IKEv2 policy, both described later in the chapter. The global configuration is used irrespective of the context (that is, for all peers and negotiations) and is defined globally in the router configuration mode. For configuration that is defined both globally and in a specific context, such as under IKEv2 profile, the latter takes precedence.
IKEv2 Configuration Constructs
Table 5-1 lists the IKEv2 configuration constructs and shows if the configuration is mandatory, if it has a smart default, and when it must be configured.
Note that except for the IKEv2 global configuration, the scope of IKEv2 configuration is defined either by the IKEv2 profile or IKEv2 policy, as these configurations must be referenced from the IKEv2 profile or IKEv2 policy. Also, note that while the IKEv2 policy defines the scope of the IKEv2 proposals, the IKEv2 profile defines the scope of rest of the configurations.
IKEv2 Proposal
The IKEv2 proposal defines cryptographic transforms that are negotiated in the IKE_SA_INIT exchange and are used to protect the IKEv2 Security Association that is to be created. The transform types configured are encryption algorithm, pseudorandom function, integrity algorithm, and Diffie-Hellman group. Note that unlike IKEv1, IKEv2 does not negotiate authentication method and SA lifetime, so the proposal does not include them.
The IKEv2 proposal mimics and corresponds to the proposal substructure in the IKEv2 Security Association (SA) payload where an SA payload can have one or more proposals and each proposal can have one or more transforms of each type.
Any number of IKEv2 proposals can be configured on a device. If a device is to support peers with different sets of cryptographic algorithms, then a single IKEv2 proposal containing all the algorithms that are to be supported can be configured. However if this causes an issue for whatever reason, then multiple proposals can be configured, with each being selected based on criteria set in the IKEv2 policy.
One scenario where multiple IKEv2 proposals must be configured is when an initiator wants to propose both combined-mode ciphers (for example, AES-GCM) and normal ciphers (for example, AES-CBC). In this case, two separate proposals must be defined, one with combined-mode ciphers and the other with normal ciphers with the integrity algorithms. Note that unlike normal ciphers, combined-mode ciphers include both integrity and encryption in a single encryption algorithm and do not use an integrity algorithm. The IKEv2 RFC requires that combined-mode and normal ciphers be carried in separate proposals in the SA payload.
Another reason to define multiple IKEv2 proposals occurs when only specific combinations of transform types are required, as a proposal with multiple transforms of each type makes all possible combinations available to the responder to select from.
The IKEv2 proposal is called from within the IKEv2 policy, which will match on certain criteria (FVRF and/or local IP address). Once the IKEv2 proposal has been configured, it should be referenced within the IKEv2 policy to ensure it is activated when needed.
The following rules apply to the use of IKEv2 proposals
At least one transform for each type must be configured without which an IKEv2 proposal is considered incomplete and is not used in the negotiation. The only exception is when a combined-mode cipher is configured in IKEv2 proposal where an integrity algorithm is not required.
When multiple transforms of each type are configured, they must be listed in the order of most to least preferred from left to right.
When the IKEv2 initiator and responder have proposals with conflicting preferences, the initiator’s preference is honored.
An IKEv2 proposal must be referenced from an IKEv2 policy that defines the scope or the context in which the proposal is used.
For the IKE SA negotiation to be successful, the responder must have at least one IKEv2 proposal matching the transforms proposed by initiator.
Combined-mode ciphers and normal ciphers cannot be combined in a single IKEv2 proposal.
Configuring the IKEv2 Proposal
The IKEv2 proposal is created using the following command in the router global configuration mode
crypto ikev2 proposal proposal-name
Once the proposal is created, the router command prompt will change from (config) to (config-ikev2-proposal) denoting that user is in IKEv2-proposal sub-mode, and a message is displayed describing the requirements for a proposal to be complete. The following outputs shows creating an IKEv2 proposal, commands configurable under IKEv2 proposal, displaying the configured proposals, referencing the proposal from IKEv2 policy, and deleting the proposal.
Router(config)#crypto ikev2 proposal ikev2_proposal
IKEv2 proposal MUST either have a set of an encryption algorithm other than
aes-gcm, an integrity algorithm and a DH group configured or
encryption algorithm aes-gcm, a prf algorithm and a DH group configured
Router(config-ikev2-proposal)#
Under the IKEv2-proposal sub-mode, the user can configure one or more encryption algorithms, integrity algorithms, pseudorandom functions (PRFs), and Diffie-Hellman groups.
Router(config-ikev2-proposal)#?
IKEv2 Proposal commands:
encryption Set encryption algorithm(s) for proposal
exit Exit from IKEv2 proposal configuration mode
group Set the Diffie-Hellman group(s)
integrity Set integrity hash algorithm(s) for proposal
no Negate a command or set its defaults
prf Set prf algorithm(s) for proposal
If an IKEv2 proposal does not contain all types of algorithms then this will not be used, this will be noted by the Proposal Incomplete message, which is displayed in the running configuration as shown:
Router#show run | begin ikev2 proposal
crypto ikev2 proposal ikev2_proposal
! Proposal Incomplete(MUST have atleast an encryption algorithm, an integrity
algorithm and a dh group configured)
The configured IKEv2 proposals can be shown using the following command:
Router#show crypto ikev2 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
IKEv2 proposal: ikev2_proposal
Encryption : AES-GCM-256 AES-GCM-128
Integrity : none
PRF : SHA256 SHA384
DH Group : DH_GROUP_384_ECP/Group 20 DH_GROUP_521_ECP/Group 21
The proposal must be referenced from IKEv2 policy in order to be used during negotiation.
Router(config)#crypto ikev2 policy ikev2_policy
Router(config-ikev2-policy)#proposal ikev2_proposal
The proposal must be dereferenced from IKEv2 policy before the proposal can be deleted.
Router(config)#no crypto ikev2 proposal ikev2_proposal
% Cannot remove as proposal is in use.
Router(config)#crypto ikev2 policy ikev2_policy
Router(config-ikev2-policy)#no proposal ikev2_proposal
Router(config-ikev2-policy)#exit
Router(config)#no crypto ikev2 proposal ikev2_proposal
Router(config)#
The following output shows the creation of an IKEv2 proposal with normal ciphers (for example, AES-CBC), along with the necessary integrity algorithm, pseudorandom function, and Diffie-Hellman groups configured. Note that when a normal cipher is configured, the combined-mode cipher option is not available.
Router(config)#crypto ikev2 proposal ikev2_proposal
Router(config-ikev2-proposal)#encryption aes-cbc-256 ?
3des 3DES
aes-cbc-128 AES-CBC-128
aes-cbc-192 AES-CBC-192
des DES
<cr>
Router(config-ikev2-proposal)#encryption aes-cbc-256
Router(config-ikev2-proposal)#integrity sha512
Router(config-ikev2-proposal)#prf sha512
Router(config-ikev2-proposal)#group 16
The configured proposal can be seen in running configuration and in the show command output:
Router#show run | begin ikev2 proposal
crypto ikev2 proposal ikev2_proposal
encryption aes-cbc-256
integrity sha512
group 16
Router#show crypto ikev2 proposal ikev2_proposal
IKEv2 proposal: ikev2_proposal
Encryption : AES-CBC-256
Integrity : SHA512
PRF : SHA512
DH Group : DH_GROUP_4096_MODP/Group 16
The following example shows the creation of an IKEv2 proposal with combined-mode ciphers (AES-GCM), along with the necessary pseudorandom function and Diffie-Hellman groups configured. Note that when a combined-mode cipher is configured, the normal-mode cipher option is not available, configuration of an integrity algorithm is not allowed, and the proposal is marked as complete without an integrity algorithm.
Router(config)#crypto ikev2 proposal ikev2_proposal
Router(config-ikev2-proposal)#encryption aes-gcm-128 ?
aes-gcm-256 Combined-mode,256 bit key,16 byte ICV(Authentication Tag)
<cr>
Router(config-ikev2-proposal)#encryption aes-gcm-256 aes-gcm-128 ?
<cr>
Router(config-ikev2-proposal)#integrity sha512
Warning!! Integrity algorithms are not allowed with AES_GCM
Router(config-ikev2-proposal)#group 21 20
Router(config-ikev2-proposal)#prf sha512 sha384
Router(config-ikev2-proposal)#
The configured proposal can be seen in running configuration and in the show command output:
Router#show run | begin ikev2 proposal
crypto ikev2 proposal ikev2_proposal
encryption aes-gcm-256 aes-gcm-128
prf sha512 sha384
group 21 20
Router#show crypto ikev2 proposal ikev2_proposal
IKEv2 proposal: ikev2_proposal
Encryption : AES-GCM-256 AES-GCM-128
Integrity : none
PRF : SHA512 SHA384
DH Group : DH_GROUP_521_ECP/Group 21 DH_GROUP_384_ECP/Group 20
Configuring IKEv2 Encryption
The encryption algorithm is used for data confidentiality; the algorithm is used to encrypt the IKEv2 Security Association. Combined-mode ciphers give the benefit of authenticated encryption, providing both confidentiality and integrity services using a single algorithm. Table 5-2 displays the available encryption algorithms on Cisco IOS.
The following terms are used to describe the cryptographic strength throughout the rest of this chapter.
Avoid: Algorithms that are marked as Avoid do not provide adequate security against modern threats and should not be used to protect sensitive information. It is recommended that these algorithms be replaced with stronger algorithms.
Legacy: Legacy algorithms provide a marginal but acceptable security level. They should be used only when no better alternatives are available, such as when interoperating with legacy equipment. It is recommended that these legacy algorithms be phased out and replaced with stronger algorithms.
Acceptable: Acceptable algorithms provide adequate security.
Next-generation encryption (NGE): NGE algorithms are expected to meet the security and scalability requirements of the next two decades.
Quantum computer resistant (QCR): Although practical Quantum Computers (QCs) would pose a threat to crypto standards for asymmetric-based cryptographic key exchange and encryption, no one has demonstrated a practical quantum computer yet. It is an area of active research and rapidly growing interest. Although it is possible, it can’t be said with certainty whether practical QCs will be built in the future. An algorithm that would be secure even after a QC is built is said to have postquantum security or be quantum computer resistant (QCR). AES-256, SHA-384, and SHA-512 are believed to have postquantum security. There are public key algorithms that are believed to have postquantum security too, but there are no standards for their use in IKEv2 currently. Diffie-Hellman is not QCR.
AES CBC mode supports three key sizes: 128 bits, 192 bits, and 256 bits. AES uses a different number of rounds for each of the defined key sizes. When a 128-bit key is used, 10 rounds are used. When a 192-bit key is used, 12 rounds are used, and when a 256-bit key is used, 14 rounds are used.
AES GCM mode combines both encryption and authentication; for authentication a 16-byte ICV is used as described in RFC 5282. The following output shows configuring encryption in IKEv2 proposal
Router(config-ikev2-proposal)#encryption ?
3des 3DES
aes-cbc-128 AES-CBC-128
aes-cbc-192 AES-CBC-192
aes-cbc-256 AES-CBC-256
aes-gcm-128 Combined-mode,128 bit key,16 byte ICV(Authentication Tag)
aes-gcm-256 Combined-mode,256 bit key,16 byte ICV(Authentication Tag)
des DES
Note that AES-GCM-128 and AES-GCM-256 are combined-mode ciphers, and if they are used no integrity algorithm is required. These also cannot be used with DES, 3DES, or any AES-CBC mode ciphers.
Note
At the time of writing, the Cisco recommendation is to use AES where possible for encryption of IKE sessions, with AES-GCM preferred over AES-CBC mode. For the latest recommendations, please refer to the Cisco Next Generation Encryption (NGE) page at http://www.cisco.com/c/en/us/about/security-center/next-generation-cryptography.html.
Configuring IKEv2 Integrity
The integrity algorithms will be used to provide assurance that data was not changed in transit. This is achieved by calculating an Integrity Checksum Value (ICV) covering the IKE header and the encrypted payload. The ICV is included within the IKEv2 encrypted payload; this value ensures that any part of the IKE header and the encrypted payload cannot be changed while the packet is in transit. Table 5-3 displays the available integrity algorithms on Cisco IOS.
Note
Cisco recommends using a SHA2 family Integrity algorithm where possible.
The larger integrity size ensures greater security, but at the cost of a larger overhead for processing and the Integrity Checksum. The following command shows the configuration of integrity algorithms in the IKEv2 proposal.
Router(config-ikev2-proposal)#integrity sha384 sha256 sha1
The integrity algorithms will all be sent by the initiator in that order within the IKE_SA_INIT exchange contained with the transform that relates to the proposal. For a device that is acting as a responder, the integrity algorithms will be chosen in the order configured.
Configuring IKEv2 Diffie-Hellman
The Diffie-Hellman group denotes the size and type of the Diffie-Hellman exchange, in which a shared secret is exchanged by both parties over an insecure medium.
With regards to the Diffie-Hellman group, if the device is acting as the initiator of the IKEv2 session, then the Diffie-Hellman public value sent will always be the first group configured within the proposal. If the initiator of an IKEv2 session is using the default IKEv2 proposal, then the Diffie-Hellman group 5 public value will always be sent in the initial exchange. For the sake of efficiency, the correct Diffie-Hellman group should be configured whenever possible, because an incorrect Diffie-Hellman value will incur an additional two packet exchange to the IKE_SA_INIT.
Cisco recommends using Diffie-Hellman group 14 or higher, with the Elliptic Curve (EC) Diffie-Hellman groups (group 19, 20, and 21) being preferred. Some platforms perform Diffie-Hellman calculations in software; this should be taken into account when devices will be terminating a number of IKEv2 sessions and performing a large number of calculations, because servicing these calculations can overload the CPU and disrupt other processes that require it.
The following output shows configuring Diffie-Hellman groups in an IKEv2 proposal. Four Diffie-Hellman groups are configured, with group 20 being used for any IKEv2 sessions initiated from this device; however if the configured proposal is used when the device is acting as a responder, then the configured groups will be used to match the group proposed by the initiator.
Router(config-ikev2-proposal)#group 20 21 19 16
Table 5-4 displays the available Diffie-Hellman groups on Cisco IOS.
Currently no Diffie-Hellman groups are postquantum secure.
Elliptic Curve Diffie-Hellman (ECDH) groups (19, 20, and 21) offer the most security for the amount of work required. The size of the Elliptic Curve Diffie-Hellman groups can’t be compared like for like with MODP groups, because the ECDH groups are more efficient.
Configuring IKEv2 Pseudorandom Function
The pseudorandom function (PRF) is used to generate key material from the derived shared secret. The PRF is a keyed-hash message authentication code (HMAC), which is a cryptographic hash function combined with a secret cryptographic key.
When an integrity algorithm is configured, the same algorithm will automatically be used as the PRF algorithm. Interestingly, when configured for integrity algorithms MD5 and SHA1 both give a 96-bit output; however, when used for PRF, these will give 128-bit and 160-bit outputs respectively. The reason being that the output for the integrity algorithms is truncated, however this is not the case for PRF.
The following example shows how to configured three PRF algorithms, which will be selected in the order that they are configured (SHA256, being the higher preference, is listed first).
Router(config-ikev2-proposal)#prf sha256 sha1 md5
Table 5-5 displays the available pseudorandom function algorithms on Cisco IOS.
If a combined-mode cipher for encryption is used, then there is no requirement for any integrity algorithms, but in this case a PRF algorithm must be configured.
Default IKEv2 Proposal
The default IKEv2 proposal consists of the most commonly used transform values, as shown below. The default proposal is associated with default IKEv2 policy, which is used in the IKEv2 negotiation only when there is no user-defined policy. The default policy can be disabled or modified to address the specific needs of users, after which it is displayed in the running configuration. The following examples show disabling, modifying, and restoring the default IKEv2 proposal.
Router#show crypto ikev2 proposal default
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
Router#show crypto ikev2 policy default
IKEv2 policy : default
Match fvrf : any
Match address local : any
Proposal : default
To disable the default IKEv2 proposal, the default IKEv2 policy that references default proposal must be disabled first.
Router(config)#no crypto ikev2 proposal default
% Cannot remove as proposal is in use.
Router(config)#no crypto ikev2 policy default
Router(config)#no crypto ikev2 proposal default
Router#show run | include ikev2 proposal default
no crypto ikev2 proposal default
Router#show crypto ikev2 proposal default
IKEv2 proposal: default Disabled
The default proposal is re-enabled with the following command:
Router(config)#default crypto ikev2 proposal
Router#show run | include ikev2 proposal default
Router#show crypto ikev2 proposal default
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
When modifying the default IKEv2 proposal, note that modified default proposal is displayed in running configuration.
Router(config)#crypto ikev2 proposal default
%Warning: This will Modify Default IKEv2 Proposal. Exit if you don't want
The integrity algorithms must be removed before configuring a combined mode cipher.
Router(config-ikev2-proposal)#no integrity sha512 sha384 sha256 sha1 md5
Router(config-ikev2-proposal)#encryption aes-gcm-256
Router(config-ikev2-proposal)#prf sha512
Router(config-ikev2-proposal)#group 21
Router(config-ikev2-proposal)#
Router#show run | begin ikev2 proposal default
crypto ikev2 proposal default
encryption aes-gcm-256
prf sha512
group 21
Router#show crypto ikev2 proposal default
IKEv2 proposal: default
Encryption : AES-GCM-256
Integrity : none
PRF : SHA512
DH Group : DH_GROUP_521_ECP/Group 21
The modified default proposal can be restored as follows:
Router(config)#default crypto ikev2 proposal
Router#show run | begin ikev2 proposal default
Router#show crypto ikev2 proposal default
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
IKEv2 Policy
The IKEv2 policy defines the set of IKEv2 proposals used in an IKEv2 negotiation based on the local context determined by the local address and FVRF used by the IKEv2 negotiation. Note that this applies to both outgoing and incoming negotiations.
An IKEv2 policy can be defined to cater to a specific or multiple contexts. In the case of overlapping policies (that is, when multiple IKEv2 policies are available for a given context), the best or most specific match is used, although configuration of overlapping policies is not recommended for simplicity.
The default IKEv2 policy contains the default IKEv2 proposal and matches any context, that is, any FRVF and any IPv4 or IPv6 local address. Note that the default IKEv2 policy is used for IKEv2 negotiation only in the absence of any user-defined IKEv2 policy.
From the IKEv2 RFC perspective, the IKEv2 policy corresponds to the IKEv2 Security Association (SA) payload in the IKE_SA_INIT messages used for IKE SA negotiation that contains one or more proposals.
The following is a quick recap of VRFs, IVRF, and FVRF, which were described in chapter 4, “IOS IPsec Implementation.”
VRF (Virtual Routing and Forwarding) is a Cisco IOS layer-3 device virtualization technique that splits an IOS device (router/L3-switch) into multiple logical devices, each with its own interfaces and forwarding context, and is used for segregation. Cisco IOS uses two types of VRFs: FVRF and IVRF.
FVRF (front-door VRF) applies to the underlay network and hence to WAN interfaces and traffic that use underlay addresses, such as IKE and encrypted/encapsulated traffic. FVRF is used for segregation of underlay networks, for example, when a router has multiple WAN connections from different providers with overlapping address spaces.
IVRF (inside VRF) applies to the overlay network and hence to LAN interfaces and traffic that use overlay addresses such as plaintext traffic before encryption/encapsulation and after decryption/de-encapsulation. IVRF is used for segregation of overlays for multitenancy, for example, when LAN side interfaces of a router connect to different customers or departments that can have overlapping address spaces.
From a VRF perspective, Cisco IOS tunnel interfaces are an exception in that they use both FVRF and IVRF, as tunnel interfaces bridge both overlay and the underlying transport networks.
The following rules apply to the use of an IKEv2 policy:
An IKEv2 policy must have at least one IKEv2 proposal and can optionally have more proposals and match statements.
An IKEv2 policy can optionally have one or match statements to specify the context, that is, FVRFs and local addresses for which the policy will be used.
A policy can have multiple match statements of same and different types. 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.
It is not recommended to configure overlapping policies. However, in case of multiple possible policy matches, the best match will be used.
The default IKEv2 policy is used only in the absence of user-defined IKEv2 policies.
Configuring an IKEv2 Policy
An IKEv2 policy is created using the command shown below in the router global configuration mode:
crypto ikev2 policy policy-name
Once the policy is created, the router command prompt will change from (config) to (config-ikev2-policy), denoting that the user is in IKEv2-policy sub-mode, and a message is displayed stating the requirements for a policy to be complete. The following examples show the creation of an IKEv2 policy.
Router(config)#crypto ikev2 policy ikev2_policy
IKEv2 policy MUST have at least one complete proposal attached
Router(config-ikev2-policy)#
Under the IKEv2-policy sub-mode, IKEv2 proposals and match statements can be configured.
Router(config-ikev2-policy)#?
IKEv2 Policy commands:
exit Exit from IKEv2 policy configuration mode
match Match values of local fields
no Negate a command or set its defaults
proposal Specify Proposal
An IKEv2 policy must contain at least one IKEv2 proposal, without which the policy is marked incomplete in the running configuration and is not used in the negotiation.
Router#show run | begin ikev2 policy
crypto ikev2 policy temp-ikev2-policy1
! Policy Incomplete(MUST have at least one complete proposal attached)
Configuring IKEv2 Proposals under IKEv2 Policy
Under IKEv2 policy, one or more IKEv2 proposals can be configured that have been defined earlier and are complete. The following output shows configuring proposals under the IKEv2 policy. Note that nonexistent and incomplete proposals are not allowed, and if they are entered, the following error messages are displayed.
Router(config)#crypto ikev2 policy ikev2_policy
Router(config-ikev2-policy)#proposal ikev2_proposal1
% No Proposal exists with the specified name ikev2_proposal1
Router(config)#crypto ikev2 proposal ikev2_proposal1
IKEv2 proposal MUST either have a set of an encryption algorithm other than
aes-gcm, an integrity algorithm and a DH group configured or
encryption algorithm aes-gcm, a prf algorithm and a DH group configured
Router(config)#crypto ikev2 policy ikev2_policy
Router(config-ikev2-policy)#proposal ikev2_proposal1
Proposal ikev2_proposal1 is not complete to be attached to policy
Once complete, IKEv2 proposals can be configured under IKEv2 policy
Router(config)#crypto ikev2 policy ikev2_policy
Router(config-ikev2-policy)#proposal ikev2_proposal1
Router(config-ikev2-policy)#proposal ikev2_proposal2
Configuring Match Statements under IKEv2 Policy
One or more match statements can be optionally configured under IKEv2 policy to define the scope of the policy, that is, to specify the FVRFs and the local addresses for which the policy can be used.
The following rules apply to the use of match statements:
When there are multiple match statements of the same type (either specifying FRVF or local address), the policy is selected when any of the match statements is true. In other words, the match statements of same type have a logical OR relationship.
When there are multiple match statements of different types (specifying FRVF and local address), the policy is selected when all of the match statements are true. In other words, match statements of different types have a logical AND relationship.
When there are multiple match statements of both the same and different types, the policy is selected when at least one match statement of each type is true.
When there are no match statements, the policy can be used with all local addresses in Global VRF.
The following output shows the configuration of match statements under IKEv2 policy.
Router(config)#crypto ikev2 policy ikev2_policy
Router(config-ikev2-policy)#match ?
address Specify the address to match
fvrf Specify fvrf
Router(config-ikev2-policy)#match fvrf ?
WORD fvrf name (default:global)
any Any fvrf
Router(config-ikev2-policy)#match address ?
local Local address
Router(config-ikev2-policy)#match address local ?
A.B.C.D IPv4 address
X:X:X:X::X IPv6 address
The following example illustrates configuring an IKEv2 policy with multiple match statements. This policy would match IKEv2 negotiations that use the FVRF with the name mpls or internet and use either 192.168.1.1 or 2001::1 as the local address.
Router(config-ikev2-policy)#match fvrf mpls
Router(config-ikev2-policy)#match fvrf internet
Router(config-ikev2-policy)#match address local 192.168.1.1
Router(config-ikev2-policy)#match address local 2001::1
The configured match statements can be seen in running configuration and in the show command output.
Router#show run | begin ikev2 policy
crypto ikev2 policy ikev2_policy
match fvrf mpls
match fvrf internet
match address local 192.168.1.1
match address local 2001::1
proposal ikev2_proposal1
proposal ikev2_proposal2
Router#show crypto ikev2 policy ikev2_policy
IKEv2 policy : ikev2_policy
Match fvrf : mpls
Match fvrf : internet
Match address local : 192.168.1.1
Match address local : 2001::1
Proposal : ikev2_proposal1
Proposal : ikev2_proposal2
Default IKEv2 Policy
The default IKEv2 policy contains the default IKEv2 proposal, matches any local address and any FVRF, and is used in the negotiation only when there is no user-defined policy. The default policy can be disabled or modified to address the specific needs of users, after which it is displayed in the running configuration. The following example shows disabling, modifying, and restoring the default IKEv2 policy.
Router#show crypto ikev2 policy default
IKEv2 policy : default
Match fvrf : any
Match address local : any
Proposal : default
The default IKEv2 policy is disabled using the following command:
Router(config)#no crypto ikev2 policy default
Router#show run | include ikev2 policy default
no crypto ikev2 policy default
Router#show crypto ikev2 policy default
IKEv2 policy : default Disabled
The default policy is re-enabled using the following command:
Router(config)#default crypto ikev2 policy
The default IKEv2 policy is modified as shown below, after which it is displayed in running configuration.
Router(config)#crypto ikev2 policy default
Router(config-ikev2-policy)#match fvrf mpls
% Specific vrf cannot be configured when fvrf type any is already configured.
Remove any fvrf and then add specific
The match fvrf any statement in the default IKEv2 policy that matches all the FVRFs must first be removed before a match statement for a specific FRVF is configured.
Router(config-ikev2-policy)#no match fvrf any
Router(config-ikev2-policy)#match fvrf mpls
Router#show run | begin ikev2 policy default
crypto ikev2 policy default
match fvrf mpls
proposal default
Router#show crypto ikev2 policy default
IKEv2 policy : default
Match fvrf : mpls
Match address local : any
Proposal : default
The modified default policy can be restored as follows:
Router(config)#default crypto ikev2 policy
IKEv2 Policy Selection on the Initiator
The IKEv2 policy selection on the initiator of an outgoing IKEv2 session happens before the negotiation starts, that is, before the IKE_SA_INIT request is sent, as described below.
IKEv2 initiates a session with a peer when IPsec requests IKEv2 to establish an IPsec Security Association with that peer. IPsec Security Associations originate from IPsec interfaces, that is, the interfaces on which IPsec is configured. With IKEv2 the IPsec interface is typically a tunnel interface with the tunnel protection ipsec command applied, so it is the configuration on the tunnel interface that determines the outgoing IKEv2/IPsec session parameters as described below;
The session local address is derived from the tunnel source configuration. This typically is the address of the WAN interface through which IKEv2 packets enter and exit the router, but it can also be the address of a loopback interface.
The session remote address is derived either from the tunnel destination configuration or is learned dynamically.
The session IVRF and FVRF are derived from the tunnel fvrf configuration, and this must be same as the VRF configured on the WAN interface through which IKEv2 packets enter and exit the router. Note that the default value for tunnel fvrf is the global routing table (GRT), and in this case IVRF = FVRF = global routing table.
The session parameters derived from the tunnel interface are passed by IPsec to IKEv2 as part of the SA request, and IKEv2 uses these parameters to select an IKEv2 policy to use for the outgoing negotiation based on the match criteria specified in the policy.
The following output shows the IKEv2 policy selection on an initiator, based on the session parameters passed by IPsec. The IKEv2 policy selection happens before the IKE_SA_INIT request is sent to the peer. The highlighted output shows the policy lookup based on FVRF and local address. The output is obtained from the tunnel interface configuration and from debug crypto ikev2 and debug crypto kmi logs.
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
tunnel source 192.168.1.1
tunnel mode ipsec ipv4
tunnel destination 192.168.1.2
tunnel protection ipsec profile default
KMI: (Session ID: 3) IPSEC key engine sending message KEY_ENG_REQUEST_SAS to
Crypto IKEv2.
KMI: (Session ID: 3) Crypto IKEv2 received message KEY_ENG_REQUEST_SAS from IPSEC
key engine.
IKEv2:Searching Policy with fvrf 0, local address 192.168.1.1
IKEv2:Using the Default Policy for Proposal
IKEv2:Found Policy 'default'
IKEv2:(SESSION ID = 3,SA ID = 1):Generating IKE_SA_INIT message
IKEv2:(SESSION ID = 3,SA ID = 1):Sending Packet [To 192.168.1.2:500/From
192.168.1.1:500/VRF i0:f0]
Initiator SPI : CF2306A9194583C6 - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST
If a matching IKEv2 policy is not found, the following debug crypto ikev2 log message is displayed.
IKEv2:Searching Policy with fvrf 0, local address 192.168.1.1
IKEv2-ERROR:Failed to initiate sa
IKEv2 Policy Selection on Responder
The IKEV2 policy selection on the responder for an incoming IKEv2 session happens after the IKE_SA_INIT request is received. The FVRF used for policy selection is derived from the VRF of the interface through which the IKEv2 packet entered the router, and the local address is derived from the destination address in the received IKEv2 packet. The IKEv2 policy matching is based on the FVRF, the local address thus derived, and the proposals in the IKE_SA_INIT request.
The following output shows IKEv2 policy selection on a responder when the first IKEv2 packet IKE_SA_INIT request is received, using selected output from debug crypto ikev2, logs to show the IKEv2 policy selection. The highlighted output shows policy lookup.
IKEv2:Received Packet [From 192.168.1.1:500/To 192.168.1.2:500/VRF i0:f0]
Initiator SPI : C51E7F53FCA49E64 - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST
Payload contents:
SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP)
NOTIFY(NAT_DETECTION_DESTINATION_IP)
IKEv2:(SESSION ID = 850,SA ID = 1):Verify SA init message
IKEv2:(SESSION ID = 850,SA ID = 1):Insert SA
IKEv2:Searching Policy with fvrf 0, local address 192.168.1.2
IKEv2:Using the Default Policy for Proposal
IKEv2:Found Policy 'default'
If a matching IKEv2 policy is not found, the following debug crypto ikev2 log messages are displayed. The reason for the ‘policy not found’ error is mismatching or incorrect IKEv2 policy configuration on the peers.
IKEv2:Received Packet [From 192.168.1.1:500/To 192.168.1.2:500/VRF i0:f0]
Initiator SPI : 418BD852B092D462 - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST
Payload contents:
SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP)
NOTIFY(NAT_DETECTION_DESTINATION_IP)
IKEv2:(SESSION ID = 851,SA ID = 1):Verify SA init message
IKEv2:(SESSION ID = 851,SA ID = 1):Insert SA
IKEv2:Searching Policy with fvrf 0, local address 192.168.1.2
IKEv2-ERROR:(SESSION ID = 851,SA ID = 1):: Failed to locate an item in the
database
IKEv2:(SESSION ID = 851,SA ID = 1):Failed SA init exchange
IKEv2-ERROR:(SESSION ID = 851,SA ID = 1):Initial exchange failed: Initial exchange
failed
IKEv2:(SESSION ID = 851,SA ID = 1):Abort exchange
IKEv2:(SESSION ID = 851,SA ID = 1):Deleting SA
IKEv2 Policy Configuration Examples
Per-peer IKEv2 Policy
As IKEv2 policy selection is based on local address and FVRF and not remote IP address, different polices for different peers can be achieved by using different local address or FVRF for connecting to those peers.
This was an actual requirement where a customer needed to allow connections to a router from two different IKEv2 peers (called Peer1 and Peer2) and use specific Next Generation Encryption (NGE) algorithms only for connections from Peer1 and not Peer2. This required two separate local IP addresses that were configured as the tunnel destination address on the two peers. The unique local IP addresses were used to differentiate two separate Policies (Policy1 and Policy2), connections from Peer1 would be anchored on the IP address defined within Policy1 (192.168.1.1) and connections from Peer2 would be anchored on the IP address defined within Policy2 (192.168.2.1). The relevant IKEv2 proposals were defined within each seperate IKEv2 policy, which then meets the requirement that only Proposal1 will be used for IKEv2 connections anchored on 192.168.1.1 and Proposal2 will be used for IKEv2 connections anchored on 192.168.2.1. The following example illustrates an IKEv2 policy configuration, which is used for two peers.
Router#show crypto ikev2 proposal
IKEv2 proposal: Proposal1
Encryption : AES-GCM-128
Integrity : none
PRF : SHA256
DH Group : DH_GROUP_256_ECP/Group 19
IKEv2 proposal: Proposal2
Encryption : AES-CBC-128
Integrity : SHA96
PRF : SHA1
DH Group : DH_GROUP_2048_MODP/Group 14
Router#show crypto ikev2 policy
IKEv2 policy : Policy1
Match fvrf : global
Match address local : 192.168.1.1
Proposal : Proposal1
IKEv2 policy : Policy2
Match fvrf : global
Match address local : 192.168.2.1
Proposal : Proposal2
IKEv2 Policy with Multiple Proposals
The following example shows how two IKEv2 proposals can be used within an IKEv2 policy. This would be required if a device is serving both combined and non-combined mode ciphers when establishing IKEv2 Security Associations.
Router#show crypto ikev2 proposal
IKEv2 proposal: Proposal1
Encryption : AES-GCM-128
Integrity : none
PRF : SHA256
DH Group : DH_GROUP_256_ECP/Group 19
IKEv2 proposal: Proposal2
Encryption : AES-CBC-128
Integrity : SHA96
PRF : SHA1
DH Group : DH_GROUP_2048_MODP/Group 14
Router#show crypto ikev2 policy
IKEv2 policy : default
Match fvrf : any
Match address local : any
Proposal : Proposal1
Proposal : Proposal2
The following debug log, enabled using the command debug crypto ikev2 packet, shows both Proposals being sent when the device is initiating an IKEv2 Security Association. The Diffie-Hellman public value is selected from the preferred Proposal Proposal1.
IKEv2:(SESSION ID = 1,SA ID = 1):Generating IKE_SA_INIT message
IKEv2:(SESSION ID = 1,SA ID = 1):IKE Proposal: 1, SPI size: 0 (initial
negotiation),
Num. transforms: 3
AES-GCM SHA256 DH_GROUP_256_ECP/Group 19
IKEv2:(SESSION ID = 1,SA ID = 1):IKE Proposal: 2, SPI size: 0 (initial
negotiation),
Num. transforms: 4
AES-CBC SHA1 SHA96 DH_GROUP_2048_MODP/Group 14
IKEv2:(SESSION ID = 1,SA ID = 1):Next payload: SA, version: 2.0 Exchange type:
IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 308
Payload contents:
SA Next payload: KE, reserved: 0x0, length: 84
last proposal: 0x2, reserved: 0x0, length: 36
Proposal: 1, Protocol id: IKE, SPI size: 0, #trans: 3 last transform: 0x3,
reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-GCM
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA256
last transform: 0x0, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_256_ECP/Group 19
last proposal: 0x0, reserved: 0x0, length: 44
Proposal: 2, Protocol id: IKE, SPI size: 0, #trans: 4 last transform: 0x3,
reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-CBC
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA1
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA96
last transform: 0x0, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_2048_MODP/Group 14
KE Next payload: N, reserved: 0x0, length: 72
DH group: 19, Reserved: 0x0
We then see that the responder has accepted the algorithms contained within Proposal1 and replies with these as the selected algorithms within the Proposal. We also can see that the Diffie-Hellman public value is included, which matches the same group used by the initiator.
IKEv2:(SESSION ID = 1,SA ID = 1):Next payload: SA, version: 2.0 Exchange type:
IKE_SA_INIT, flags: RESPONDER MSG-RESPONSE Message id: 0, length: 264
Payload contents:
SA Next payload: KE, reserved: 0x0, length: 40
last proposal: 0x0, reserved: 0x0, length: 36
Proposal: 1, Protocol id: IKE, SPI size: 0, #trans: 3 last transform: 0x3,
reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-GCM
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA256
last transform: 0x0, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_256_ECP/Group 19
KE Next payload: N, reserved: 0x0, length: 72
DH group: 19, Reserved: 0x0
IKEv2 Keyring
Authentication within IKEv2 is accomplished by three methods: public key signatures, EAP, and shared secret. The terms shared secret and pre-shared key can be used interchangeably.
Within IKEv2, authentication is performed asymmetrically: that is, one device can use one method of authentication to prove its identity, and the peer device can use another method. When shared secrets are used, the identity of a device is proven by an initiator by sending the following output of the PRF within the AUTH payload in IKE_AUTH messages. The same concept is used when the responder proves its identity.
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <InitiatorSignedOctets>)
If the initiator’s configured shared secret for the peer it was connecting to was ‘Cisco123’, then the AUTH payload would be constructed as;
AUTH = prf( prf(Cisco123, "Key Pad for IKEv2"), <InitiatorSignedOctets>)
The following displays an AUTH payload that uses shared secrets. The authentication data is the output of the PRF and can be seen to be 160 bits, an indication that SHA1 was used as the PRF.
Type Payload: Authentication (39)
Next payload: Security Association (33)
0... .... = Critical Bit: Not Critical
Payload length: 28
Authentication Method: Shared Key Message Integrity Code (2)
Authentication Data: 27c5615a79ba2abe1c0077507770d624c3f8e246
On receipt of this payload, the peer can reconstruct the output of the PRF itself, for the PRF was previously negotiated in the IKE_SA_INIT exchange, the string “Key Pad for IKEv2” is known, and the ‘InitiatorSignedOctets’ is also available to the receiver. The pre-shared key for the peer is looked up based on the peer IP address or an IKE identity from the keyring. Once the pre-shared key has been located, all components are then available to reconstruct the authentication data. If the locally generated authentication matches the authentication data received, then the responder can be sure that the peer device is in possession of the pre-shared key and hence is authenticated.
The IKEv2 keyring is a local repository of pre-shared keys that are used with the shared secret authentication method. Note that the term local repository is used to highlight the fact that keys can also be stored remotely on a RADIUS server. One or more keyrings can be defined, and the keyrings must be referenced from the IKEv2 profile in order to be used for key lookup.
The keyring is structured into peer blocks in which each block allows grouping of one or more related peers based on their IP addresses, IKE identities, and hostnames and then defines the pre-shared key to be used with those peers. The key defined in a peer block can be either symmetric or asymmetric. A symmetric key is bidirectional in that the same key is used by a device to authenticate itself to a peer as well as to authenticate that peer (that is, to generate the authentication data sent to a peer as well as to verify the authentication data sent by that peer, which must be configured with the same key). An asymmetric key is unidirectional in that it is used by a device to either authenticate itself to a peer, in which case the key is referred to as local key, or to authenticate a peer in which case the key is referred to as remote key. The local key on a device must be configured as a remote key on the peer and vice versa.
Pre-shared keys can also be stored on a RADIUS server, which offers a scalable and centralized way of managing pre-shared keys. This is especially true for IKEv2 nodes that need to support pre-shared key authentication with a large number of peers, such as a FlexVPN Server acting as a hub or remote access server. The keys are obtained from the server using RADIUS authorization, which is based on peer IKE identity, and since identity-based key lookup is possible only on an IKEv2 responder, RADIUS-based pre-shared keys can be used only on IKEv2 responders.
Since RADIUS-based pre-shared keys are particularly relevant to the FlexVPN Server, this topic will be described in detail in chapter 9, “FlexVPN Server.”
Configuring IKEv2 Keyring
An IKEv2 keyring is created using the following command in the router’s global configuration mode:
crypto ikev2 keyring keyring-name
The following examples show the creation of an IKEv2 keyring. Once the keyring is created, the router command prompt will change to (config-ikev2-keyring), denoting that user is in IKEv2-keyring sub-mode.
Router(config)#crypto ikev2 keyring ikev2_keyring
Router(config-ikev2-keyring)#
The keyring must be referenced from the IKEv2 profile in order to be used for key lookup and is used for lookup only for peers associated with that IKEv2 profile. Note that only one keyring can be referenced from a profile.
Router(config)#crypto ikev2 profile default
Router(config-ikev2-profile)#keyring local ikev2_keyring
The keyring must be dereferenced from the IKEv2 profile before the keyring is deleted.
Router(config)#no crypto ikev2 keyring ikev2_keyring
% Cannot remove as keyring is in use.
Router(config)#crypto ikev2 profile default
Router(config-ikev2-profile)#no keyring local ikev2_keyring
Router(config-ikev2-profile)#exit
Router(config)#no crypto ikev2 keyring ikev2_keyring
Router(config)#
Configuring a Peer Block in Keyring
The following example shows the creation of a peer block under an IKEv2 keyring.
Router(config-ikev2-keyring)#?
IKEv2 Keyring commands:
exit Exit from crypto ikev2 keyring sub-mode
no Negate a command or set its defaults
peer Configure a Peer and associated keys
Once a peer block is created, the router command prompt will change to (config-ikev2-keyring-peer), denoting that the user is in the peer sub-mode. Under the peer sub-mode, peers and their corresponding pre-shared key can be configured
Router(config-ikev2-keyring)#peer peer1
Router(config-ikev2-keyring-peer)#?
Crypto IKEv2 Keyring Peer sub-mode commands:
address Specify IPv4/IPv6 address of peer
description Specify a description of this peer
exit Exit from crypto ikev2 keyring peer sub-mode
hostname Hostname of peer
identity Specify IKE identity to use
no Negate values of a command
pre-shared-key specify the pre-shared key
Configuring Peers in a Peer Block
In the keyring peer block, peers can be specified by their IP address, hostname, and identity; only one statement of each type is allowed. The IP address and identity statements can specify one or more peers using the IP address mask and domain portion of the identity (FQDN and email only), but the hostname statement can only specify a single peer. A wildcard key can be configured by specifying peers using a wildcard IP address and mask (0.0.0.0 0.0.0.0); however, the use of wildcard keys is not recommended.
The key lookup can be based on any of the three parameters—hostname, IP address, or identity—to find a matching peer block and the corresponding key. In case of overlapping peer blocks, the best match is used, though such a configuration is not recommended for simplicity.
The key lookup by peer hostname is performed only by the hostname string and not by its resolved address, as address resolution is not performed during the lookup. The key lookup by peer hostname has very limited use; although the key lookup by peer hostname can be performed on an initiator, specifying the IKE/IPsec peer as a hostname is possible only with crypto map configuration by use of the set peer hostname dynamic command and not with a tunnel interface configuration. The following output shows specifying peers in a peer block.
Specifying peers using their IP address and mask:
Router(config-ikev2-keyring-peer)#address ?
A.B.C.D IPv4 Address
X:X:X:X::X/<0-128> IPv6 address/prefix
Router(config-ikev2-keyring-peer)#address 192.168.1.0 ?
A.B.C.D specify mask
<cr>
Router(config-ikev2-keyring-peer)#address 2001::1/128
Specifying a peer using hostname,
Router(config-ikev2-keyring-peer)#hostname ?
WORD Name
Specifying peers using their Identity,
Router(config-ikev2-keyring-peer)#identity ?
address IP address
email Use email address
fqdn Use FQDN
key-id proprietary types of identification (ID KEY ID)
Router(config-ikev2-keyring-peer)#identity email ?
WORD Specify the name string
domain email Domain Name
Router(config-ikev2-keyring-peer)#identity email domain ?
WORD Specify the name string
Router(config-ikev2-keyring-peer)#identity fqdn ?
WORD Specify the name string
domain email Domain Name
Router(config-ikev2-keyring-peer)#identity fqdn domain ?
WORD Specify the name string
Router(config-ikev2-keyring-peer)#identity key-id ?
WORD ID_KEY_ID <string>
Router(config-ikev2-keyring-peer)#identity address ?
A.B.C.D IPv4 Address
X:X:X:X::X IPv6 address
Configuring Keys in a Peer Block
A peer block can have a single symmetric key or an asymmetric key pair. An asymmetric key is specified by using an additional local or remote keyword. With a symmetric key, the peer must be configured with the same key for this device. With asymmetric keys, the local key configured for a peer on one device must be configured as the remote key for this device on the peer and vice versa. The following example shows configuring pre-shared keys in a peer block.
Router(config-ikev2-keyring-peer)#pre-shared-key ?
0 Specifies an UNENCRYPTED password will follow
6 Specifies an ENCRYPTED password will follow
LINE The UNENCRYPTED (cleartext) user password
hex Key entered in hex string
local specify signing key
remote specify verifying key
Router(config-ikev2-keyring-peer)#pre-shared-key local ?
0 Specifies an UNENCRYPTED password will follow
6 Specifies an ENCRYPTED password will follow
LINE The UNENCRYPTED (cleartext) user password
hex Key entered in hex string
Router(config-ikev2-keyring-peer)#pre-shared-key remote ?
0 Specifies an UNENCRYPTED password will follow
6 Specifies an ENCRYPTED password will follow
LINE The UNENCRYPTED (cleartext) user password
hex Key entered in hex string
Key Lookup on Initiator
The key lookup on the initiator is performed before the start of IKE negotiation; hence the lookup can be based only on peer IP address or hostname, because the peer IKE identity (received in IKE_AUTH response) is not yet available. The key lookup is first performed using hostname (if available) and then by IP address if the key is not found.
Each peer block in an IKEv2 keyring must have pre-shared keys defined for a unique set of peers, and overlapping peer blocks should be avoided. However, in case of multiple matching peer blocks, the most specific match is used.
The following example shows a pre-shared key lookup being performed on the initiator at the start of IKEv2 negotiation before the first IKEv2 packet IKE_SA_INIT request is sent to the peer, using selected output below from debug crypto ikev2, debug crypto ikev2 internal, and debug crypto kmi logs. The highlighted output shows the key lookup.
KMI: (Session ID: 3) IPSEC key engine sending message KEY_ENG_REQUEST_SAS to
Crypto IKEv2.
KMI: (Session ID: 3) Crypto IKEv2 received message
IKEv2:% Getting preshared key from profile keyring ikev2_keyring
IKEv2-INTERNAL:% Getting preshared key by address 192.168.1.2
IKEv2:% Matched peer block 'Router2'
IKEv2:(SESSION ID = 3,SA ID = 1):Generating IKE_SA_INIT message
IKEv2:(SESSION ID = 3,SA ID = 1):Sending Packet [To 192.168.1.2:500/From
192.168.1.1:500/VRF i0:f0]
Initiator SPI : 83BA3833DB300CF3 - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST
If the key is not found, the following error log message is displayed if debug crypto ikev2 is enabled.
KMI: (Session ID: 3) IPSEC key engine sending message KEY_ENG_REQUEST_SAS to
Crypto IKEv2.
KMI: (Session ID: 3) Crypto IKEv2 received message KEY_ENG_REQUEST_SAS from IPSEC
key engine.
IKEv2:% Getting preshared key from profile keyring ikev2_keyring
IKEv2-ERROR:% key not found.
IKEv2-ERROR:Failed to initiate sa
Key Lookup on Responder
The key lookup on the responder is performed when an IKE_AUTH request is received; hence the lookup can be based on peer IKE identity (received in IKE_AUTH request) or IP address but not peer hostname, for the responder learns the peer from negotiation by its IP address and identity. The key lookup is first performed using the peer identity and then by IP address if a key is not found. While overlapping peer blocks should be avoided, in case of multiple matching peer blocks, the most specific match is used.
The following example shows the key lookup on a responder using selected output from debug crypto ikev2 logs. The highlighted output shows the key lookup.
IKEv2:(SESSION ID = 1069,SA ID = 1):Received Packet [From 192.168.1.1:500/To
192.168.1.2:500/VRF i0:f0]
Initiator SPI : 85A08BDDAE7D63EC - Responder SPI : 2DF24BD4A2F7A66C Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
IKEv2:(SESSION ID = 1069,SA ID = 1):Searching policy based on peer's identity
'192.168.1.1' of type 'IPv4 address'
IKEv2:found matching IKEv2 profile 'default'
IKEv2-INTERNAL:(1): Choosing IKE profile default
IKEv2:% Getting preshared key from profile keyring ikev2_keyring
IKEv2-INTERNAL:% Getting preshared key by address 192.168.1.1
IKEv2:% Matched peer block 'Router2'
If the key is not found, the following error log is displayed if debug crypto ikev2 and debug crypto ikev2 internal are enabled.
IKEv2:(SESSION ID = 1090,SA ID = 1):Received Packet [From 192.168.1.1:500/To
192.168.1.2:500/VRF i0:f0]
Initiator SPI : 16B9C6C2858AC956 - Responder SPI : 386B52AB1240F61D Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
IKEv2:% Getting preshared key from profile keyring ikev2_keyring
IKEv2:(SESSION ID = 1090,SA ID = 1):Get peer's preshared key for 192.168.1.1
IKEv2-INTERNAL:(SESSION ID = 1090,SA ID = 1):Failed to compute authentication data
IKEv2-ERROR:(SESSION ID = 1090,SA ID = 1):: Failed to authenticate the IKE SA
IKEv2:(SESSION ID = 1090,SA ID = 1):Verification of peer's authentication data
FAILED
IKEv2:(SESSION ID = 1090,SA ID = 1):Sending authentication failure notify
Table 5-6 shows the IKEv2 parameters used for pre-shared key lookup and if they can be used on an initiator and/or responder.
IKEv2 Keyring Configuration Example
The following examples show a keyring with two peer blocks to highlight the various aspects of keyring configuration.
The first peer block matches peers from company abc.com using their IP addresses and domain portion of their FQDN identities and is configured with asymmetric keys where the local key (key1) is used to authenticate to specified peers and remote key (key2) is used to validate those peers. The key lookup is first performed using the peer identity if available and if not found, using the peer IP address.
The second peer block matches a specific peer based on its hostname, host IP address, and unique Identity of each type and is configured with a symmetric key, which is used both for authenticating to the peer and validating that peer.
crypto ikev2 keyring ikev2_keyring
peer abc.com
address 192.168.1.0 255.255.255.0
identity fqdn domain abc.com
identity email domain abc.com
pre-shared-key local key1
pre-shared-key remote key2
peer peer2
hostname peer2
address 192.168.2.1 255.255.255.255
identity address 192.168.2.1
identity key-id peer2
identity fqdn peer2.abc.com
identity email [email protected]
pre-shared-key key
In the examples, the pre-shared key is cryptographically weak; these values could be trivially broken by someone performing a man-in-the-middle attack (impersonating the responder) on the service-provider network when an initiator initiates an IKEv2 session. For this reason pre-shared keys should be cryptographically strong, containing sufficient entropy to ensure that these cannot be easily broken by a brute-force or dictionary attack. RFC 7296 states that the pre-shared-key should be as cryptographically strong as the key being negotiated. If AES is being used with a 128 bit key, then the pre-shared key used should have 128 bits of entropy. If using base94 (which is compatible with the characters that can be entered as a pre-shared key within Cisco IOS), then the key length should be at least 20 characters. Table 5-7 displays cryptographic strengths and the equivalent number of base-94 characters required to achieve this strength.
Generating random pre-shared keys with sufficient entropy is hard for any human, for human nature gives us tendencies to not create true randomness. Hence passwords should be generated by a device that can generate true randomness. RFC 7296 even states the following regarding the use of passwords as pre-shared-keys.
As noted above, deriving the shared secret from a password is not secure. This construction is used because it is anticipated that people will do it anyway.
One or more keyrings can be defined, and a keyring is used for key lookup during shared-secret authentication only when it is referenced from an IKEv2 profile and is used only for the peers associated with that profile.
Only one keyring can be referenced from an IKEv2 profile; however, the same keyring can be referenced from more than one profile.
The key lookup on an initiator is based on the peer’s hostname and IP address, while on a responder it is based on the peer’s identity and IP address in that order.
Each peer block in an IKEv2 keyring must have pre-shared keys defined for a unique set of peers, and overlapping peer blocks should be avoided. However, in case of multiple matching peer blocks, the most specific match is used. Symmetric key is used for bidirectional authentication (that is, both for signing and validation of authentication data) and must be configured on both peers.
Asymmetric key is used for unidirectional authentication either for signing (local key) or validation (remote key) of authentication data. A local key on a device must be configured as the remote key on the peer and vice versa.
IKEv2 Profile
The IKEv2 profile is the central Cisco IOS IKEv2 configuration that defines a peer group based on peer identities and defines various parameters and features to be used with that peer group.
Table 5-8 lists the key IKEv2 profile parameters and the functionality they provide
The parameters and features defined in the profile such as AAA authorization, IKEv2 redirect and IKEv2 auto-reconnect that are relevant to IKEv2 load balancing and FlexVPN server are described in the respective chapters.
The IKEv2 profile is a mandatory configuration because it defines important parameters, such as authentication method and credentials, without which negotiation cannot start. Multiple IKEv2 profiles can be defined to allow per peer-group parameters and features.
An IKEv2 profile must be attached to an IPsec interface, such as a tunnel interface with tunnel protection applied, on both the initiator and responder. This profile is validated during negotiation to check if the received peer identity matches the profile and if not the negotiation is aborted. As an IPsec interface represents an IPsec SPD (Security Policy database) instance in Cisco IOS, the IKEv2 profile associated with an IPsec interface authorizes the peers that can communicate with that SPD.
IKEv2 Profile as Peer Authorization Database
From RFC 4301 (Security Architecture for the Internet Protocol) perspective, IKEv2 profile embodies a Peer Authorization Database (PAD). Here is a description of PAD from the RFC.
4.4.3. Peer Authorization Database (PAD)
The Peer Authorization Database (PAD) provides the link between the
SPD and a security association management protocol such as IKE. It
embodies several critical functions:
o identifies the peers or groups of peers that are authorized
to communicate with this IPsec entity
o specifies the protocol and method used to authenticate each
peer
o provides the authentication data for each peer
o constrains the types and values of IDs that can be asserted
by a peer with regard to child SA creation, to ensure that the
peer does not assert identities for lookup in the SPD that it
is not authorized to represent, when child SAs are created
o peer gateway location info, e.g., IP address(es) or DNS names,
MAY be included for peers that are known to be "behind" a
security gateway
The PAD provides these functions for an IKE peer when the peer acts
as either the initiator or the responder.
IKEv2 profile implements PAD and provides the functionalities described above:
Provides a linkage between SPD (IPsec interface) and the key management protocol (IKEv2) as the profile must be attached to an IPsec interface on both initiator and responder.
Specifies the protocol (IKEv2), authentication method, and credentials.
Defines the peers that are authorized to communicate with an SPD (IPsec interface).
Configuring IKEv2 Profile
An IKEv2 Profile is created using the following command in the router global configuration mode:
crypto ikev2 profile profile-name
The following examples show IKEv2 profile creation. Once the profile is created, the router command prompt will change to (config-ikev2-profile), denoting that the user is in IKEv2-profile sub-mode, and a message is displayed stating the minimum required configuration in a profile.
Router(config)#crypto ikev2 profile ikev2_profile
IKEv2 profile MUST have:
1. A local and a remote authentication method.
2. A match identity or a match certificate or match any statement.
Without the mandatory configuration in a profile, the running configuration displays it as incomplete:
Router(config)#show run | begin ikev2_profile
crypto ikev2 profile ikev2_profile
! Profile incomplete (no match identity or match certificate statement)
! Profile incomplete (no local and/or remote authentication method specified)
The profile must be attached to a tunnel interface on both the initiator and the responder, as shown in the following example. Only one profile can be attached to an interface. The IKEv2 profile can be specified with a tunnel protection command option or can be configured under an IPsec profile, which in turn is configured on tunnel interface with the tunnel protection command.
Router(config)#interface tunnel 100
Router(config-if)tunnel protection ipsec profile ipsec_profile ikev2-profile
ikev2_profile
or
Router(config)#crypto ipsec profile ipsec_profile
Router(ipsec-profile)#set ikev2-profile ikev2_profile
Router(config)#interface tunnel 100
Router(config-if)tunnel protection ipsec profile ipsec_profile
The IKEv2 profile must be detached from IPsec profile before it is deleted:
Router(config)#no crypto ikev2 profile ikev2_profile
% Profile ikev2_profile is still in use and cannot be removed
Router(config)#crypto ipsec profile ipsec_profile
Router(ipsec-profile)#no set ikev2-profile ikev2_profile
Router(ipsec-profile)#exit
Router(config)#no crypto ikev2 profile ikev2_profile
Router(config)#
Configuring Match Statements in IKEv2 Profile
Match statements in an IKEv2 profile serve two purposes: grouping of peers based on their identity and defining the scope of the profile based on the FVRF and local address context of the negotiation. An IKEv2 profile must have at least one statement matching the peer identity (match identity or match certificate) and can optionally have a statement matching FVRF and one or more statements matching peer identity and local address.
Following rules apply to the use of match statements:
The match identity and match certificate statements specify peer identity and hence are considered to be of same type. When both are present, match certificate has precedence and is evaluated first if peer certificate is available.
When there are multiple match statements of the same type (specifying peer identity, FRVF, or local address), the profile is selected when any of the match statements is true. In other words, match statements of the same type have a logical OR relationship.
When there are multiple match statements of different types (specifying peer identity, FRVF, and local address), the profile is selected when all of the match statements are true. In other words, match statements of different types have a logical AND relationship.
When there are multiple match statements of both the same and different types, the profile is selected when at least one match statement of each type is true.
When there are no match statements defining the FVRF, local address, and remote address scope, the profile is used for any local address and global FVRF.
Table 5-9 lists the match statement types supported in IKEv2 profile and the functionality they provide.
Router(config-ikev2-profile)#match ?
address IP address
certificate Peer certificate attributes
fvrf fvrf of the profile
identity IKE identity
Matching Peers by Certificate
An IKEv2 profile allows matching peers based on certificate through one or more match certificate statements that use PKI Certificate maps to match arbitrary fields in a certificate. When a peer authenticates itself using a certificate, the IKEv2 profile lookup is first performed based on the peer certificate, which is matched against the match certificate statements in the configured profiles. If a match is not found, the lookup is then performed by peer identity. The following example shows profile matching by peer certificate.
Router(config)#crypto pki certificate map certificate_map 1
Router(ca-certificate-map)#?
Crypto certificate attribute map commands:
alt-subject-name Alternate subject name
default Set a command to its defaults
exit Exit from certificate attribute map mode
expires-on Expiration date/time
issuer-name Certificate issuer name
name Any subject name field
no Negate a command or set its defaults
serial-number Certificate serial number (hexadecimal)
subject-name Certificate subject name
unstructured-subject-name Unstructured subject name
valid-start Valid after date/time
Router(ca-certificate-map)#subject-name ?
co Contains
eq Equal
nc Does not contain
ne Not Equal
Router(ca-certificate-map)#subject-name eq ?
LINE Compare string
Router(ca-certificate-map)#subject-name co Router2
Router(ca-certificate-map)#end
Router#
Router(config)#crypto ikev2 profile ikev2_profile
Router(config-ikev2-profile)#match certificate certificate_map
Router(config-ikev2-profile)#
Matching Peers by Identity
The IKEv2 profile allows matching peers based on identity of all types through one or more match identity statements. For structured identity types such as FQDN and email, in addition to exact match, the matching can also be based on the domain portion of the identity, which facilitates easier grouping of peers belonging to a common domain, such as a company or an organization.
For peers authenticating using shared secret and EAP methods, the profile lookup is based on identity, and for peers authenticating using the certificate method, the lookup is first based on certificate and then identity.
Table 5-10 lists the peer Identity types supported for matching the profile.
The following example shows how to configure profile matching by peer identity:
Router(config-ikev2-profile)#match identity ?
remote Remote identity
Router(config-ikev2-profile)#match identity remote ?
address IP Address(es)
any match any peer identity
email Fully qualified email string [Max. 255 char(s)]
fqdn Fully qualified domain name string [Max. 255 char(s)]
key-id key-id opaque string
Router(config-ikev2-profile)#match identity remote any ?
<cr>
Router(config-ikev2-profile)#match identity remote address ?
A.B.C.D IP address prefix
X:X:X:X::X/<0-128> IPv6 address/prefix-length
Router(config-ikev2-profile)#match identity remote email ?
WORD Specify the name string
domain match domain instead of exact
Router(config-ikev2-profile)#match identity remote email domain ?
WORD Specify the name string
Router(config-ikev2-profile)#match identity remote fqdn ?
WORD Specify the name string
domain match domain instead of exact
Router(config-ikev2-profile)#match identity remote fqdn domain ?
WORD Specify the name string
Router(config-ikev2-profile)#match identity remote key-id ?
WORD Specify the key-id string
Matching any Peer Identity
An IKEv2 profile can be configured as a last resort catch-all profile by using a match identity remote any statement. This allows the profile to define default parameters and features for peers that do not match any specific profile. Note that the match identity remote any statement is mutually exclusive with other match identity and match certificate statements; however, match fvrf and match address local statements that define the profile scope do not conflict with the match identity remote any statement.
This feature is useful on IKEv2 responders in simple deployments where all the peers need to be grouped into a single IKEv2 profile irrespective of the peers’ IKE identity. However, when the peers need to be grouped based on IKE identity, as in the case of managed service providers or enterprises with multiple departments, separate IKEv2 profiles must be configured with unique match statements.
The following example shows how to configure a profile that can match any peer identity.
Router(config-ikev2-profile)#match identity remote any ?
<cr>
Router(config-ikev2-profile)#match identity remote any
Router(config-ikev2-profile)#match certificate certificate_map
%Error! please remove 'match identity remote any' statement
Router(config-ikev2-profile)#match identity remote address 192.168.1.1
%Error! please unconfigure 'match identity remote any' in this profile
Router(config-ikev2-profile)#no match identity remote any
Router(config-ikev2-profile)#match identity remote address 192.168.1.1
Router(config-ikev2-profile)#match identity remote any
%Error! please remove 'match certificate' and 'match identity remote' statements
Router(config-ikev2-profile)#
Defining the Scope of IKEv2 Profile
The scope of the IKEv2 profile can be defined using an optional match fvrf statement and one or more optional match address local statements that specify the FVRF and local address context of the IKEv2 negotiations for which the profile can be used. The default scope is global routing table and any local address.
The following example shows configuring FVRF and local address to define the scope of a profile.
Router(config-ikev2-profile)#match fvrf ?
WORD fvrf name (default: global)
any any fvrf
Router(config-ikev2-profile)#match address local ?
A.B.C.D Specify an IPv4 address
X:X:X:X::X Specify an IPv6 address
interface Specify an interface
Defining the Local IKE Identity
The IKEv2 profile allows defining the local IKE identity that is used to authenticate to the peers associated with the profile. The identity is carried in the identification payload (IDi/IDr) and is included in the calculation of the authentication payload in the IKE_AUTH messages to prove the identity to the peer. The local IKE identity is configured with the identity local statement. When it is not configured, the IKE negotiation local address is used as the local identity. Note that for an identity of type DN, the value is derived from the certificate, while for other identity types the value must be configured.
Table 5-11 shows the local IKEv2 Identity types supported in IKEv2 profile and their values.
The following example shows how to configure a local IKEv2 identity in an IKEv2 profile and display the identities used in an IKEv2 negotiation.
Router(config-ikev2-profile)#identity local address ?
A.B.C.D IPv4 address
X:X:X:X::X IPv6 address
Router(config-ikev2-profile)#identity local dn ?
<cr>
Router(config-ikev2-profile)#identity local email ?
WORD email <user@domain>
Router(config-ikev2-profile)#identity local fqdn ?
WORD FQDN <host.domain>
Router(config-ikev2-profile)#identity local key-id ?
WORD key-id string
The IKE identities used by a initiator and responder in an IKEv2 SA can be seen in the highlighted portion of the output from show crypto ikev2 sa detailed and show crypto ikev2 session detailed.
Router#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 192.168.1.1/500 192.168.1.2/500 none/none
READY
Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:5, Auth sign:
PSK, Auth verify: PSK
Life/Active Time: 86400/13 sec
CE id: 1040, Session-id: 44
Status Description: Negotiation done
Local spi: 1935BB7ED97A8119 Remote spi: 4EB9F7349F07B7A4
Local id: 192.168.1.1
Remote id: 192.168.1.2
The identities exchanged between peers during the negotiation can be seen in the debug crypto ikev2 logs.
On the initiator:
IKEv2:(SESSION ID = 3077,SA ID = 1):Constructing IDi payload: '192.168.1.1' of
type 'IPv4 address'
IKEv2:(SESSION ID = 3077,SA ID = 1):Searching policy based on peer's identity
'192.168.1.2' of type 'IPv4 address'
On the responder:
IKEv2:(SESSION ID = 1174,SA ID = 1):Searching policy based on peer's identity
'192.168.1.1' of type 'IPv4 address'
IKEv2:(SESSION ID = 1174,SA ID = 1):Constructing IDr payload: '192.168.1.2' of
type 'IPv4 address'
A local identity of type DN must be used only when the device is configured to authenticate itself using a certificate (that is, the local authentication method is certificate based) and a certificate is available. If not, the following error log is displayed when debug crypto ikev2 is enabled, and the negotiation is aborted.
IKEv2-ERROR:(SESSION ID = 3077,SA ID = 1):: Detected an unsupported ID type
IKEv2:(SESSION ID = 3077,SA ID = 1):Auth exchange failed
IKEv2:(SESSION ID = 3077,SA ID = 1):Abort exchange
IKEv2:(SESSION ID = 3077,SA ID = 1):Deleting SA
Defining Local and Remote Authentication Methods
Unlike IKEv1, IKEv2 does not negotiate the authentication method between peers and uses unidirectional authentication, which means the method used by a device to authenticate to its peer is independent of the method used by the peer to authenticate to the device.
The IKEv2 profile defines local and remote authentication methods to support IKEv2 unidirectional authentication. The local authentication method is used by the device to authenticate to its peers, and the remote authentication method is used by the device to authenticate or validate the peers. While the local and remote authentication methods are independent in general, when the local authentication method is EAP based, the remote authentication method must be certificate-based and vice versa. Note that the local authentication method configured on a device must be configured as a remote authentication method on the peer and vice versa.
Only one local authentication method can be configured, while multiple remote authentication methods can be configured; this allows an IKEv2 profile to serve peers authenticating using different methods.
The authentication method used by a device is denoted in the authentication payload in the IKE_AUTH exchange; this allows the peer to select the appropriate method to validate the device. The following packet capture shows the authentication method in the authentication payload.
Type Payload: Authentication (39)
Next payload: Security Association (33)
0... .... = Critical Bit: Not Critical
Payload length: 28
Authentication Method: Shared Key Message Integrity Code (2)
Authentication Data: 27c5615a79ba2abe1c0077507770d624c3f8e246
The following local and remote authentication methods are supported.
Router(config-ikev2-profile)#authentication local ?
eap Extended Authentication Protocol
ecdsa-sig ECDSA Signature
pre-share Pre-Shared Key
rsa-sig Rivest-Shamir-Adleman Signature
Router(config-ikev2-profile)#authentication remote ?
anyconnect-eap AnyConnect EAP
eap Extended Authentication Protocol
ecdsa-sig ECDSA Signature
pre-share Pre-Shared Key
rsa-sig Rivest-Shamir-Adleman Signature
Note
The EAP and AnyConnect-EAP authentication methods are mainly used with FlexVPN Client and Server respectively; hence they are described in the respective chapters for those features. Unlike pre-shared key and certificate-based authentication methods that are used for device authentication, the EAP method is used for user authentication and is mainly used with FlexVPN client (Remote Access Client). It is in chapter 10, “FlexVPN Client.” The AnyConnect-EAP method is Cisco proprietary. The AnyConnect client-specific method that is supported by FlexVPN Server is described in chapter 9, “FlexVPN Server.”
Pre-Shared Key Authentication
When the pre-shared key method is used for local or remote authentication, the pre-shared keys can be configured in the IKEv2 profile and/or in a local or remote (RADIUS-based) keyring with the former taking precedence.
Below is an example of pre-shared key authentication with keys directly configured in the profile as part of the authentication command. Note that the keys configured in the profile take precedence and any keyring configuration in the profile is ignored. A limitation of this approach is that all peers matching this profile must use the same local and remote key, while with local or RADIUS-based keyring, the keys can be per peer. This is useful is simple deployments that use the same pre-shared key for all the peers associated with an IKEv2 profile.
crypto ikev2 profile ikev2_profile
authentication local pre-share key key1
authentication remote pre-share key key2
The following example shows configuring pre-shared key authentication with keys configured in a local keyring that is referenced from the profile. Note that keys can be configured on a per-peer or peer-group basis.
crypto ikev2 keyring ikev2_keyring
peer peer1
address 192.168.2.1 255.255.255.255
pre-shared-key local key1 remote key2
peer peer2
address 192.168.3.0 255.255.255.0
pre-shared-key local key3 remote key4
crypto ikev2 profile ikev2_profile
keyring local ikev2_keyring
Note
RADIUS-based pre-shared keys are mainly used by FlexVPN Server for scalable and centralized management of pre-shared keys; they are described in the FlexVPN Server chapter
Certificate-Based Authentication
Certificate-based authentication is generally considered cryptographically more secure and scalable than the pre-shared key method. It uses a Public Key Infrastructure (PKI) to manage the issuing of certificates, revocation of certificates, protection of key material, and security policy. With this method, a device proves its identity by signing a known blob of data using its private key, and the peer verifies the same using the corresponding public key conveyed in the certificate. The authentication data and the certificate are carried in the authentication (AUTH) and certificate (CERT) payloads in IKE_AUTH exchange, and the peer indicates the certificate authorities that are acceptable in the CERTREQ payload as shown below.
Initiator Responder
--------- ---------
IKE_SA_INIT Request:
HDR, SAi1, KEi, Ni -->
IKE_SA_INIT Response:
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
IKE_AUTH Request:
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr} -->
IKE_AUTH Response:
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
The PKI trustpoint configuration specifies the CA server and related parameters for certificate enrollment and validation. Note that the term trustpoint implies the corresponding CA server in the description below.
When a certificate-based method (RSA-SIG or ECDSA-SIG) is used for local or remote authentication, a PKI trustpoint must be configured and referenced from the IKEv2 profile. Note that only the trustpoints configured in the IKEv2 profile are used for signing and validation and must be configured.
If a certificate-based method is used for remote authentication, a PKI trustpoint must be configured, and the CA certificate must be obtained from the CA server in order to validate the peer certificate. If the certificate method is used for local authentication, then in addition to the PKI trustpoint configuration and obtaining the CA server certificate, an RSA/EC key pair must be generated, and the device certificate must be obtained from the CA server. Please refer to the “Configuring PKI in Cisco IOS” section of this chapter for a detailed description of CA Server and PKI trustpoint configuration, generation of the PKI key pair, and ways of obtaining CA server and device certificates.
Up to six trustpoints can be configured in an IKEv2 profile that can be used for signing or validation or both. Note that a trustpoint configured without the sign or verify keyword can be used for both signing and verification.
Router(config-ikev2-profile)#pki trustpoint ca_server1 ?
sign Set trustpoint for sign
verify Set trustpoint for verify
<cr>
Table 5-12 summarizes the trustpoint (TP) selection for sending a certificate request (CERTREQ) and certificate (CERT) payloads and for certificate validation on the initiator and responder.
The following example shows how to configure certificate authentication and a PKI trustpoint.
crypto pki trustpoint ca_server1
enrollment url http://192.168.1.4:80
subject-name cn=Router
revocation-check crl
crypto ikev2 profile ikev2_profile
match identity remote any
authentication local rsa-sig
authentication remote rsa-sig
pki trustpoint ca_server1
IKEv2 Dead Peer Detection
Dead Peer Detection (DPD) is a mechanism whereby a device will send a liveness check to its IKEv2 peer to check that the peer is functioning correctly. These checks are sent from each peer as an empty INFORMATIONAL exchange, which the corresponding receiving peer receives and retransmits back to the initiating peer. The peer that initiated the liveness check can validate the returned packet by noting the message ID.
If a device sends a liveness check to its peer and fails to receive a response, then the device will go into an aggressive retransmit mode, in which it will transmit five DPD messages at a configured interval. If these transmitted DPD exchanges are not acknowledged, then the peer device will be marked as dead, and the IKEv2 SA and the child IPsec Security Associations will be torn down. The following example shows how to configure Dead Peer Detection (DPD) in an IKEv2 profile.
Router(config-ikev2-profile)#dpd ?
<10-3600> DPD R-U-THERE interval
Router(config-ikev2-profile)#dpd 10 ?
<2-60> DPD Retry Interval
Router(config-ikev2-profile)#dpd 10 2 ?
on-demand Send DPD queries only as needed
periodic Send DPD queries at regular intervals
Note that DPD can also be configured globally in the router configuration mode. The IKEv2 profile DPD configuration overrides the global DPD configuration for the peers or IKEv2 sessions associated with that profile.
Periodic DPD forces DPD messages to be sent at regular intervals. A message is sent at every configured time interval, irrespective of any traffic received on the IPsec Security Association relating to the IKEv2 SA.
On-demand mode will monitor received traffic on the IPsec Security Association that was built from the IKEv2 SA only when needed, that is, before sending any outbound traffic on the IPsec Security Association. If no received traffic is seen on this IPsec Security Association for the configured period, the host will send a DPD message to its peer to ascertain if it is alive. If a response is not received, the device will go into an aggressive mode and retransmit DPD messages every interval. If any replies to the DPD messages are received or if traffic is seen on the corresponding IPsec Security Associations, it will exit from the aggressive mode; however, if no replies are received after five aggressive attempts, the IKEv2 SA and the child IPsec Security Associations will be torn down.
Periodic mode can result in earlier detection of dead peers than on-demand mode. For example, if a peer lost connectivity and a DPD message was sent by the router just after this occurred, after no reply to the DPD message the aggressive mode would be enabled. However, with on-demand mode the DPD messages would be sent only if there is any outbound traffic to be sent and no traffic has been received for the configured duration, and in the absence of outbound traffic, on-demand DPD may not detect if the peer is dead. When on-demand mode is used, if an IKEv2 SA has more than just a single pair of IPsec Security Associations, traffic received on any of the IPsec Security Associations will disable the sending of DPD messages.
When hub and spoke networks are designed in which many spoke devices will connect to a VPN headend, care should be taken if DPD messages are enabled that originate from the hub to the spokes. DPD messages consume CPU cycles, and should a large number of spokes suddenly lose connectivity to the hub, then the hub CPU could become hogged in generating a large amount of DPD packets. It is advised that for large hub and spoke topologies only the spoke should have DPD enabled, and should connectivity fail between the hub and the spoke, then the spoke will transition into the aggressive retransmit state to detect failed connectivity and tear down the IKEv2 and child SAs. When connectivity is restored between the spoke and the hub, the newly created IKEv2 Security Association on the hub will tear the old security association down due to INITIAL_CONTACT.
There is one caveat with not enabling DPD messages on hub devices. Should connectivity be lost, then the hub will continue to send encrypted traffic to a spoke that will not receive the data until the spoke establishes a new IKEv2 SA or until a rekey occurs and is unsuccessful, resulting in the deletion of the SA.
IKEv2 Initial Contact
Should an IKEv2 device crash or be reloaded and DPD is not enabled on the peer device, then the IKEv2 SA and all corresponding IPsec Security Associations would become stale and eventually time out. When the crashed device initiates a new IKEv2 session, it would use the same IKEv2 identity, so the peer with the stale IKEv2 SA would realize then that this is a duplicate session and delete the old stale session. The behavior to check the identity of previously created IKEv2 sessions and delete any existing sessions is enabled when a peer sends an INITIAL_CONTACT notification payload within the IKE_AUTH exchange. This will ensure that any previously created sessions are deleted.
This behavior is enabled by default on Cisco IOS; however, should an IKEv2 implementation initiate an IKEv2 session that does not contain the INITIAL_CONTACT notification payload, then the initial contact processing based on identity and 5 tuple session information for any existing stale IKEv2 session with that peer can be forced by using the following command in IKEv2 profile.
crypto ikev2 profile ikev2_profile
initial-contact force
IKEv2 SA Lifetime
IKEv2 SAs use secret keys that should be used only for a limited amount of time. This limits the lifetime of the entire SA. When the lifetime of an SA expires, the SA must not be used and must be replaced with new SAs that use new keys. In IKEv2, the SA lifetime is not negotiated, and each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. This allows better control over which side initiates the rekey and is useful in spoke-hub topologies, where the spokes can be configured with a lower lifetime and made to initiate the rekeys instead of the hub. The peer with the shorter lifetime will always end up being the one to request the rekeying. Cisco IOS uses a default IKEv2 SA lifetime of 24 hours, which can be overridden on each IKEv2 profile with the lifetime lifetime_duration command, where the lifetime can be configured between 120 and 86,400 seconds.
NAT Keepalives
NAT detection and NAT traversal is built into the IKEv2 protocol. When the use of NAT is detected, as part of NAT traversal, IKEv2 moves from UDP port from 500 to 4500. Additionally, IKEv2 programs the child IPsec ESP SAs to use UDP encapsulation, the peer’s post-NAT IP address and UDP port number, and the frequency at which the NAT keepalives must be sent to keep the NAT translation entries alive on the NAT device. Please refer to RFC 3948 (UDP Encapsulation of IPsec ESP Packets) for a description of the NAT keepalive packet format and procedure. The following example shows how to configure the NAT keepalive frequency in the IKEv2 profile.
Router(config-ikev2-profile)#nat ?
keepalive NAT keepalive interval
Router(config-ikev2-profile)#nat keepalive ?
<5-3600> NAT keepalive interval in seconds
Note that NAT keepalive frequency can also be configured globally in the router configuration mode with crypto ikev2 nat keepalive command and, as always, the IKEv2 profile configuration overrides the global configuration for the peers or IKEv2 sessions associated with that profile.
IVRF (inside VRF)
As described earlier in chapter 4, “IOS IPsec implementation,” VRF is a Cisco IOS layer-3 device virtualization technique used to segregate layer-3 forwarding domains. IOS uses two types of VRFs: IVRF (inside) and FVRF (front-door VRF). In IOS, IVRF is used for segregation of overlay domains to support multi-tenancy, and FVRF is used for segregation of underlay domains (WAN transports/providers). As IPsec deals with both overlay (plaintext) and underlay (encrypted) traffic, IPsec Security Associations use both IVRF and FVRF. With tunnel protection, IPsec Security Associations derive FVRF and IVRF from the tunnel interface, which can be configured with both VRFs. With crypto maps, IPsec Security Associations derive FVRF from the crypto map interface and IVRF from the IKEv2 profile used by the SAs as crypto map interfaces, which are typically non-tunnel interfaces can be configured only with a single VRF. The following example shows configuring VRF in the IKEv2 profile.
The IVRF can be configured in IKEv2 profile with the ivrf command, as shown below:
Router(config-ikev2-profile)#ivrf ?
WORD VRF Name
Note that IVRF configuration in IKEv2 profile is meant to be used only with crypto maps and must not be used with tunnel protection.
Virtual Template Interface
The IPsec dVTI is a dynamically instantiated virtual access interface of type tunnel that is used on IPsec VPN headends such as FlexVPN server. A dVTI is created for every incoming IKE and IPsec session, and the configuration for a dVTI is primarily cloned from a virtual template interface of type tunnel and optionally from AAA. The virtual template used for an incoming session is derived from the IKEv2 profile associated with that session. For a dVTI, a virtual template must be configured in an IKEv2 profile, without which the virtual access interface is not created. The following example shows configuring a virtual template and referencing it from an IKEv2 profile.
Router(config-ikev2-profile)#?
virtual-template Specify the virtual-template for dynamic interface
creation.
Router(config-ikev2-profile)#virtual-template ?
<1-200> Virtual-template number
interface Virtual-Template1 type tunnel
ip unnumbered Ethernet0/0
tunnel source Ethernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile ipsec_profile
crypto ikev2 profile ikev2_profile
virtual-template 1
Disabling IKEv2 Profile
It is recommended that an IKEv2 profile be disabled when it is being configured or modified; this prevents an incomplete profile from being used, which would cause undesired results. A profile can be disabled with the shutdown command.
Router(config-ikev2-profile)#shutdown ?
<cr>
Displaying IKEv2 Profiles
The configured IKEv2 profiles can be displayed with the following command. The output also displays default values used in the IKEv2 profile:
Router#show crypto ikev2 profile
IKEv2 profile: default
Ref Count: 5
Match criteria:
Fvrf: global
Local address/interface: none
Identities: any
Certificate maps: none
Local identity: none
Remote identity: none
Local authentication method: pre-share
Remote authentication method(s): pre-share
EAP options: none
Keyring: ikev2_keyring
Trustpoint(s): none
Lifetime: 86400 seconds
DPD: disabled
NAT-keepalive: disabled
Ivrf: none
Virtual-template: none
mode auto: none
AAA AnyConnect EAP authentication mlist: none
AAA EAP authentication mlist: none
AAA Accounting: none
AAA group authorization: none
AAA user authorization: none
IKEv2 Profile Selection on Initiator and Responder
On the initiator, the IKEv2 profile used for the outbound negotiation is the one that is attached to the IPsec interface (for example, the tunnel interface with tunnel protection applied on it) that initiated the IPsec Security Association request. The profile is later validated against the peer certificate or identity received in the IKE_AUTH response, and if there is a mismatch, the negotiation is aborted.
On the responder, the IKEv2 profile is selected based on the peer certificate or identity received in the IKE_AUTH request, and this profile is later validated against the profile attached to the IPsec interface that accepted the incoming the IPsec session. This check is performed during IPsec proposal validation, and if there is a mismatch the negotiation is aborted.
IKEv2 Profile Key Points
Following is a summary of the key points about IKEv2 profiles.
The IKEv2 profile is a mandatory configuration on the initiator and responder, for it specifies key parameters, such as authentication methods and credentials, without which negotiation cannot start.
The IKEv2 profile must be attached to an IPsec interface on both the initiator and responder that defines the IKE identities the interface can communicate with.
The IKEv2 profile attached to the IPsec interface must match the profile selected during the negotiation based on peer certificate or identity. If not, the negotiation is aborted.
The IKEv2 profile configuration overrides any corresponding global configuration and applies only to peers or sessions that get associated with that profile.
IKEv2 Global Configuration
The IKEv2 global configuration parameters defined in the router configuration mode apply to all the IKEv2 sessions and peers, irrespective of the IKEv2 profile that they associated with.
Table 5-13 lists the IKEv2 parameters that can be configured globally and the functionality that they provide.
Note
IKEv2 fragmentation, CTS, and the session deletion on peer certificate revocation feature are described in chapter 6, “Advanced IKEv2 Features.” The IKEv2 redirect and auto-reconnect features are described in chapter 11, “FlexVPN Load Balancer,” and chapter 9, “FlexVPN Server.”
HTTP URL-based Certificate Lookup
If the IKEv2 messages are long enough that IP-level fragmentation is necessary, it is possible that malicious users could prevent the exchange from completing by exhausting the reassembly buffers. The chances of this can be minimized by using the Hash and URL encoding instead of sending certificates where the peer would fetch the certificate using http from the specified URL.
The HTTP_CERT_LOOKUP_SUPPORTED notification as part of the CERTREQ payload indicates that the sender is capable of looking up certificates based on an HTTP-based URL and would prefer to receive certificate specifications in that format. If the peer supports that feature, the certificate payload includes a hash and URL of the certificate instead of the certificate. The following example shows how to enable HTTP URL-based certificate lookup.
Router(config)#crypto ikev2 http-url ?
cert Enable certificate lookup based on HTTP-based URL
The caching of certificates fetched from HTTP URL for future use is enabled with the following command:
Router(config)#crypto ikev2 ?
certificate-cache Cache for storing certs fetched from HTTP URLs
Router(config)#crypto ikev2 certificate-cache ?
<1-2000> Maximum number of certificates stored in certificate cache
IKEv2 Cookie Challenge
IKEv2 Cookie Challenge is used to mitigate against a possible DoS attack on an IKEv2 responder that results from a flood of session initiation requests from forged IP addresses. The mitigation involves using minimal CPU and state resources until the responder confirms that the initiator can receive packets at the address from which it claims to be sending them. When a responder detects a large number of half-open IKE SAs, it replies to IKE_SA_INIT requests with a response containing the COOKIE notification with a stateless cookie, and only when the initiator reflects the cookie back does it proceed with the negotiation. The following example shows configuring the threshold for the number of half open IKEv2 session requests, after which cookie challenge is enabled.
Router(config)#crypto ikev2 ?
cookie-challenge Set Cookie-challenge watermark
Router(config)#crypto ikev2 cookie-challenge ?
<0-1000> Maximum number of in-negotiation SAs that enable Cookie-challenge
IKEv2 Call Admission Control
IKEv2 Call Admission Control (CAC) limits the maximum number of IKEv2 SAs that can be established by a device based on the platform limitations, such as crypto engine or CPU limitations. CAC also limits the number of simultaneous negotiations, depending on the device capabilities, to avoid thrashing because setting up a new IKEv2 session is resource intensive. The limits will vary depending on the platform, and tuning the limits based on testing will yield the optimal performance and session setup rate. At the time of this writing, the default IKEv2 CAC values are 40 for incoming sessions and 400 for outgoing sessions.
The following example shows how to configure the CAC limits.
Router(config)#crypto ikev2 ?
limit Limit the number of maximum and negotiating sa
Router(config)#crypto ikev2 limit ?
max-in-negotation-sa Limit the maximum number of negotiating SA
max-sa Limit the maximum number of SA allowed
Router(config)#crypto ikev2 limit max-sa ?
<1-9999> Set the limit
Router(config)#crypto ikev2 limit max-in-negotation-sa ?
<1-9999> Set the limit
Router(config)#crypto ikev2 limit max-in-negotation-sa 100 ?
incoming Limit the maximum number of incoming negotiating SA
outgoing Limit the maximum number of outgoing negotiating SA
<cr>
The IKEv2 call admission statistics can be seen with the show crypto ikev2 stats command:
Router#show crypto ikev2 stats
--------------------------------------------------------------------------------
Crypto IKEv2 SA Statistics
--------------------------------------------------------------------------------
System Resource Limit: 0 Max IKEv2 SAs: 0 Max in nego(in/out):
100/400
Total incoming IKEv2 SA Count: 0 active: 0 negotiating: 0
Total outgoing IKEv2 SA Count: 1 active: 1 negotiating: 0
Incoming IKEv2 Requests: 0 accepted: 0 rejected: 0
Outgoing IKEv2 Requests: 3 accepted: 3 rejected: 0
Rejected IKEv2 Requests: 0 rsrc low: 0 SA limit: 0
IKEv2 packets dropped at dispatch: 0
Incoming IKEV2 Cookie Challenged Requests: 0
accepted: 0 rejected: 0 rejected no cookie: 0
Total Deleted sessions of Cert Revoked Peers: 0
IKEv2 Window Size
Each IKEv2 header contains a message identifier, which is a sequential number beginning at 0, for every exchange this value is incremented by one for every pair of exchanged packets. Having a message number within the header allows each packet exchange to be tracked and prevents replay attacks.
All IKEv2 exchanges are in pairs, in which a sent packet will always be acknowledged by the receiver. The number of pairs of messages that can be inflight at any time is exchanged by using the SET_WINDOW_SIZE notification payload within the IKE_SA_INIT exchange. This value denotes the IKEv2 window size, and by default Cisco IOS sets the window size to 5, which allows up to five IKEv2 exchanges to be sent before an acknowledgement is received. There are very few cases in which more than five packets will be inflight at any given time. If dead peer detection is enabled and INFORMATIONAL exchanges occur around the same time that a rekey occurs, then two or three packet exchanges could be occurring at the same time, but the default window size of 5 should be ample for this scenario.
On IOS the SET_WINDOW_SIZE notification payload is sent in the IKE_AUTH exchange; once the IKEv2 Window Size has been set it cannot be reduced but can only grow in size.
Type Payload: Notify (41)
Next payload: Notify (41)
0... .... = Critical Bit: Not Critical
Payload length: 12
Protocol ID: IKE (1)
SPI Size: 0
Notify Message Type: SET_WINDOW_SIZE (16385)
Notification DATA: 00000005
IKEv2 window size can be configured globally using the following
command:Router(config)#crypto ikev2 window ?
<1-200> Maximum number of overlapping requests with a peer
Dead Peer Detection
Please refer to the IKEv2 profile section for a detailed description of Dead Peer Detection (DPD). The DPD method and intervals can be configured globally with the following command:
Router(config)#crypto ikev2 dpd ?
<10-3600> DPD R-U-THERE interval
Router(config)#crypto ikev2 dpd 10 ?
<2-60> DPD Retry Interval
Router(config)#crypto ikev2 dpd 10 2 ?
on-demand Send DPD queries only as needed
periodic Send DPD queries at regular intervals
NAT Keepalive
Please refer to the IKEv2 profile section for a detailed description of NAT keepalives. NAT keepalives can be configured globally with the following command:
Router(config)#crypto ikev2 nat keepalive ?
<5-3600> Number of seconds between NAT keepalive
IKEv2 Diagnostics
IKEv2 diagnostics maintains a database of exit paths and a count of different error types. The exit path captures the exit points from the normal code paths caused by errors, and the accompanying tracebacks help determine the exact location of the error, because the same error message can be generated from multiple places in the code.
IKEv2 diagnostics can be enabled with the following command:
Router(config)#crypto ikev2 diagnose error ?
<1-1000> Maximum number of exit path entry
The exit path database and the error counts can be displayed with the following command:
Router#show crypto ikev2 diagnose ?
error Shows error trace database
Router#show crypto ikev2 diagnose error ?
count Shows ikev2 errors counts - only non-zero
| Output modifiers
<cr>
Router#show crypto ikev2 diagnose error count ?
detailed Shows ikev2 errors counts - all
| Output modifiers
<cr>
PKI Configuration
Public Key Infrastructure (PKI) is a very large and complicated topic; indeed, a whole book could easily be written to describe how PKI can be implemented on Cisco IOS. The following title by Cisco Press is that book and should be read for an in-depth study of PKI: PKI Uncovered: Certificate-Based Security Solutions for Next-Generation Networks.
Within this section we cover the core components of PKI and then use an example to illustrate the component in action.
A number of components are found within a PKI. On Cisco IOS, the relevant ones are the certificate authority, public-private key pair, and certificate.
Certificate Authority
A Certificate Authority (CA) manages certificate requests and issues certificates to devices participating within the PKI. These services (managing certificate requests and issuing certificates) provide centralized key management for the participating devices and are explicitly trusted by the receiver to validate identities and to create digital certificates.
Cisco IOS can operate as a CA using a Rivest-Shamir-Adleman (RSA) key pair. This can be very useful in case a single IPsec Security Association is required to be established between a pair of routers and a fully blown PKI is not required. One of the routers can act as a CA and the other router can enroll into this. The following command can be used to configure a Cisco IOS router as a CA.
crypto pki server cs-label
where cs-label is the name of the CA server.
After configuring the CA function, a submenu will be presented in which additional configuration options can be applied to specific attributes pertaining to the CA. The following examples shows CA server configuration.
Router(config)#crypto pki server CA
Router(cs-server)#?
CA Server configuration commands:
auto-rollover Rollover the CA key and certificate
cdp-url CRL Distribution Point to be included in the issued certs
crl server crl
database Certificate Server database config parameters
default Set a command to its defaults
eku Configure EKU parameters
exit Exit from Certificate Server entry mode
grant Certificate granting options
hash Hash algorithm
issuer-name Issuer name
lifetime Lifetime parameters
mode Mode
no Negate a command or set its defaults
redundancy sync this server to the standby
serial-number Serial Number of Last Certificate Issued
show Show this certificate server configuration
shutdown Shutdown the Certificate Server
To activate the CA service, issue the no shutdown command within the CA server. The CA server will become active when the HTTP service is enabled locally. The following example illustrates a method to determine if the CA server is disabled due to the HTPP service not being enabled.
Router#show crypto pki server
Certificate Server CA:
Status: disabled, HTTP Server is disabled
Enter the ip http server global command to activate the HTTP service. Access to the HTTP service should be restricted by using the ip http access-class access-list-number global command.
A password is required, which is used to protect the private key that is used by the CA service.
Router(config)#crypto pki server CA
Router(cs-server)#no shut
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password:
Re-enter password:
% Generating 1024 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 0 seconds)
When the CA is created, an RSA key pair will be generated if one is not defined. This will be a default 1024-bit RSA key pair. For maximum security, a stronger key pair should be used, which is described in the following section.
The following output illustrates the expected behavior once the CA service is enabled.
%PKI-6-CS_ENABLED: Certificate server now enabled.
Router#show crypto pki server
Certificate Server CA:
Status: enabled
State: enabled
....
Accurate time is crucial when designing the architecture of a Certificate Authority; for this reason, Network Time Protocol (NTP) should always be used to ensure accurate time when a PKI is used.
The example above is a simplified PKI deployment. In cases where a subordinate CA is used, multiple trustpoints would be required if full chain validation is needed.
Public-Private Key Pair
A key pair consists of a public key and a private key. The two keys in the key pair have a cryptographic relationship with each other, so that what can be done with one can be undone with the other and vice versa. When a PKI is set up, the public key is required in the certificate enrollment request. Once the certificate has been granted, the public key will be included in the certificate. In the context of IKEv2, the public key is used to verify that the peer is in possession of the private key.
Note
Prior to generating the default RSA key pair the router hostname and domain-name must be set. This requirement does not exist for named key pairs.
To generate a key pair, use the crypto key generate command. This command can generate either a Rivest-Shamir-Adleman (RSA) or Elliptic Curve (EC) key pair. EC keys pairs are smaller and offer greater security for less work than RSA; however, they have only recently been introduced and many third-party devices do not support EC key pairs. The following example shows EC key pair generation.
crypto key generate ec keysize { 256 | 384 } [ exportable ] [ label key-label ]
The following global command is used to generate an RSA key pair.
crypto key generate rsa [ general-keys | usage-keys | signature | encryption ]
[ label key-label ] [exportable] [ modulus modulus-size ] [ storage devicename : ]
[redundancy] [ on devicename : ]
A Cisco IOS router can be enrolled into a PKI. Before enrollment, a public-private key pair must be available on the router. The generation of the public-private key pair can be performed locally with the crypto key generate command, or the key pair can be imported.
The following command illustrates how an EC key pair can be imported.
crypto key import ec key-label [ exportable ] { terminal | url url } passphrase
The following command illustrates how a RSA key pair can be imported.
crypto key import rsa key-label pem [ usage-keys | signature | encryption |
general-purpose ] { storage | terminal [passphrase] | url url } [exportable]
[ on devicename : ]
A public-private key pair can be removed with the following commands:
crypto key zeroize ec [key-pair-label]
crypto key zeroize rsa [key-pair-label]
PKI Trustpoint
A PKI trustpoint is a container for information pertaining to a certificate authority. The trustpoint will contain the certificate of the CA in question, along with attributes that are used by the local device when generating a Certificate Signing Request (CSR).
The sending of the CSR to the CA can be performed by a manual process (copy and paste) which uses the enrollment terminal command from within the trustpoint. Simple Certificate Enrolment Protocol (SCEP) is an HTTP-based method to enroll clients to a CA with RSA certificates. SCEP can be enabled with the enrollment url scep-url command, where url is the URL of the CA to which the router should send certificate requests.
If EC certificates are used, Enrollment over Secure Transport (EST) can be used to enroll next-generation encryption certificates over SSL or TLS. EST is described with RFC 7030. To configure enrollment using EST, a PKI profile is required and created with the command crypto pki profile enrollment pki_profile. Within this profile, the command method-est is used to enable enrolment using EST. The trustpoint that is configured to use EST must be defined using the command enrollment credential trustpoint_label. The enrollment URL must be defined using the command enrollment url url.
The public-private key pair that is used for the CSR can be defined within the trustpoint. To configure an EC key pair, the eckeypair name command is used. To configure a RSA key pair the rsakeypair key-label [[ key-size encryption-key-size ]] command is used. The key-size argument is used for generating the key, and the encryption-key-size argument specifies that the system is to request separate encryption, signature keys, and certificates. The key-size and encryption-key-size values must be the same size. For RSA, a length of less than 2048 is not recommended.
To specify the cryptographic hash algorithm function for the signature that the routers uses for the CSR, the hash hash_type command is used. Table 5-14 lists the available hash algorithms and their cryptographic strength.
The certificate revocation method is performed to ensure that the certificate has not been revoked by the issuing CA. Cisco IOS software supports two revocation mechanisms: Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP). A CRL is a list of revoked certificates. The CRL is created and digitally signed by the CA that originally issued the certificates. The CRL contains the serial number, date and revocation reason for each certificate that was revoked.
CAs publish new CRLs periodically or when a certificate for which the CA is responsible has been revoked. By default, a new CRL is downloaded after the currently cached CRL expires. An administrator may also configure the duration for which CRLs are cached in router memory or disable CRL caching completely. The CRL caching configuration applies to all CRLs associated with a trustpoint.
The ability to check if a peer’s certificate has been revoked is achieved using the revocation-check method command.
A number of other attributes can be configured within the trustpoint, where the revocation method can be one or more of the following (please consult cisco.com for more information):
crl—Certificate checking is performed by a certificate revocation list (CRL). This is the default behavior.
none—Certificate checking is not required.
ocsp—Certificate checking is performed by an online certificate status protocol (OCSP) server.
Once a trustpoint has been configured, the CA certificate must be obtained. This is achieved by authenticating the CA with the global command crypto pki authenticate name, where name is the name of the trustpoint. The process to obtain the CA certificate is achieved by cut and paste when enrollment is set to terminal, or by SCEP when an enrollment URL is defined.
The fingerprint of the CA certificate is its MD5 and SHA1 hash and can be used to verify that it was indeed the genuine CA certificate that was received.
Once the CA certificate is obtained, the router can be enrolled into the PKI with the global command crypto pki enroll name, where name is the name of the trustpoint.
In the enrollment process, a CSR that is populated with the details defined within the trustpoint is sent to the CA; the CA will cryptographically sign the hash of this CSR and return it to the client. This is the client’s certificate.
PKI Example
The following example illustrates a router being configured to act as a Certificate Authority.
The host name and domain name are first set, then an RSA keypair used by the CA is generated. The CA will be configured to automatically generate certificates. For security purposes this should not be configured.
Router(config)#hostname CA
CA(config)#ip domain-name cisco.com
CA(config)#crypto key generate rsa general-keys modulus 2048 label CA
The name for the keys will be: CA
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 1 seconds)
CA(config)#crypto pki trustpoint CA
CA(ca-trustpoint)#rsakeypair CA
CA(ca-trustpoint)#exit
CA(config)#crypto pki server CA
CA(cs-server)#grant auto
%PKI-6-CS_GRANT_AUTO: All enrollment requests will be automatically granted.
CA(cs-server)#no shutdown
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password:
Re-enter password:
% Certificate Server enabled.
CA(cs-server)#
%PKI-6-CS_ENABLED: Certificate server now enabled.
CA#show crypto pki server
Certificate Server CA:
Status: enabled
State: enabled
Server's configuration is locked (enter "shut" to unlock it)
Issuer name: CN=CA
CA cert fingerprint: 1CB1376E 48B40FFC 8C68A493 D744A83A
Granting mode is: auto
The following illustrates PKI trustpoint configuration, the IP address of the CA is 192.168.1.3
Router(config)#crypto pki trustpoint PKI
Router(ca-trustpoint)#enrollment url http://192.168.1.3
Router(ca-trustpoint)#exit
Router(config)#crypto pki authenticate PKI
Certificate has the following attributes:
Fingerprint MD5: 1CB1376E 48B40FFC 8C68A493 D744A83A
Fingerprint SHA1: 805741B2 A094DFC3 CAFF1D7D 819EA99F B9C7879E
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
Router(config)#crypto pki enroll PKI
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Password:
Re-enter password:
% The subject name in the certificate will include: CA.cisco.com
% Include the router serial number in the subject name? [yes/no]:
no
% Include an IP address in the subject name? [no]:
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose PKI' command will show the fingerprint.
Router(config)#
CRYPTO_PKI: Certificate Request Fingerprint MD5: 552781FF 2584FBB1 9E014F06
51BCB61D
CRYPTO_PKI: Certificate Request Fingerprint SHA1: 70190AD2 B255D1A9 03E942F8
A5F97C1F 5078E579
Router(config)#
%PKI-6-CERTRET: Certificate received from Certificate Authority
IPsec Configuration
This section describes the Cisco IOS IPsec configuration required to setup an IPsec session to or from a Cisco IOS router.
Cisco IOS IPsec implementation is interface-centric, which means that IPsec configuration, Security Policy Database (SPD), and Security Association Database (SAD) are per-interface. The term “IPsec interface” used in this book implies an interface with IPsec enabled on it by either the legacy crypto map or the newer tunnel protection method. Tunnel protection is a new way of configuring IPsec on Cisco IOS tunnel interfaces and is used with most of the Cisco IOS IPsec VPNs, such as FlexVPN and DMVPN. Therefore, this section will explain configuring IPsec using tunnel protection.
Any IPsec configuration should specify three key pieces of information:
What traffic to protect (that is, the traffic selectors).
How to protect that traffic (that is, the IPsec parameters to use, such as the IPsec protocol, mode, algorithms, SA lifetime, and others).
Whom to protect the traffic with (that is, the peer).
With tunnel protection, the IPsec parameters are derived from the IPsec profile attached to the tunnel interface using the tunnel protection command, and the traffic selector and peer information is derived from the tunnel interface configuration as described below:
The IKE/IPsec Security Association local address is derived from the tunnel source ip-address command on the tunnel interface.
The IKE/IPsec Security Association peer address is derived from the tunnel destination ip-address command on the tunnel interface for point-to-point tunnel interfaces such as GRE (tunnel mode gre) or IPsec VTI (tunnel mode ipsec) or is learned dynamically for multipoint tunnel interfaces such as mGRE (tunnel mode gre multipoint).
The SA traffic selectors for GRE interfaces are ip gre host host and for IPsec VTI ip any any.
IPsec Profile
The IPsec profile is the central configuration in IPsec that defines most of the IPsec parameters such as the protocol (Encapsulation Security Payload, Authentication Header), mode (tunnel, transport), algorithms (encryption, integrity, Diffie-Hellman), perfect forward secrecy (PFS), SA lifetime, and key management protocol (IKEv1, IKEv2).
Table 5-15 lists IPsec profile key commands and their usage.
IPsec Configuration Example
The following example shows an IPsec transform-set, IPsec profile, and tunnel protection configuration. The IPsec transform set and IKEv2 profile are referenced from IPsec profile, which is then attached to tunnel interface with the tunnel protection command.
crypto ikev2 profile ikev2_profile
match identity remote any
authentication local pre-share key key1
authentication remote pre-share key key1
crypto ipsec transform-set transform_set esp-aes esp-sha-hmac
mode transport
crypto ipsec profile ipsec_profile
set transform-set transform_set
set ikev2-profile default
interface Tunnel0
ip address 192.168.0.1 255.255.255.0
tunnel source 172.16.1.1
tunnel destination 172.16.2.1
tunnel protection ipsec profile ipsec_profile
Smart Defaults
Smart defaults minimize IKEv2 and IPsec configuration by using default values wherever possible that cater to most of the use cases and can be customized to meet the needs of specific users. Smart defaults consist of the default IKEv2 proposal, default IKEv2 policy, and default IPsec profile. With smart defaults, a user just needs to configure the IKE2 profile specifying the authentication methods and the IKEv2 keyring or PKI trustpoint specifying authentication credentials and then apply the default IPsec profile to a tunnel interface. The following example shows the minimal IKEv2 and IPsec configuration required to create a basic IKEv2 and IPsec session when smart defaults are used.
crypto ikev2 profile default
match identity remote any
authentication local pre-share key key1
authentication remote pre-share key key1
interface Tunnel0
ip address 192.168.0.1 255.255.255.0
tunnel source 172.16.1.1
tunnel destination 172.16.2.1
tunnel protection ipsec profile ipsec_profile
The default IKEv2 proposal, IKEv2 policy, and IPsec profile can be displayed by issuing the following show commands. Note that the default IPsec profile references an IKEv2 profile with name default, as highlighted in the show command output below; hence an IKEv2 profile with the name “default” must be defined.
Router#show crypto ikev2 proposal default
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
Router#show crypto ikev2 policy default
IKEv2 policy : default
Match fvrf : any
Match address local : any
Proposal : default
Router#show crypto ipsec profile default
IPSEC profile default
IKEv2 Profile: default
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): N
Mixed-mode : Disabled
Transform sets={
default: { esp-aes esp-sha-hmac } ,
}
Summary
This chapter introduces the foundational IKEv2 configuration that is needed for any IKE-based VPN, whether it is point-to-point, remote-access or hub-spoke. This chapter provides essential background information for understanding more advanced topics such as IKEv2 advanced features, FlexVPN Client, FlexVPN Server, and IKEv2 load balancing. The key point to remember from this chapter is the concept that the IKEv2 profile is an anchoring point for most of the IKEv2 configurations and features.