The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to configure Internet Key Exchange version 2 (IKEv2) and IP Security (IPSec) on the Cisco 1000 Series Connected Grid Routers (hereafter referred to as Cisco CG-OS router) to support secure communications between a source (Cisco CG-OS router) and destination router over a virtual tunnel.
Internet Key Exchange Version 2 (IKEv2) is a key management protocol standard that is used in conjunction with the IPsec standard. IPSec is a security protocol that provides data security by tunnel and transport mode.
In the tunnel mode, IPSec protects peer-to-peer communication between two end nodes by establishing a virtual tunnel between those two endpoints. On the Cisco CG-OS router, this virtual tunnel is built between itself (source) and the destination router such as the Cisco ASR 1000 Series Aggregation Services Routers (Cisco ASR), which serve as a head-end router.
The virtual tunnel does not manage or modify any packets that are sent over the physical interfaces of the Cisco CG-OS router. Therefore, the Cisco CG-OS router can interoperate with most IPSec implementations (operating with IKEv2) that support IPSec Encapsulating Secure Payload (ESP) operating in tunnel mode. (See limitations in Guidelines and Limitations for IKEv2 and IPSec.)
The Cisco CG-OS router employs IKEv2 to authenticate to the destination router by using either a pre-shared key (PSK) or by using RSA signatures with a Public Key Infrastructure (PKI). IKEv2 must be configured on the source and destination router (peers) and both routers must employ the same authentication method.
When a packet arrives at the router through an interface, the Cisco CG-OS router applies any configured Policies to that interface such as ingress IP access control lists (IP ACLs) or QoS policies. During IP routing, the Cisco CG-OS router identifies any traffic destined for the virtual tunnel. Before forwarding that traffic to the virtual tunnel interface (VTI), the Cisco CG-OS router attaches any egress policies defined for the VTI. At the VTI, IPSec encrypts the original packet and then encapsulates it within another packet. The encapsulated packet has the Differentiated Services Code Point (DSCP) field of the original packet and its outer address has the source (Cisco CG-OS router) and destination (head-end router) addresses of the VTI.
After encapsulation, IPSec resubmits the packet to the routing function for forwarding to an interface for transmission to the head-end router. The Cisco CG-OS router applies any configured egress IP ACL or QoS policies configured for the interface, before the packet exits the interface.
When the encapsulated packet (with an IP protocol field of ESP) arrives at the destination router (head- end router), the Cisco CG-OS router applies any ingress IP ACL and QoS policies configured for the ingress interface to the packet. The encapsulated packet is then forwarded for processing by IPSec (before any route lookup occurs) for de-encryption. After de-encryption, IPSec forwards the original packet back into the routing function where the Cisco CG-OS router applies egress IP ACL and QoS policies configured for the VTI.
IKEv2 employs policies to negotiate handshakes between the two peers. These policies, which are configured on each peer, are a combination of the various security parameters listed below:
Each policy has a unique priority number assigned to it.
The peers must share at least one common policy to allow for successful secure communication.
During the IKEv2 Security Association (SA) negotiation, IKEv2 searches for a policy that is the same for both peers. The peer that initiates the negotiation (handshake) sends all its supported policies to the remote peer.
After successful IKEv2 SA negotiation between the peers, IPSec SA negotiation occurs by exchanging profiles (known as transform-sets) between the two peers.
The primary application of IPSec and IKEv2 is to allow the configuration of tunnels between the
Cisco CG-OS router and the head-end router to securely encapsulate and de-encapsulate traffic sent and received over a WAN interface from an insecure backhaul.
IKEv2 negotiates the secure communication channel and IPSec encrypts and de-encrypts the traffic received from an insecure backhaul to provide data confidentiality, data integrity, and authentication. IPSec also provides support for the anti-replay protocol that provides IP packet-level security to prevent interception and modification of message packets that are being sent between a source and destination system.
IPv4 packets can be transported within the virtual tunnel. The Cisco CG-OS router supports up to 25 simultaneous IPSec virtual tunnels.
A connection must exist between the Cisco CG-OS router and the head-end router before you can configure a virtual tunnel interface between the two systems.
IKEv2 must be configured on the source (Cisco CG-OS router) and destination (head-end) routers.
IPSec only supports key negotiation using IKEv2 and does not support connection to firewalls configured on the Cisco ASA 5500 Series Adaptive Security Appliance and other VPN concentrator products.
Table 8-1 lists the default settings for IKEv2 policy parameters.
Table 8-2 lists the default settings for IPSec profile parameters.
Contact the system administrator to confirm the authentication method (PSK or RSA) to configure on the Cisco CG-OS router.
This example shows how to enable IKEv2 and then create a virtual IPSec tunnel when employing RSA authentication for both the Cisco CG-OS router and the head-end router.
This example configuration employs a Cisco ASR 1000 Series as the head-end router.
RSA mode is the system default setting for the Cisco CG-OS router.
Cisco CG-OS Router Configuration
Note When you use the system default for a parameter there is no need to enter the associated command. In the configuration below, the Cisco CG-OS router uses the default settings for authentication, encryption, hash algorithm, group, and lifetime seconds ( to ).
These commands show how to enable and configure IKEv2 on the Cisco CG-OS router.
These commands show how to enable tunnelling on the router and then create a virtual IPSec tunnel (Tunnel 0) and then define profiles for that tunnel.
Note In the configuration below, the connected grid router uses the default settings for the set security-association lifetime seconds kilobytes parameter ().
Note Any Cisco IOS router configured as the head-end router must be configured as responder-only as shown in the configuration section below.
Note Cisco recommends the set security-association lifetime kilobytes and seconds values set in the procedure below to protect against connection tear-downs.
This example shows how to enable IKEv2 and then create a virtual IPSec tunnel employing pre-shared key (PSK) for authentication between the Cisco CG-OS router and the head-end router. This example configuration employs a Cisco ASR 1000 Series router as the head-end router.
Connected Grid Router Configuration
These commands show how to enable and configure IKEv2 on the Cisco CG-OS router.
Head-End Router Configuration (Cisco ASR 1000 Series with Cisco IOS)
To display IKEv2 and IPSec configurations, enter any or all of the following commands.
To display IKEv2 and IPSec statistics, refer to the commands summarized in Verifying the Configuration.
To troubleshoot IKEv2 and IPSec configurations, you can use the following commands.
The following is example output for IKEv2 debug commands:
This example output from the debug ipsec_tun trace command shows a successful handshake:
The following is output of the debug ipsec_tun packet command while sending a ping packet: