This chapter introduces a number of designs where IKEv2 is used. Each design will use a simple deployment of two routers with the focus on the configuration of IKEv2. Although each scenario uses only two routers, the configuration can scale as required if needed.
The configuration is intended to be as simple as possible, and the emphasis is focused on the IKEv2 configuration.
Pre-shared-key Authentication with Smart Defaults
This configuration is the simplest to set up. By using smart defaults, a VPN is created between two peers using minimal configuration: only the IKEv2 profile and corresponding IKEv2 keyring are required.
Figure 7-1 illustrates the topology. The transport network is using IPv6, and the overlay network is using IPv4.
)
Figure 7-1 PSK Authentication with Smart Defaults Topology
The following example illustrates the relevant configuration used on Router1. This is a very minimal configuration which leaves little room for error.
Note that the shared secrets used in the example below are for illustrative purposes and, if used in a production environment, should contain sufficient entropy.
The example might seem complex as this scenario uses IPv4 and IPv6; however, the main focus of interest is to illustrate the IKEv2 configuration and the simplicity of using smart defaults.
An IKEv2 keyring is created with a peer entry which matches the peer’s IPv6 address. Asymmetric pre-shared-keys are used with each device having a unique local and remote key.
crypto ikev2 keyring local_keyring
peer 2001:DB8::2
address 2001:DB8::2/128
pre-shared-key local bartlett
pre-shared-key remote inamdar
The IKEv2 profile is the mandatory component and matches the remote IPv6 address configured on Router2. The local IKEv2 identity is set to the IPv6 address configured on E0/0. The authentication is set to pre-shared-key with the locally configured keyring defined previously.
crypto ikev2 profile default
match identity remote address 2001:DB8::2/128
identity local address 2001:DB8::1
authentication remote pre-share
authentication local pre-share
keyring local local_keyring
The local loopback interface is configured, which will allow testing over the IPsec Security Association.
interface Loopback0
ip address 192.168.10.1 255.255.255.0
The tunnel interface is created as tunnel mode GRE IPv6. This is required as the transport network is IPv6 and the overlay is IPv4. The default IPsec profile is used to protect this interface; this uses the default IKEv2 profile which was configured earlier.
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel source Ethernet0/0
tunnel mode gre ipv6
tunnel destination 2001:DB8::2
tunnel protection ipsec profile default
The physical interface used as the tunnel source uses IPv6.
interface Ethernet0/0
no ip address
ipv6 address 2001:DB8::1/64
Enhanced interior gateway routing protocol (EIGRP) is used to establish a peer relationship over the tunnel interface and distribute the loopback prefix.
router eigrp 1
network 172.16.1.0 0.0.0.3
network 192.168.10.0
The following example illustrates the relevant configuration on Router2.
interface Loopback0
ip address 192.168.20.1 255.255.255.0
interface Tunnel0
ip address 172.16.1.2 255.255.255.252
tunnel source Ethernet0/0
tunnel mode gre ipv6
tunnel destination 2001:DB8::1
tunnel protection ipsec profile default
interface Ethernet0/0
no ip address
ipv6 address 2001:DB8::2/64
router eigrp 1
network 172.16.1.0 0.0.0.3
network 192.168.20.0
The following example illustrates the EIGRP neighbor relationship built over the tunnel interface. The prefix for IP address assigned to the loopback interface on Router2 is reachable via the protected tunnel.
Router1#show ip route 192.168.20.0
Routing entry for 192.168.20.0/24
Known via "eigrp 1", distance 90, metric 27008000, type internal
Redistributing via eigrp 1
Last update from 172.16.1.2 on Tunnel0, 00:12:04 ago
Routing Descriptor Blocks:
* 172.16.1.2, from 172.16.1.2, 00:12:04 ago, via Tunnel0
Route metric is 27008000, traffic share count is 1
Total delay is 55000 microseconds, minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1418 bytes
Loading 1/255, Hops 1
The following example illustrates the IKEv2 SA that is created. The IKEv2 SA is protected by the PRF and integrity algorithms using SHA512, encryption using AES-CBC-256, and Diffie-Hellman group 5, which are the most preferred algorithms within the IKEv2 default proposal. The authentication is performed using pre-shared-key.
Router1#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
IPv6 Crypto IKEv2 SA
Tunnel-id fvrf/ivrf Status
1 none/none READY
Local 2001:DB8::1/500
Remote 2001:DB8::2/500
Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:5, Auth sign:
PSK, Auth verify: PSK
Life/Active Time: 86400/10523 sec
CE id: 1002, Session-id: 2
Status Description: Negotiation done
Local spi: 261B9BD2F208A02A Remote spi: 0B28D2A21FC6304D
Local id: 2001:DB8::1
Remote id: 2001:DB8::2
Local req msg id: 4 Remote req msg id: 4
Local next msg id: 4 Remote next msg id: 4
Local req queued: 4 Remote req queued: 4
Local window: 5 Remote window: 5
...
The following example illustrates traffic being sent over the IPsec Security Association. The tunnel source and destination being the IPv6 addresses configured on the physical E0/0 interfaces.
Traffic is sent via the tunnel interface, from the locally configured loopback interface to the loopback on Router2.
Router1#ping 192.168.20.1 source 192.168.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
The IPsec Security Association is verified where the default IPsec transform set is used, which is created using Encapsulation Security Payload with AES-CBC-256 for encryption and SHA1-HMAC for integrity. Transport mode is used.
Router1#show crypto ipsec sa
interface: Tunnel0
Crypto-map tag: Tunnel0-head-0, local addr 2001:DB8::1
protected vrf: (none)
local ident (addr/mask/prot/port): (2001:DB8::1/128/47/0)
remote ident (addr/mask/prot/port): (2001:DB8::2/128/47/0)
current_peer 2001:DB8::2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 523, #pkts encrypt: 523, #pkts digest: 523
#pkts decaps: 523, #pkts decrypt: 523, #pkts verify: 523
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 2001:DB8::1,
remote crypto endpt.: 2001:DB8::2
plaintext mtu 1462, path mtu 1500, ipv6 mtu 1500, ipv6 mtu idb Ethernet0/0
current outbound spi: 0x5FC3C94A(1606666570)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xB8435B94(3091422100)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 10, flow_id: SW:10, sibling_flags 80000001, crypto-map:
Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4315844/2543)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x5FC3C94A(1606666570)
transform: esp-aes esp-sha-hmac ,
in use settings ={Transport, }
conn id: 9, flow_id: SW:9, sibling_flags 80000001, crypto-map:
Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4315844/2543)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
Elliptic Curve Digital Signature Algorithm Authentication
The scenario looks to use digital signatures to authenticate both peers. Rather than the more common RSA certificates, Elliptic Curve (EC) certificates are used that provide the ability to authenticate both parties, using the Elliptic Curve Digital Signature Algorithm (ECDSA).
The configuration in this example is intended to be simple, with the main focus on the IKEv2 configuration.
Figure 7-2 illustrates the physical IP addressing and the setup of the tunnel interface.
)
Figure 7-2 Topology with Configuration
In addition to ECDSA for authentication, Cisco Next Generation Encryption (NGE) algorithms secure the IKEv2 and IPsec session, as shown in Table 7-1.
Table 7-1 Security Algorithms Used
Method |
Algorithm |
|---|---|
IKEv2 encryption |
AES-GCM-256 |
IKEv2 PRF |
SHA512 |
Diffie-Hellman |
Group 21 |
Authentication |
Elliptic Curve Digital Signature Algorithm |
IPsec encryption |
AES-GCM-256 |
IPsec PFS |
Group 21 |
Rather than using the default IKEv2 proposal, the default IKEv2 proposal is disabled, and a new IKEv2 proposal created containing the IKEv2 algorithms defined in Table 7-1.
Static routes are used to send traffic down the freshly created tunnel interface.
The following example illustrates the configuration that is used on Router1.
The trustpoint is configured using manual enrollment, with the local and CA certificate.
crypto pki trustpoint ecdsa_tp
enrollment terminal
crypto pki certificate chain ecdsa_tp
certificate 6156E3D5000000000009
308203BF 30820365 A0030201 02020A61 56E3D500 00000000 09300A06 082A8648
...
68656c6c 6f736861 627333E4FDDC 642DA416 F57D4962 C5DF6545 FEC931FA F84BAF40
A9829E
quit
certificate ca 780887F0CDD97E9E49DB893FA5D74238
30820206 308201AB A0030201 02021078 0887F0CD D97E9E49 DB893FA5 D7423830
0A06082A 8648CE3D 04030230 4F311330 11060A09 92268993 F22C6401 19160363
...
816AA443 9191FBAC 731C
quit
A certificate map is created that will match certificates containing a subject name of cisco.com. This is used within the IKEv2 profile to anchor the certificates presented by the peers. As this is a site-to-site VPN with only two peers, the certificate map could have been more granular to include the peer DN.
crypto pki certificate map certmap 10
subject-name co cisco.com
The default IKEv2 proposal is disabled, and a new IKEv2 proposal is created that contains the relevant cryptographic algorithms.
no crypto ikev2 proposal default
crypto ikev2 proposal nge
encryption aes-gcm-256
prf sha512
group 21
An IKEv2 policy is created, which encompasses the IKEv2 proposal created above. Because the default IKEv2 proposal is disabled, this then ensures that only the IKEv2 proposal named nge will be used and minimizes the chance of mis-configuration.
crypto ikev2 policy default
match fvrf any
proposal nge
An IKEv2 profile is created, which uses the certificate map created earlier. The identity is set to DN, which will use the DN from the certificate. The authentication method is set to ECDSA and the PKI trustpoint used which was configured earlier. This profile will only match peer certificates, which contain the string cisco.com within the subject name. Dead-peer detection is enabled to ensure that the IKEv2 SA and corresponding IPsec Security Associations are torn down in a timely manner if IKE connectivity is lost.
crypto ikev2 profile nge
match certificate certmap
identity local dn
authentication remote ecdsa-sig
authentication local ecdsa-sig
pki trustpoint ecdsa_tp
dpd 10 2 on-demand
An IPsec transform set is created, which uses AES-GCM-256. Because this is a combined mode cipher, no integrity algorithm is required.
crypto ipsec transform-set nge-transform esp-gcm 256
mode transport
The default IPsec profile is disabled, which ensures that it is not used due to mis-configuration. A new IPsec profile is created which uses the IKEv2 profile and IPsec transform-set created earlier. Additionally, perfect forward secrecy is enabled to ensure that a fresh Diffie-Hellman exchange is performed on rekey.
no crypto ipsec profile default
crypto ipsec profile nge-profile
set transform-set nge-transform
set pfs group21
set ikev2-profile nge
A loopback interface is used that will allow traffic to be sourced from and destined to as it transverses the VPN.
interface Loopback0
ip address 192.168.10.1 255.255.255.0
The tunnel interface is created with the relevant source interface configured and with the destination address of Router2. This is protected by the IPsec profile created above.
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel source Ethernet0/0
tunnel destination 10.10.10.2
tunnel protection ipsec profile nge-profile
The E0/0 interface is used as the tunnel source.
interface Ethernet0/0
ip address 10.10.10.1 255.255.255.0
A static route is configured to send all traffic for the 192.168.20.0/24 network, which is the subnet protected by the peer, via the peer tunnel IP address.
ip route 192.168.20.0 255.255.255.0 172.16.1.2
Router2 has a nearly similar configuration; the following example illustrates the unique configuration. The tunnel interface has a unique IP address, and the destination is configured as E0/0 on Router1.
Note the unique IP address and the tunnel destination of Router1.
interface Tunnel0
ip address 172.16.1.2 255.255.255.252
tunnel source Ethernet0/0
tunnel destination 10.10.10.1
tunnel protection ipsec profile nge-profile
interface Ethernet0/0
ip address 10.10.10.2 255.255.255.0
The following example illustrates verification that the IKEv2 SA established. The algorithms used to secure the IKE session as described in Table 7-1 can be seen.
Router1#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.10.10.1/500 10.10.10.2/500 none/none READY
Encr: AES-GCM, keysize: 256, PRF: SHA512, Hash: None, DH Grp:21, Auth sign:
ECDSA, Auth verify: ECDSA
Life/Active Time: 86400/6 sec
CE id: 1030, Session-id: 13
Status Description: Negotiation done
Local spi: 313404E23B3A5707 Remote spi: 13FE5BCC09FFAAAB
Local id: hostname=Router1.cisco.com
Remote id: hostname=Router2.cisco.com
Local req msg id: 2 Remote req msg id: 0
Local next msg id: 2 Remote next msg id: 0
Local req queued: 2 Remote req queued: 0
Local window: 5 Remote window: 5
DPD configured for 10 seconds, retry 2
Fragmentation not configured.
Extended Authentication not configured.
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA : Yes
IPv6 Crypto IKEv2 SA
The creation of the IPsec Security Association can be seen in the following example. The tunnel interface is configured with the default GRE mode, the traffic selectors can be seen indicating this by the use of IP protocol 47.
Router1#show crypto sockets
Number of Crypto Socket connections 1
Tu0 Peers (local/remote): 10.10.10.1/10.10.10.2
Local Ident (addr/mask/port/prot): (10.10.10.1/255.255.255.255/0/47)
Remote Ident (addr/mask/port/prot): (10.10.10.2/255.255.255.255/0/47)
IPSec Profile: "nge-profile"
Socket State: Open
Client: "TUNNEL SEC" (Client State: Active)
Crypto Sockets in Listen state:
Client: "TUNNEL SEC" Profile: "nge-profile" Map-name: "Tunnel0-head-0"
The following example illustrates the route to 192.168.20.0/24, which be seen via the tunnel interface. All traffic intended for this network will be sent via the tunnel and encrypted by the corresponding IPsec Security Association.
Router1#show ip route 192.168.20.0 255.255.255.0
Routing entry for 192.168.20.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 172.16.1.2
Route metric is 0, traffic share count is 1
Router1#show ip route 172.16.1.2
Routing entry for 172.16.1.0/30
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1
Traffic is sent from Router1 to Router2 via the tunnel interface. Note that this traffic has been protected by the IPsec Security Association, as indicated by the increasing encaps and decaps counters.
Router1#ping 192.168.20.1 source 192.168.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/6 ms
Router1#show crypto ipsec sa
interface: Tunnel0
Crypto-map tag: Tunnel0-head-0, local addr 10.10.10.1
protected vrf: (none)
local ident (addr/mask/prot/port): (10.10.10.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (10.10.10.2/255.255.255.255/47/0)
current_peer 10.10.10.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.10.10.1, remote crypto endpt.: 10.10.10.2
plaintext mtu 1466, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0x3FD4A2AF(1070899887)
PFS (Y/N): Y, DH group: group21
inbound esp sas:
spi: 0x349334C6(882062534)
transform: esp-gcm 256 ,
in use settings ={Transport, }
conn id: 6, flow_id: SW:6, sibling_flags 80000000, crypto-map:
Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4207250/3566)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x3FD4A2AF(1070899887)
transform: esp-gcm 256 ,
in use settings ={Transport, }
conn id: 5, flow_id: SW:5, sibling_flags 80000000, crypto-map:
Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4207250/3566)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
RSA Authentication Using HTTP URL Lookup
In this scenario, we will use RSA certificates to authenticate both peers. However, for Router2, we will not send the certificate within the IKE AUTH exchange, but will send a HTTP URL from Router2 to Router1 to inform it where to obtain the certificate. Router1 will then retrieve the certificate from the HTTP URL and verify that the presented AUTH payload was signed by the private key relating to the public key contained within the certificate.
Router1 has been set up as a certificate authority; from this CA, a certificate is obtained for both Router1 and Router2. These certificates are used to authenticate the IKEv2 SA.
Figure 7-3 illustrates the operation of the HTTP URL lookup feature. Router2 will sign the AUTH payload with its private key. Router1 will retrieve the certificate from the HTTP server and validate the AUTH payload by using the public key obtained from the retrieved certificate.
)
Figure 7-3 HTTP URL Lookup Feature
openssl x509 -outform der -in 3.crt -out 3.der
Figure 7-4 illustrates the topology used in the tunnel interface configuration.
)
Figure 7-4 Topology with Configuration
The configuration is similar to the ECDSA example earlier, but RSA certificates are used, which results in a different authentication method. However, the base concepts are the same with regards to the PKI.
The subject information access (SIA) is an attribute within a certificate that defines some type of offered services. An example of where to access a server can be included in the SIA with a uniform resource identifier (URI). The SIA is amended to contain the URL that the peer will use for the HTTP URL lookup. This is achieved by the use of the certificate map that matches the locally used certificate and is attached to the trustpoint. This removes the inclusion of the certificate within the IKE exchange and uses the value defined in the SIA as the location for the peer to obtain the certificate.
The following example illustrates the configuration used on Router2.
The PKI trustpoint is defined; it has been authenticated, and the local device enrolled. The critical component to ensure that this client does not send its certificate but instead sends the HTTP URL is the match certificate command. This command will match the defined certificate map and override the SIA to contain the configured URL. This is then sent in replacement of the certificate in the IKE_AUTH exchange.
crypto pki trustpoint CA
enrollment url http://10.10.10.1:80
revocation-check crl
match certificate local override sia 1 http://192.168.1.100/3.der
A certificate map is created that will match certificates containing a subject name of router1.cisco.com. This is used within the IKEv2 profile to anchor the peer’s presented certificate.
crypto pki certificate map certmap 10
subject-name eq router1.cisco.com
The following certificate map is used by the match statement within the trustpoint configuration to match the local certificate. This is achieved by matching the local subject name (which is not case sensitive) of router2.
crypto pki certificate map local 10
subject-name co router2
The mandatory IKEv2 profile is configured which uses the certificate map created earlier. This will match any certificates which contain a subject name of cisco.com. The authentication method is set to RSA signatures, and the trustpoint configured earlier is used.
crypto ikev2 profile default
match certificate certmap
identity local dn
authentication remote rsa-sig
authentication local rsa-sig
pki trustpoint CA
The tunnel interface is created with the relevant source interface configured and the destination address of Router1. This is protected by the default IPsec profile which uses the default IKEv2 profile which was created earlier.
interface Tunnel0
ip address 172.16.1.2 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 10.10.10.1
tunnel protection ipsec profile default
The following physical interface is used as the tunnel source.
interface Ethernet0/0
ip address 10.10.10.2 255.255.255.0
crypto pki trustpoint CA
match certificate local override sia 1 http://192.168.1.100/3.der
match certificate local override sia 2 http://192.168.1.100/subca1.der
match certificate local override sia 3 http://192.168.1.100/subca2.der
match certificate local override sia 4 http://192.168.1.100/root.der
The following example illustrates the configuration used on Router1.
The certificate authority function is enabled. Note that the automatic granting of certificates is used here for ease of configuration and should not occur in a production environment where un-authenticated access to the CA can occur.
crypto pki server local
database level complete
no database archive
grant auto
The relating PKI trustpoint for the IOS CA is:
crypto pki trustpoint local
revocation-check crl
rsakeypair local
A trustpoint is used to enroll into the local CA.
crypto pki trustpoint CA
enrollment url http://10.10.10.1:80
revocation-check crl
A certificate map is created that will match certificates containing a subject name of router2.cisco.com. This is used within the IKEv2 profile to anchor the peer’s presented certificate.
crypto pki certificate map certmap 10
subject-name eq router2.cisco.com
The mandatory IKEv2 profile is configured that uses the certificate map created earlier. This will match any certificates, which contain a subject name of cisco.com. The authentication method is set to RSA signatures, and the trustpoint configured earlier is used.
crypto ikev2 profile default
match certificate certmap
identity local dn
authentication remote rsa-sig
authentication local rsa-sig
pki trustpoint CA
The tunnel interface is created with the relevant source interface configured, and the destination address of Router1. This is protected by the default IPsec profile that uses the default IKEv2 profile, which was created earlier.
interface Tunnel1
ip address 172.16.1.1 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 10.10.10.2
tunnel protection ipsec profile default
The physical interface used as the tunnel source.
interface Ethernet0/0
ip address 10.10.10.1 255.255.255.0
The physical interface used to reach the HTTP server containing the certificates.
interface Ethernet0/1
ip address 192.168.1.1 255.255.255.0
The following example illustrates IKEv2 debugs taken from Router1. It can be seen that Router2 sends the IKE_AUTH exchange with the CERT payload containing the HASH and URL format. Also note the NOTIFY payload which indicates the HTTP URL method is supported.
IKEv2:(SESSION ID = 4,SA ID = 1):Received Packet [From 10.10.10.2:500/To
10.10.10.1:500/VRF i0:f0]
Initiator SPI : 52D538043A8E330C - Responder SPI : 5CE063D07E8745EA Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
IKEv2-PAK:(SESSION ID = 4,SA ID = 1):Next payload: ENCR, version: 2.0 Exchange
type: IKE_AUTH, flags: INITIATOR Message id: 1, length: 816
Payload contents:
VID Next payload: IDi, reserved: 0x0, length: 20
IDi Next payload: CERT, reserved: 0x0, length: 44
Id type: DER ASN1 DN, Reserved: 0x0 0x0
CERT Next payload: CERTREQ, reserved: 0x0, length: 52
Cert encoding Hash and URL of PKIX
CERTREQ Next payload: NOTIFY, reserved: 0x0, length: 25
Cert encoding Hash and URL of PKIX
NOTIFY(HTTP_CERT_LOOKUP_SUPPORTED) Next payload: AUTH, reserved: 0x0, length: 8
Security protocol id: Unknown - 0, spi size: 0, type:
HTTP_CERT_LOOKUP_SUPPORTED
AUTH Next payload: CFG, reserved: 0x0, length: 136
Auth method RSA, reserved: 0x0, reserved 0x0
CFG Next payload: SA, reserved: 0x0, length: 304
cfg type: CFG_REQUEST, reserved: 0x0, reserved: 0x0
A short time later, Router1 opens a TCP socket with 192.168.1.100, when the certificate is obtained.
TCP: sending SYN, seq 2191097267, ack 0
TCP0: Connection to 192.168.1.100:80, advertising MSS 1460
TCP0: state was CLOSED -> SYNSENT [42603 -> 192.168.1.100(80)]
TCP0: state was SYNSENT -> ESTAB [42603 -> 192.168.1.100(80)]
TCP: tcb 32417230 connection to 192.168.1.100:80, peer MSS 1460, MSS is 1460
The following example illustrates verification on Router1 that the certificate was obtained by way of HTTP.
Router1#show crypto ikev2 stats ext-service
--------------------------------------------------------------
AAA OPERATION PASSED FAILED
--------------------------------------------------------------
RECEIVING PSKEY 0 0
AUTHENTICATION USING EAP 0 0
START ACCOUNTING 0 0
STOP ACCOUNTING 0 0
AUTHORIZATION 0 0
--------------------------------------------------------------
IPSEC OPERATION PASSED FAILED
--------------------------------------------------------------
IPSEC POLICY VERIFICATION 3 0
SA CREATION 3 0
SA DELETION 3 0
---------------------------------------------------------------
CRYPTO ENGINE OPERATION PASSED FAILED
---------------------------------------------------------------
DH PUBKEY GENERATED 34 0
DH SHARED SECKEY GENERATED 29 0
SIGNATURE SIGN 28 0
SIGNATURE VERIFY 3 0
--------------------------------------------------------------
PKI OPERATION PASSED FAILED
--------------------------------------------------------------
VERIFY CERTIFICATE 3 0
FETCHING CERTIFICATE USING HTTP 1 0
FETCHING PEER CERTIFICATE USING HTTP 1 0
GET ISSUERS 31 0
GET CERTIFICATES FROM ISSUERS 28 0
GET DN FROM CERT 3 0
--------------------------------------------------------------
GKM OPERATION PASSED FAILED
--------------------------------------------------------------
GET_POLICY 0 0
SET_POLICY 0 0
The certificate that is obtained via HTTP is cached locally. By default, 200 certificates will be cached. As the certificate is cached, if the IKE session drops and is re-established, the certificate will not be required to be obtained via HTTP as it is already cached. This saves numerous HTTP requests to occur if the peer is required to re-authenticate. The following example illustrates viewing the contents of the certificate cache.
Router1#show crypto ikev2 certificate-cache
No of entries in ikev2 certificate-cache = 1
Certificate entry:
Certificate
Status: Available
Certificate Serial Number (hex): 03
Certificate Usage: General Purpose
Issuer:
cn=CA.cisco.com
Subject:
Name: Router2.cisco.com
hostname=Router2.cisco.com
Validity Date:
start date: 10:44:26 UTC Feb 8 2016
end date: 10:44:26 UTC Feb 7 2017
Associated Trustpoints:
The following example illustrates the IKEv2 SA being verified. The cryptographic algorithms used have been negotiated via the use of smart defaults. The authentication method of RSA can be seen. There is no differentiation that the certificate was received via the HTTP URL method; the authentication is performed in the same manner as RSA authentication when certificates are sent in the IKE_AUTH exchange.
Router1#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.10.10.1/500 10.10.10.2/500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:5, Auth sign:
RSA, Auth verify: RSA
Life/Active Time: 86400/509 sec
CE id: 1034, Session-id: 7
Status Description: Negotiation done
Local spi: 5CE063D07E8745EA Remote spi: 52D538043A8E330C
Local id: hostname=Router1.cisco.com
Remote id: hostname=Router2.cisco.com
Local req msg id: 0 Remote req msg id: 2
Local next msg id: 0 Remote next msg id: 2
Local req queued: 0 Remote req queued: 2
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
Fragmentation not configured.
Extended Authentication not configured.
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA : No
IKEv2 Cookie Challenge and Call Admission Control
The following scenario highlights the use of the cookie challenge and the maximum in negotiation SA features, and the benefits that each brings.
IKEv2 call admission control (CAC) limits the maximum number of IKEv2 SAs that can be established. CAC limits the number of simultaneous negotiations with the default being 40 in-negotiation SAs, although this value is configurable using the crypto ikev2 limit max-in-negotation-sa command.
To illustrate the CAC in action, the architecture in Figure 7-5 was developed. This setup consists of an IOS device acting as a VPN headend. Imagine a device created to send many IKE_SA_INIT requests to the headend from random spoofed source IP addresses. The IOS headend is configured with a default gateway, which is where all replies to any received IKE_SA_INIT messages will be sent and then discarded. The IKEv2 generator is pre-configured with an IKEv2 proposal that will be accepted by the IKEv2 headend and sends approximately 12 spoofed packets every second.
)
Figure 7-5 CAC Architecture
The IKEv2 generator sends an IKE_SA_INIT request with a spoofed source IP address of 192.168.1.1 to 10.10.10.1. The IKEv2 headend receives the IKE_SA_INIT, checks that the transforms are valid, allocates state and returns its IKE_SA_INIT response. This response will be received by the router and then forwarded to the 192.168.1.1 destination where it will be discarded.
The hardware used for the IKEv2 headend was purposely chosen as a low-powered device. This was to illustrate the load when generating a large number Diffie-Hellman calculations and the software crypto engine was used. The following example illustrates the CPU history when a constant stream of spoofed IKEv2 SA_INIT requests is sent from the IKEv2 generator. The sudden initial spike in CPU (40 to 60 seconds) is due to the device processing the first forty spoofed IKE_SA_INIT requests, these are processed and replies sent. The CPU then drops to zero percent for approximately fifteen seconds and once again rises back to near full CPU at ninety percent. The drop in CPU processing was due to the CAC feature becoming active. Once forty IKE SAs are in negotiation, no more IKE_SA_INIT requests will be processed. Although the IKEv2 generator is sending a constant stream of these, the IKEv2 headend will only process forty at any given time (although this value is configurable). Some of the initial forty requests time out, and the state for these are removed before any new requests are processed and state allocated.
Router#show processes cpu history
100
90 *****
80 ***** *****
70 ***** *****
60 ***** *****
50 ********** **********
40 ********** **********
30 ********** **********
20 ********** **********
10 ********** ***************
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
CPU% per second (last 60 seconds)
When an IKEv2 device acting as a responder receives a number of half-open IKE_SA_INIT requests, the cookie challenge mechanism can be deployed. This will enable the responder to include the cookie notification payload in the response to the initiator. The responder does not allocate any state to the session. If the initiator was legitimate, the response containing the cookie will reach the initiator who will then re-attempt the IKE_SA_INIT exchange, including the cookie notification payload, which is then verified by the responder. The responder will then allocate state to the IKE session.
If a device is under a Denial-of-Service (DoS) attack where spoofed IKE_SA_INIT are sent with the purpose of overloading the CPU, the device can be configured to activate the cookie-challenge mechanism. In this situation, the responder will reply with the cookie notification payload. Because this reply is sent to an IP address that was spoofed by an attacker, this reply will be discarded, or dropped by the receiver.
To illustrate this behavior, the IKEv2 headend was amended to allow 1000 in negotiation SAs. The following example shows the command used to achieve this.
Router(config)#crypto ikev2 limit max-in-negotation-sa 1000
The CPU of the IKEv2 headend was then constantly at 100 percent. This was due to the amount of constant spoofed IKE_SA_INIT requests from the IKEv2 generator that overwhelmed the IKEv2 state machine.
To rectify this issue, the cookie-challenge is enabled by default. This was enabled, using the value of 0, so all received IKE_SA_INIT requests will be returned with the cookie notification payload.
Router(config)#crypto ikev2 cookie-challenge 0
The value configured can be between 0 and 1000, which denotes the maximum number of in-negotiation IKE SAs before the cookie challenge is engaged.
No state is allocated to any IKE sessions as all IKE_SA_INIT replies are resent. The following example illustrates the impact that enabling the cookie challenge mechanism has. Once cookie challenge is enabled, the CPU drops from 100 to 0 percent. This is due to the fact that no state is allocated to any of the received IKE_SA_INIT requests.
Router#show processes cpu history
100 *******************************************************
90 *******************************************************
80 *******************************************************
70 *******************************************************
60 *******************************************************
50 *******************************************************
40 *******************************************************
30 *******************************************************
20 *******************************************************
10 *******************************************************
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
CPU% per second (last 60 seconds)
The cookie challenge is a useful feature when an IKEv2 headend is under a DoS attack whereby source IP addresses are spoofed. It can be enabled by default. However, this will incur an additional two-packet exchange to any IKE negotiation which might not be optimal in some situations. Using a value for the maximum in negotiation SAs that is a little higher than what is observed in a known good state will allow this mechanism to engage should a DoS condition occur.