Chapter 6. Advanced IKEv2 Features
IKEv2 is a modular protocol and has the ability to incorporate a number of additional tweaks and features into the protocol itself.
The industry has developed additional features into IKEv2, such as IKEv2 fragmentation that was added after the initial release of the RFC. Prior to the standardization of IKEv2 fragmentation, it was implemented as a Cisco proprietary feature in Cisco IOS.
Cisco has developed a number of other proprietary features that interact with IKEv2 and enhance the architecture of VPNs. IKEv2 allows for the transportation of security group tags (SGT) when using Cisco TrustSec.
Cisco IOS allows for the handling of expired or revoked certificates in a strict manner, allowing for certificates that have been used to authenticate an IKEv2 SA, but are then revoked or expired, to remove the IKEv2 SA.
Introduction to IKEv2 Fragmentation
IKEv2 uses UDP as the transport protocol for its messages. The majority of IKEv2 messages are generally small in size, with most being well below 500 bytes. The exception to this is the IKE_AUTH exchange. When using certificates, the size of the messages used in the exchange can become large, in some cases too large for traffic to transverse certain links. When the size of the IP packet (aka datagram) is too large, a number of scenarios can occur with regard to the router that owns the link:
The IP packet can be dropped and a message indicating this condition is sent back to the sender.
The IP packet is split (fragmented) into smaller pieces so that these can fit on the link.
The IP packet can be discarded and no action taken.
In many cases when IP packets are fragmented, problems can occur, such as fragmented packets being dropped by security or network address translation (NAT) devices, or the indication message that a packet was dropped is discarded en route to the sender.
Any of these scenarios can lead to loss of connectivity with the result that the IKEv2 SA is not established. The use of IKEv2 fragmentation mitigates these issues by performing fragmentation at the IKE layer. If using IKEv2 fragmentation, an IKE message will be split into IKE fragments, and each of these is then sent alone. The sending of these single IKE fragments ensures that when the IKE traffic is encapsulated within UDP and then IP, the size of the resulting IP packet will never exceed the smallest link size between IKE peers.
IP Fragmentation Overview
The IP protocol can operate over a wide variety of transmission links and media types. Theoretically the maximum length of an IP packet is 65535 bytes; this is the largest IP packet size possible. However, due to the fact that most transmission links enforce a smaller maximum packet length limit, also known as the maximum transmission unit (MTU), this value is rarely achieved. The exact value of the IP MTU depends on the type of the transmission media or interface type. It is common for networks of various media types to have different sized MTUs, and even when networks have the same transmission type (such as Ethernet), IP MTUs can differ between equipment types and versions.
Note
Fragmentation can only occur if the Don’t Fragment (DF) flag is not sent within the IP header.
Should a router receive an IP packet that is too big to forward out of an interface because the local interface has a lower IP MTU than the size of the IP packet, and if the DF flag is not set, then the IP packet must be fragmented. Fragmentation involves breaking the packet into a number of pieces so that the new size of the packets is within the size permitted by the interface that the packet will exit. When the original packet is fragmented, each newly created packet will have a new total length, fragment offset, and more fragments field.
When the intended recipient receives the fragmented packets, it can reassemble them, using the fragment offset and more fragments field contained in the IP header. This is detailed in Chapter 15 “IPsec Overhead and Fragmentation.” The issue with network devices performing fragmentation is that this is very resource intensive; on almost all devices, fragmentation is performed in software that requires CPU and memory resource. The receiving device also needs to allocate memory and resources to reassemble the received fragments.
Hosts do have a method to detect the MTU in use on a path and can adjust their MTU for a session so that fragmentation will not occur. The method, known as path MTU discovery (PMTUD), allows for a host to set the DF flag within the fragmentation field of the IP header. Setting the DF flag will ensure that if an IP datagram is required to be fragmented by a network device en-route, fragmentation will not occur. Instead the IP datagram will be discarded, and the network device discarding the datagram will send an Internet control message protocol unreachable message, indicating that the fragmentation was needed, however the DF bit was set (ICMP Type 3 Message 4). This message will contain the IP header of the datagram that required fragmentation along with the first 64 bytes of the payload and the largest MTU that can be sent on the link. When the host receives this ICMP message, it can then reduce the MTU for this session to ensure that future IP datagrams are not fragmented. This process can occur for any links between hosts that requires traffic to be fragmented.
Some network devices can be configured to drop traffic that requires fragmentation and not send an ICMP unreachable message. In this instance, the concept of PMTUD becomes broken, resulting in failed connectivity between hosts. Many network security devices are configured to drop ICMP messages. A network device might drop an IP datagram, which requires fragmentation but has the DF bit set, and send a ICMP unreachable message. The ICMP message might be dropped en-route to the recipient, with the result that all traffic requiring fragmentation is not received by the intended destination.
IKEv2 and Fragmentation
The IKEv2 SA_INIT message can become large in size should a Diffie-Hellman group be used with a large public key (such as Group 18 which uses an 8192-bit MODP). This can considerably add to the size of the resulting IP datagram. The IKE_AUTH exchange can contain one or more certificates, which can result in the packet size exceeding over 1000 bytes. Depending on the public key used for the certificate and the number of certificates sent (if chaining is used), the resulting packet can commonly exceed 1500 bytes, which is the default largest IP MTU on most interfaces. Another common cause of fragmentation in IKEv2 is heavily populated configuration payloads containing many attributes. Cisco AnyConnect advertises the fact that it supports many features using configuration payload, which commonly results in a single IKE SA_INIT or IKE_AUTH message being fragmented into six or more fragments.
Figure 6-1 illustrates an IKE message being fragmented at the IP layer. As the IKE message is larger than the IP MTU, this message is fragmented at the IP layer, resulting in a number of IP datagrams being created to send the single IKE message.
In November 2014, RFC 7383—Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation—was released, which describes how to negotiate and fragment IKEv2 packets. RFC 7383 describes how each IKEv2 peer will advertise the ability to fragment IKEv2 traffic by sending an IKEV2_FRAGMENTATION_SUPPORTED notification payload (type 16430) within the IKE_SA_INIT exchange.
Assuming that both peers include these payloads, the IKE_AUTH and subsequent encrypted exchanges can be fragmented at the IKE layer, rather than the IP layer. IKEv2 messages can be configured to be fragmented should the size of the IKEv2 payload exceed a defined value. Fragmented IKEv2 messages are sent individually within an Encrypted Fragment payload (defined in RFC 7383); the Encrypted Fragment payload contains additional fields to indicate that the packet is a fragment and should be reassembled once successfully decrypted and authenticated by the receiving device.
Figure 6-2 illustrates the negotiation of the ability to support fragmentation. This will only occur within the IKE_SA_INIT exchange, and the fragmentation will only then be performed on IKEv2 traffic that is to be protected.
Note
Allowing IKEv2 fragmentation mitigates the chance of allowing Denial-of-Service (DoS) attacks which utilize weaknesses in fragment reassembly in hosts.
Figure 6-3 illustrates the Encrypted Fragment payload used when IKEv2 fragmentation is activated. The fragment number and total fragments fields in the Encrypted Fragment payload are used by the receiver to reconstruct the IKEv2 message if fragmentation occurs.
For example, if an IKE_AUTH message is required to be 1400 bytes, with UDP (6 bytes) and IPv4 (20 bytes) overhead, this would result in an IP packet being 1426 bytes. Should this packet encounter a link with an IP MTU of 1400 bytes and the DF bit was not set, the packet would be fragmented into two new IP packets.
If IKEv2 fragmentation were used where a value of 800 bytes was configured, then the total size of the IKEv2 message and IP and UDP headers would be 800 bytes. The actual size of the IKEv2 message would be 800 – 6 – 20 = 774 bytes. Rather than sending a single IP packet 1426 bytes in size, two IP packets of size of 800 bytes or less would be sent without the need for fragmentation at the IP layer. Within the Encrypted Fragment payload, the first message would have a fragment number of 1, with the total fragments field set to 2; the second message would have a fragment number of 2 with the total fragments field set to 2. The receiver would decrypt and verify all three received IKEv2 packets and then reconstruct the 1400 byte IKE_AUTH message to then process.
Note
As the size of the IKEv2 packet is configured, the minimum IP MTU between the peers must be known prior to fragmentation at the IKE layer (to calculate the minimum IKEv2 message size). If it is not known, then a value must be guessed that will be below what will be fragmented at the IP layer.
Figure 6-4 illustrates how an outgoing IKE message is fragmented at the IKE layer on an IOS device when IKEv2 fragmentation is enabled with a MTU of 1000 bytes. An IKEv2 message with a size over 1000 bytes is sent out as multiple separate IP payloads, which are not fragmented. The receiver will re-assemble the IKE payload on receipt.
For many years, Cisco IOS has supported the use of fragmenting IKEv2 traffic, using a Cisco proprietary feature, similar to the IETF version but slightly different in the method used to negotiate the capability. Cisco proprietary fragmentation is performed after encryption, while IETF fragmentation is before encryption. The IETF version uses a new Encrypted Fragment payload which has the Fragment Number and Total Fragments fields in cleartext, so decryption is not required to validate the Fragment Number and Total Fragments on receiver.
With Cisco fragmentation the Fragment Number and Total Fragments fields are sent encrypted, so decryption is required before these fields can be validated. The Cisco version uses the Vendor ID payload to advertise the capability; this is contrary to the IETF version that uses the notification payload to announce the ability to use IKEv2 fragmentation.
Cisco IOS 3.15, 15.5.2T, and onward have the ability to use either the standardized IETF version or the Cisco proprietary version. If configured to perform IKEv2 fragmentation, Cisco devices will advertise both IETF and proprietary capabilities. By advertising both methods, Cisco IOS post 3.15/15.5.2T can interoperate with peers that support only the Cisco proprietary method, the IETF standard method, or both.
Table 6-1 details the behavior of IKEv2 fragmentation on an Cisco IOS device post 3.15. If both the Cisco and IETF methods are advertised, then the IETF method will be selected. This allows for Cisco devices to interoperate with older Cisco devices that only support the proprietary method, as well as Cisco or third-party devices that support the standardized method.
By default, IKEv2 fragmentation is not enabled on Cisco IOS; to enable IKEv2 fragmentation, the global command crypto ikev2 fragmentation must be enabled.
The default IKEv2 fragmentation MTU size is set to 576 bytes for IPv4 transport and 1280 bytes for IPv6 transport. This value will set the size of the IKEv2 message plus the UDP and IP overhead, which is calculated at 8 bytes for UDP, 20 bytes for IPv4, and 40 bytes for IPv6.
To configure IKEv2 fragmentation, the command crypto ikev2 fragmentation mtu mtu-size is used, where the MTU size is from 68 to 1500 bytes.
To verify if an IKEv2 session is using fragmentation, issue the show crypto ikev2 sa detailed command. This will indicate if fragmentation is used and the method. The following output illustrates an example output where the use of IKEv2 fragmentation can be seen, along with the type of fragmentation used, in this case it being the standard IETF method.
Router#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.10.10.1/500 10.10.50.5/500 OUTSIDE/none READY
Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth
sign: RSA, Auth verify: RSA
Life/Active Time: 120/38 sec
CE id: 1074, Session-id: 1171
Status Description: Negotiation done
Local spi: F78AC1F7C7C9F558 Remote spi: 5043A7F7F7E1A622
Local id: hostname=R1.cisco.com
Remote id: hostname=R5.cisco.com,cn=r5,o=cisco,ou=service1
Local req msg id: 0 Remote req msg id: 3
Local next msg id: 0 Remote next msg id: 3
Local req queued: 0 Remote req queued: 3
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
IETF Std Fragmentation enabled.
IETF Std Fragmentation MTU in use: 972 bytes....
IKEv2 SGT Capability Negotiation
Security group tagging (SGT) is a technology that overcomes the shortcomings of the traditional approaches to network control policy administration. When a user or device connects to the network and sends network traffic, a Cisco access switch has the ability to automatically profile the user or device and then tag all incoming traffic, based on a policy applied to the profile. 802.1x in conjunction with RADIUS is commonly used to profile the user and/or device. The tag or Security group tag (SGT) is a numerical value and is either manually assigned to the access switches or automatically administered through the use of the Cisco identity services engine (ISE) and applied to network traffic meeting the profile. This tag can then be used on any capable networking device to make access control policy decisions.
Figure 6-5 illustrates the use of a SGT within a basic network. Traffic is classified from each host by the network access switch;, this traffic is then applied a tag when egressing the switch. An access-control-list (ACL) is applied on the router that permits various tagged traffic. This ACL will filter traffic based on SGT rather than the standard 5-tuples (source/destination IP address, protocol and ports) of information.
In order to pass the information about the SGT tag, the Ethernet frame is amended with an additional field, known as Cisco meta data (CMD). Figure 6-6 details the structure of the CMD header. Although the SGT is included within the CMD, many people still refer to the CMD as the SGT.
This CMD field is added to the Ethernet header, between the source MAC and the Ether Type fields. This modification can be thought of as similar to the way modifications are made for 802.1q tags. The modified Ethernet frame can be understood only by selected Cisco devices and will not be passed on devices that do not support or understand this technology.
Figure 6-6 illustrates a Cisco Meta Data header.
When network devices that support SGTs are interconnected by network devices that don’t have this ability (and are unable to read the CMD header), a protocol exists to transfer information about SGT bindings. The Security group tag exchange protocol (SXP) is used by network devices to propagate information about IP to SGT bindings. SXP allows for non-adjacent networking devices to inform each other about IP to SGT mappings that were created statically or assigned dynamically to clients after profiling.
Cisco IOS allows for an IPsec Security Association to include the CMD header within the Encapsulation Security Payload header. Note that this is a Cisco proprietary feature and, at the time of writing, is only available on Cisco IOS. The CMD header is included after the Encapsulation Security Payload header, resulting in the SGT being encrypted and integrity protected. There are a number of benefits for including the SGT tag within an IPsec Security Association:
The SGT allows for policy-based decisions to be made on the protected traffic by the IPsec peer.
The SGT can be viewed by the receiver, which allows for firewall or IPS functionality to then be applied on incoming traffic should these features be enabled.
Having the SGT included within the IPsec Security Association also allows for the SGT to be passed between devices capable of understanding the SGT, without the need for running SXP.
The ability for a device to support including the SGT within an IPsec Security Association is negotiated within the IKEv2 SA_INIT exchange. Devices advertise the fact that they support this ability using the Vendor ID (VID) payload of type CISCO-CTS-SGT. This is a Cisco private VID and should be ignored by any devices that don’t support this feature.
If the negotiation did not occur and the SGT was included by one IPsec peer and the opposing peer did not support or understand the CMD, the decrypted traffic would be dropped. The Encapsulation Security Payload header indicates the next header is CMD by the use of the next header being protocol 99 (any private encryption scheme).
Once both peers have advertised the fact that they support the sending of SGTs within the IPsec Security Association, when clear text traffic enters the tunnel interface—if there is an IP to SGT mapping—the relevant SGT will be added to outgoing traffic prior to encryption. If there is no IP to SGT mapping then a SGT of 0 will be used in the CMD.
Figure 6-7 illustrates the inclusion of the CMD within Encapsulation Security Payload.
It should be noted that, at the time of writing, the use of SGT within an IPsec Security Association is only available for IPsec using VTIs, the reason being when using tunnel mode GRE, traffic will be encapsulated within GRE prior to being encrypted. The tunnel will only see the GRE source and destination address and so will not be able to match on the IP to SGT mapping (which will be a end-host IP address and not an overlay IP address) because it is currently unable to view the traffic that is traversing the tunnel. Using tunnel mode GRE will not enable the ability to see the internal traffic; this is currently tracked via Cisco bug ID CSCuj25890.
Note
If a packet is fragmented either before or after encryption, only the first fragment will be inline tagged with the SGT.
The following output illustrates how to verify that an IPsec Security Association has included a SGT.
Router#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.10.10.1/500 10.10.50.5/500 OUTSIDE/none READY
Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth
sign: RSA, Auth verify: RSA
Life/Active Time: 120/38 sec
CE id: 1074, Session-id: 1171
Status Description: Negotiation done
Local spi: F78AC1F7C7C9F558 Remote spi: 5043A7F7F7E1A622
Local id: hostname=R1.cisco.com
Remote id: hostname=R5.cisco.com,cn=r5,o=cisco,ou=service1
Local req msg id: 0 Remote req msg id: 3
Local next msg id: 0 Remote next msg id: 3
Local req queued: 0 Remote req queued: 3
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 enabled
Verbose debugging can be enabled to verify the SGT applied to traffic using the debug crypto ipsec metadata sgt command.
IKEv2 Session Authentication
As the IKE_AUTH exchange only occurs once when creating an IKEv2 session between peers, and within this exchange, both peers authenticate each other should the authentication method used be digital-signatures, one or more certificates will be exchanged. At the time that this authentication occurs, a number of checks will be performed on the presented certificate in addition to the verification of the digital signature:
Cryptographic checks are performed to ensure that the certificate was signed by the private-key of the issuing certificate authority.
The certificate validity period will be checked to ensure that the certificate has not expired.
If a revocation check is enabled, the serial number of the certificate will be checked to confirm that this has not been revoked. This can be via online certificate status protocol (OCSP) or checking a certification revocation list (CRL).
Once these checks have occurred, at any point in the future should the certificate presented by the peer become revoked or expires, there is no inbuilt mechanism within IKEv2 to then re-authenticate the session to perform the certificate revalidation.
Note that the experimental RFC, RFC 4478 “Repeated Authentication in Internet Key Exchange (IKEv2) Protocol,” describes the ability to perform repeated authentication within IKEv2. However, this is not implemented by Cisco IOS.
The behavior of IKEv1 is different from IKEv2 in the regard of re-authentication. Within IKEv1 an authentication exchange will occur on the IKEv1 session rekeying.
IKEv2 Session Deletion on Certificate Revocation
When a certificate authority issues a certificate, this certificate is used by the owner of the private key that relates to the public key contained within the certificate. The purpose of a certificate is to cryptographically bind an identity to the public key. Should the private key become lost or stolen, then there is no guarantee that whoever presents the certificate and is in possession of the private key is who the certificate classes as the identity.
A certificate authority supports the ability to revoke certificates that for some reason become untrusted. This could be if the private key is lost/stolen or if the certificate was issued incorrectly. A certificate revocation list (CRL) is a list of serial numbers of certificates that have been revoked by the certificate authority. This list is cryptographically signed by the certificate authority and includes a validity period.
Cisco IOS allows for the ability such that if CRL checking is enabled, when a CRL is downloaded, a check will be performed on the serial numbers of all certificates that were used in the authentication of all active IKEv2 SAs. Should the serial number of a certificate be included in the CRL for an active IKEv2 session, that session will be instantly deleted.
To activate the ability to disconnect a revoked peer, the crypto ikev2 disconnect-revoked-peers should be used.
Figure 6-8 illustrates the behavior of IKEv2 session deletion on certificate revocation, when a client connects to an IPsec gateway. When CRL checking is enabled, the CRL will be checked on the initial IKEv2 connection. At this point, the CRL could be locally cached or will need to be downloaded. The serial number of the certificate presented by the client is checked against the CRL by the gateway; at this point the serial number of the certificate is not within the CRL so the authentication is successful. If at some point later, the client’s certificate is revoked, when the updated CRL is then downloaded by the gateway, the gateway will check the serial numbers of all existing IKEv2 SAs, including the sessions that were established earlier, using the client certificate which is then deleted.
An INFORMATIONAL message will be generated to inform the peer that the session is deleted, containing the error code IKEV2_DELETE_CERT_REVOKED.
The following syslog message is generated when an existing IKEv2 session is deleted due to a certificate being revoked;
IKEv2:Sending Delete Reason Notify with error code: IKEV2_DELETE_CERT_REVOKED
severity: INFORMATIONAL
The ability to delete a session that is using a revoked certificate after the session has been established allows for Cisco IOS implementations to adhere to many companies’ security policies which dictate that a certificate must be revoked with a certain period of time and that any VPNs created with that certificate must also be removed within a certain period.
A CRL will have a valid lifetime. If, for example, the lifetime of a CRL is set to 24 hours and an IPsec gateway downloads the CRL one hour after it was published, the IPsec gateway would cache the CRL for the remaining lifetime (23 hours). If a certificate is revoked two hours after the CRL has been downloaded, then the remaining lifetime (21 hours) of the CRL could be used by an attacker to exploit the compromise of a private key by connecting to the VPN gateway before the new CRL containing the revoked certificate was downloaded.
A number of options can be used to reduce the time that a CRL will remain cached on Cisco IOS and before a new CRL obtained:
Download the CRL at regular intervals, using the command crypto pki crl download schedule time.
Use the command crypto pki crl download schedule prepublish to download the CRL prior to the expiry lifetime. This can be used to ensure that the CRL is downloaded at a time prior to the expiry time.
Refresh the CRL cache at regular intervals by renewing all CRLs that are cached (this requires that the cache is populated). This could be scripted using the commands crypto pki crl download trustpoint and crypto pki crl refresh-cache.
IKEv2 Session Deletion on Certificate Expiry
When a certificate authority issues a certificate, this certificate will have a defined lifetime, which is the time that the certificate can be used for. This lifetime is denoted by the certificate validity period, which is the time interval during which the CA warrants that it will maintain information about the status of the certificate. An example of maintenance is that the certificate will only be revoked within this lifetime. The validity field is represented as two dates, the date on which the certificate validity period begins (notBefore) and the date on which the certificate validity period ends (notAfter).
As the authentication within IKEv2 only occurs once, if a certificate is used to authenticate a client and the current time is within the validity period, this certificate can successfully be used. If the current time is outside of the validity period, then authentication will fail.
This opens the interesting case for an IKEv2 SA that is established using a certificate within the validity period but is very close to expiring. Once the certificate expires (the validity period passes), then prior to Cisco IOS version 15.4(3)M or 3.13, there was no automatic method to remove an IKEv2 SA which was created with a certificate.
Since Cisco IOS version 15.4(3)M or 3.13, there is now the ability for the lifetime of the IKEv2 SA to be tied to the lifetime of the certificate validity period. This ensures that once a certificate is outside of the validity period, then the IKEv2 SA is torn down, and for an IKEv2 SA to be re-established, re-authentication will be required (which would then fail as the certificate is expired). This behavior is enabled by default within the IKEv2 profile. Because the behavior is default, the command to enable this behavior lifetime certificate is hidden by default but can be seen by using the show run all command. Should this behavior be required to be disabled, the no lifetime command can be used within the IKEv2 profile to disable this behavior.
In Cisco IOS version 15.4(3)M and 3.13, when an IKEv2 SA is created or a subsequent IKEv2 rekey occurs, the certificate validity time is checked to determine if the IKEv2 SA lifetime is greater than the remaining validity time of the certificate. If the IKEv2 SA lifetime is greater than the remaining certificate validity time, the following IKEv2 debug message is generated, and the IKEv2 SA lifetime is adjusted to only last as long as the certificate validity time.
IKEv2:Adjusting lifetime due to Cert Validity date
The IKEv2 SA will have the adjusted lifetime, when the IKEv2 SA then meets this lifetime rather than an IKEv2 SA rekey occurring the IKEv2 SA is deleted, and the following debug message generated.
IKEv2:(SESSION ID = 24,SA ID = 1):Queuing IKE SA delete request reason:
certificate lifetime expired
IKEv2 Session Lifetime
In the process of establishing an IKEv2 session, both peers authenticate each other; this authentication occurs within the IKE_AUTH exchange. IKEv2 use the concept that once authentication has successfully completed, authentication does not occur again for the duration of the IKEv2 session. When new IKEv2 or IPsec Security Associations are required, these are generated using the CREATE_CHILD_SA exchange, which doesn’t include any form of authentication.
This concept surprises many individuals who are familiar with IKEv1; in IKEv1, the session will have a lifetime (denoted in seconds). This lifetime is included within the policies used to negotiate the IKEv1 session (sent in MM1 and MM2). Just prior to the IKEv1 SA expiring, a new IKEv1 SA is created, which requires a fresh authentication exchange, and then the new IKEv1 SA is used. Having a fresh authentication is more computationally expensive; however, it brings the benefits of proving authenticity for every new IKE exchange.
An IKEv2 Security Association has a lifetime; however, this lifetime is held locally and not negotiated between parties. On Cisco IOS, the default lifetime for an IKEv2 SA is 86,400 seconds or 24 hours; this lifetime is configurable within the IKEv2 profile, using the lifetime command. Before the IKEv2 SA lifetime is reached, a peer will rekey the IKEv2 SA by initiating a CREATE_CHILD_SA exchange. This exchange will create a new IKEv2 SA with new SPIs and key material. This new IKEv2 SA will then exist for its lifetime and should rekey a new IKEv2 SA unless removed by a process or individual. Although each IKEv2 SA has a lifetime, because the IKEv2 SA is free to generate child IKEv2 SAs, the overall crypto session can potentially live forever.
The method to authenticate a peer can be computationally expensive; you could ask the question if I have authenticated a peer once, why would I need to be validated again? This is true in many cases; however, business needs might dictate that an IKEv2 session only lasts for a certain lifetime. If a guest or partner was given VPN access for a period of time, would the business expect that the session could last indefinitely? There might be a security requirement that authentication re-occur at least every 24 hours. In the modern age, it is common for mobile devices to be left on trains or go missing after a night at the pub. In this case, the behavior of IKEv2 to only authenticate once is not ideal as once an IKEv2 session is established, by default it will last until it is manually deleted, disconnected due to timeout, or loss of services results in premature session termination.
To allow for an IKEv2 session to have a strictly defined lifetime, Cisco IOS can be configured to set the lifetime of the cryptographic session when the IKEv2 SA is created. Once this lifetime has been met, the IKEv2 SA and all related IPsec Security Associations will be deleted. This strictly defined lifetime will ensure that the IKEv2 SA only occurs for the configured period and after that the IKEv2 SA is deleted (without any other IKEv2 SAs being rekeyed using the CREATE_CHILD_SA exchange). Should a new session be required between both peers, a new IKE_SA_INIT and IKE_AUTH exchange will occur, guaranteeing that the two peers will authenticate each other.
Having a strict session lifetime allows for scenarios, such as a user being granted access for a given period; when this period has elapsed, the session will be removed. Should the user attempt to re-authenticate, their access would have expired and authentication within the IKE_AUTH exchange would subsequently fail for the new session.
Without this behavior, should it be necessary to remove a session, the session would need to be identified and then cleared, using either of the following commands: clear crypto ikev2 sa or clear crypto session.
The session lifetime has been configurable since version 15.5(1)T or 3.14, where the lifetime can be obtained via the local IKEv2 authorization policy or a policy obtained from RADIUS. This lifetime is then used when creating the crypto session. If the session lifetime is less than the default IKEv2 SA lifetime, then the IKEv2 SA will only be created for the session lifetime, and once the IKEv2 SA expires, it is deleted. If the session lifetime is greater than the IKEv2 SA lifetime, the IKEv2 SA will be created, however subsequent IKEv2 SAs will only be rekeyed until the remaining session lifetime is less than the IKEv2 lifetime. At this point, the final IKEv2 SA will have a lifetime that ensures it expires at the same time as the session lifetime.
It should be noted that the session is deleted when the session lifetime has been met. Assuming that revocation is enabled, if the CRL check passes, the new session will be established. There will be loss of secure connectivity from the time the session is deleted to the time that the new session is created.
The lifetime of the session can be controlled locally by the IKEv2 authorization policy; within this policy, the following command can be used to set the lifetime of the created IKEv2 SA.
session-lifetime <120- 25920000>
The session lifetime can be set, using the IETF RADIUS attribute (27) Session-Timeout. This can be included in the RADIUS Access-Accept when a peer is authenticated, and the created IKEv2 SA be created for the configured lifetime.
The value can be any number with the 32-bit unsigned integer field, which denotes the lifetime in seconds and is configurable.
If an IKEv2 session is created which uses the session lifetime feature, this can be seen by using the show crypto session detail command.
The following example illustrates the establishment of two crypto sessions. The session using virtual-access 1 has a static lifetime with a little over five minutes remaining. When this timer expires, the session will be deleted.
Router#show crypto session
Crypto session current status
Interface: Virtual-Access1
Profile: default
Session status: UP-ACTIVE
Peer: 10.10.50.5 port 500
Session ID: 3
Session Lifetime: 00:05:22
IKEv2 SA: local 10.10.10.1/500 remote 10.10.50.5/500 Active
IPSEC FLOW: permit 47 host 10.10.10.1 host 10.10.50.5
Active SAs: 2, origin: crypto-map
Interface: Virtual-Access2
Profile: default
Session status: UP-ACTIVE
Peer: 10.10.60.6 port 500
Session ID: 6
IKEv2 SA: local 10.10.10.1/500 remote 10.10.60.6/500 Active
IPSEC FLOW: permit 47 host 10.10.10.1 host 10.10.60.6
Active SAs: 2, origin: crypto-map
If IKEv2 debugging is enabled, using the command debug crypto ikev2, the adjusted IKEv2 lifetime can be seen within the generate syslog messages. The following illustrates a session that is established, where the session lifetime is set to 600 seconds, which then sets the IKEv2 lifetime to the same value.
IKEv2:Adjusting lifetime due to Session expiry time
IKEv2:(SESSION ID = 7,SA ID = 1):IKEV2 SA created; inserting SA into database. SA
lifetime timer (600 sec) started
%IKEV2-5-SA_UP: SA UP
When the session lifetime expires and the session is deleted, the following syslog message is generated in this instance.
(SESSION ID = 11,SA ID = 1):Queuing IKE SA delete request reason: session lifetime
expired
Summary
This chapter introduced a number of advanced IKEv2 topics. On Cisco IOS, IKEv2 fragmentation supports both the Cisco proprietary method and the IETF standardized method.
When using Cisco security group tagging, IPsec can be used to transport the SGT tag. IKEv2 performs the negotiation of this feature.
When using certificates for authentication, options exist for designing an architecture that will allow certificates that have been revoked or expired to delete the corresponding IKEv2 SAs. The IKEv2 session lifetime can be used to enable VPN sessions to exist for a defined value of time. This allows systems to be designed where the cryptographic protection and access is provided for the duration that it is needed.
References
https://tools.ietf.org/html/rfc1191 Path MTU Discovery
https://tools.ietf.org/html/rfc5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile