This document covers the theoretical aspects of the GETVPN. It outlines the best deployment methods and best practices recommended by Solution Architects.
GETVPN (Group Encrypted Transport)
What is GETVPN?
Cisco GETVPN delivers a revolutionary solution for tunnel-less, any-to-any and confidential branch communication. Group Encrypted Transport VPN (GETVPN) introduces the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing. All Group Members (GMs) share a common security association (SA), also known as a group SA. This enables GMs to decrypt traffic that was encrypted by any other GM. (Note that IPsec CE acts as a GM.) In GETVPN networks, there is no need to negotiate point-to-point IPsec tunnels between the members of a group, because GETVPN is tunnel-less.
Key GETVPN Benefits
- Large-scale any-to-any encrypted communication.
- Native routing without tunnel overlay.
- Optimal for QoS and Multicast support—improves application performance.
- Transport agnostic—private LAN/WAN, FR/ATM, IP, MPLS.
- Instantaneous large-scale any-to-any IP connectivity using a group IPsec security paradigm.
- Takes advantage of underlying IP VPN routing infrastructure and does not require an overlay routing control plane.
- Seamlessly integrates with multicast infrastructures without the multicast replication issues typically seen in traditional tunnel-based IPsec solutions.
- Preserves the IP source and destination addresses during the IPsec encryption and encapsulation process. Therefore, GETVPN integrates very well with features such as QoS and traffic engineering.
VPN technologies Positioning
GETVPN Technology Overview
The GETVPN solution is based on both open standards and Cisco patented innovative technology which helps utilize the power of underlying MPLS/shared IP networks. In addition to leveraging the existing IKE, IPsec and multicast technologies, GETVPN solution relies on following core building blocks to provide the required functionality:
- GDOI The GDOI group key management protocol is used to provide a set of cryptographic keys and policies to a group of devices. In a GETVPN network, GDOI is used to distribute common IPsec keys to a group of enterprise VPN gateways that must communicate securely. These keys are periodically refreshed and are updated on all the VPN gateways using a process called rekey.
The GDOI protocol is protected by Internet Key Exchange (IKE) SA. All participating VPN gateways must authenticate themselves to the device providing keys using IKE. All IKE authentication methods, for example, pre-shared keys (PSKs) and public key infrastructure (PKI) are supported for initial authentication. After the VPN gateways are authenticated and provided with the appropriate security keys via the IKE SA, the IKE SA expires and GDOI is used to update the GMs in a more scalable and efficient manner. For more information about GDOI, refer to RFC 6407.
GDOI introduces two different encryption keys. One key secures the GETVPN control plane; the other key secures the data traffic. The key used to secure the control plane is commonly called the Key Encryption Key (KEK), and the key used to encrypt data traffic is known as Traffic Encryption Key (TEK).
- Key server (KS)
A key server (KS) is a device responsible for creating and maintaining the GETVPN control plane. All encryption policies, such as interesting traffic, encryption protocols, security association, rekey timers, and so on, are centrally defined on the KS and are pushed down to all GMs at registration time.
GMs authenticate with the KS using IKE (pre-shared keys or PKI) and download the encryption policies and keys required for GETVPN operation. The KS is also responsible for refreshing and distributing the keys.
Unlike traditional IPsec, interesting traffic defined on the KS (using an access control list (ACL)) is downloaded to every GM, irrespective of the GM owns that network. It is recommended to summarize GM networks into as few entries as possible and to strive for a symmetric policy. For example, if all LAN addresses on the GMs are within the 10.0.0.0/8 network (10.1.1.0/24, 10.1.2.0/24, and so on), it is better to define interesting traffic as ― permit 10.0.0.0/8 to 10.0.0.0/8 as opposed to ―permit 10.1.1.0/24 to 10.1.2.0/24, ―10.1.1.0/24 to 10.1.3.0/24, and so on.
Asymmetric policies lead to a geometric expansion in the number of ACL entries. An aggregate policy that serves the most GMs is ideal. The most complete aggregate policy is permit
IP any any. This policy encrypts all traffic leaving the GM crypto interface. Therefore, exceptions must be made (that is, deny entries) to exclude encryption of control plane traffic and management plane necessary to bootstrap the GM.
Note: A device configured as KS cannot be configured as GM.
- Cooperative (COOP) KS
The KS is the most important entity in the GETVPN network because the KS maintains the control plane. Therefore, a single KS is a single point of failure for an entire GET-VPN network. Because redundancy is an important consideration for KSs, GET-VPN supports multiple KSs, called cooperative (COOP) KSs, to ensure seamless fault recovery if a KS fails or becomes unreachable.
A GM can be configured to register to any available KS from a list of all COOP KSs. GM configuration determines the registration order. The KS defined first is contacted first, followed by the second defined KS, and so on.
The COOP protocol is configured on a per GDOI group basis. A KS that is configured with multiple GDOI groups can maintain multiple unique COOP relationships with disparate KSs.
When COOP KSs boot, all KSs assume a secondary role and begin an election process. One KS, typically the one having the highest priority, is elected as a primary KS. The other KSs remain in the secondary state. The primary KS is responsible for creating keys and distributing configured group policies to all GMs, and to periodically synchronize the COOP KSs.
GMs can register to any available KS (primary or secondary), but only the primary KS sends rekey messages. It is possible to distribute GM registration to all available COOP KSs to reduce the IKE processing load on a single KS.
Cooperative KSs exchange one-way announcement messages (primary to secondary) on a 20-second interval. If a secondary KS does not hear from the primary KS over a 30-second interval, the secondary KS tries to contact the primary KS and requests updated information. If the secondary KS does not hear from the primary KS over a 60-second interval, a COOP reelection process is triggered and a new primary KS is elected.
Up to eight KSs can be defined as COOP KSs, but more than four COOP servers are seldom required. Since rekey information is generated and distributed from a single primary KS, the advantage of deploying more than two KSs is the ability to handle registration load in case of a network failure and reregistration taking place at the same time. This is especially important when using Public Key Infrastructure (PKI) because IKE negotiation using PKI requires a lot more CPU power compared to IKE negotiation using pre-shared keys (PSKs).
Periodic DPD must be enabled on the ISAKMP SAs between the KSs if COOP is configured. This way the primary KS can track and display the state of the other secondary KSs. Periodic DPD between GM and KS is not required.
- Group Members (GMs)
A GM is a device responsible for actual encryption and decryption i.e. a device responsible to handle GETVPN data plane. A GM is only configured with IKE parameters and KS/Group information. As mentioned before, encryption policies are defined centrally on the KS and downloaded to the GM at the time of registration. Based on these downloaded policies, GM decides whether traffic needs to be encrypted or decrypted and what keys to use. In a GETVPN network, GM policies are dictated by the KS, but in some instances, a GM can be configured to locally override some of these policies. Any global policy (including both permit and deny entries) defined on the KS affects all the members of the group whether it is applicable to them or not and therefore some policies make more sense when defined locally. As an example, if a handful of GMs in the group is running a different routing protocol, a local entry can be added to these GMs to bypass the encryption of the routing protocol traffic instead of defining the policy globally at the KS level.
- IP tunnel header preservation
In traditional IPsec, tunnel endpoint addresses are used as new packet source and destination. The packet is then routed over the IP infrastructure, using the encrypting gateway source IP address and the decrypting gateway destination IP address. In the case of GETVPN, IPsec protected data packets encapsulate the original source and destination packet addresses of the host in the outer IP header to preserve the IP address.
Figure 1. Tunnel Header Preservation
The biggest advantage of tunnel header preservation is the ability to route encrypted packets using the underlying network routing infrastructure. The branch high availability (HA) provided by the IP, VPLS, or MPLS VPN infrastructure (dual spokes, dual links, and so on) integrates seamlessly with the GETVPN solution. There is no need to provide HA at the IPsec level (dual hubs, stateful IPsec HA, and so on).
Because tunnel header preservation is combined with group SAs, multicast replication can be offloaded to the provider network. Because every GM shares the same SA, the IPsec router closest to the multicast source does not need to replicate packets to all its peers and is no longer subject to multicast replication issues seen in traditional IPsec solutions.
Because of tunnel header preservation, GETVPN solution is very well suited for MPLS, Layer-2 (L2), or an IP infrastructure with end to end IP connectivity. However, GETVPN is generally not a good candidate for deployment over the Internet because enterprise host IP addresses are typically not route-able, and network address translation (NAT) functions interfere with tunnel header preservation.
- A group security association (SA)
Unlike traditional IPsec encryption solutions, GETVPN uses the concept of group SA. All members in the GETVPN group can communicate with each other using a common encryption policy and a shared SA. With a common encryption policy and a shared SA, there is no need to negotiate IPsec between GMs; this reduces the resource load on the IPsec routers. Traditional GM scalability (number of tunnels and associated SA) does not apply to GETVPN GMs.
In a GETVPN group, up to 100 ACL entries (permit and deny) can be used to define interesting traffic for encryption. It is a best practice to summarize interesting traffic to as few permit entries as possible and to build symmetric policies. Unlike traditional IPSec policy, where source and destination address ranges must be uniquely defined, GETVPN is optimized when the source and destination address range are the same. This minimizes the number of policy permutations, making GETVPN very efficient.
- Rekey mechanism
As mentioned above, the KS is not only responsible for creating the encryption policies and keys, but also for refreshing keys and distribute them to GMs. The process of sending out new keys when existing keys are about to expire is known as the rekey process. GETVPN supports two types of rekey messages: unicast and multicast.
If a GM does not receive rekey information from the KS (for example, the KS is down or network connectivity is broken), the GM tries to reregister to an ordered set of KSs when only 5% of the original TEK lifetime remains. Registration must be completed 30 seconds before the existing IPsec SAs expire as GM‘s that have successfully received rekey or re-registered will start using the new IPSec SA when 30 seconds remain in the previous TEK‘s lifetime. The 30-second window provides a graceful roll-over period for traffic encrypted with the previous TEK to clear the network before the deletion of the expiring TEK. If reregistration is successful, the GM receives new SAs as part of the reregistration process and traffic in the data plane flows without disruption. If reregistration is unsuccessful (the preferred KS is unavailable), the GM tries three more times, at 10-second intervals, to establish a connection with the KS. If all attempts to contact the preferred KS fail, the GM tries the next KS in the ordered list. The process repeats through each of the ordered set of KS until all KS have been attempted. The GM will restart the registration process to the first KS in the ordered set until registration is successful.
- Unicast Rekey
In the unicast rekey process, a KS generates a rekey message and sends multiple copies of the message, one copy to each GM. Upon receiving the rekey message, a GM sends an ACK message to the KS. This ACK mechanism not only ensures that the list of active GMs on the KS is current but also ensures that the rekey message is sent only once to GM‘s that successfully receive the rekey and the KS only to active GMs.
A KS can be configured to retransmit a rekey packet to overcome transient defects in the network. If a GM does not acknowledge three consecutive scheduled rekeys, the KS removes the GM from its active GM database and stops sending rekey messages to that GM.
Unicast rekey re-transmission occurs only when a GM does not ACK a rekey.
Internet Key Exchange Version 2 (IKEv2) provides improvisations to ISAKMP infrastructure with lessons learned from the industry. IKEv2 reduces network latency, reduces complexity in message exchanges, improves interoperability and reliability, and fixes the cryptographic issue in HASH authentication. GETVPN combines IKEv2 protocol with IPsec to provide an efficient method to secure IP multicast traffic or unicast traffic through the GETVPN G-IKEv2 feature. This feature provides a complete IKEv2 solution across all of Cisco‘s VPN technologies.
The G-IKEv2 protocol provides a mechanism for a group member (GM) to download policy and keys from a key server (KS). These policy and keys are used to secure communication among GMs in a group. G-IKEv2 is a new model to secure group communication between remote locations in an enterprise private WAN.
Basic GETVPN Architecture
- Group members (GMs) register via GDOI with Key servers (KSs)
- KS authenticates & authorizes the GMs
- KS pushes the set of IPsec SAs for the GM to use
- Data Plane Encryption
- GM exchange encrypted traffic using the group keys
- The traffic uses IPSec Tunnel Mode with Header Preservation
- Periodic Rekey of Keys
- KS pushes out replacement IPSec keys before current IPSec keys expire; this is called a Rekey
GETVPN Data path
- Rekey Message sent from key server to all group members.
- IP multicast message provides very efficient distribution.
- Rekeys resulting from configured KEK & TEK intervals or KS policy change.
- Sequence number based anti-replay only works with a single sender.
- Need a method to work for all senders using same IPSec SA
- Key server downloads relative pseudo time and window size to all the GMs.
- GMs calculate pseudo-timestamp based on downloaded pseudo time and sends out packet.
- Receiving GM verifies packet within window size.
- KS periodically refreshes GMs with pseudo time/window size – this means clock does not need to be synchronized between GMs.
- If sender’s pseudo time falls in the below receiver window, packet accepted
- Packet 1 & packet 2 have pseudo time T0, providing loose anti-replay protection (unlike counter-based)
Key-server Design Consideration
Key-servers play a critical role in a GETVPN implementation and should always be deployed in a redundant fashion. There will be two key servers for the assessed GETVPN. The key server could also be used for load balancing Group Member (GM) registrations. GMs will contact KSs in order of their configuration. All GMs in the network should have the same order of key servers configured, which means no load balancing takes place. The primary key server can handle the load of all GMs and thus the only drawback is a potentially longer convergence time should a large network outage or key server outage occurs.
ISAKMP/IKEv1 For COOP
The lifetime of ISAKMP sessions on the KS is recommended to be the default lifetime of 24 hours. The KSs need the IKE session active to transmit COOP messages between themselves. This is a persistent database synchronization process, so the IKE session is always required. There is no point in tearing down the IKE session because it is immediately restored. ISAKMP periodic dead peer detection (DPD), also called keepalives, must be configured on all KSs (only) so the primary COOP server can keep track of the state of the secondary KSs.
AES mode is recommended for the Traffic Encryption Key. Since AES mode provides more robust security with minimal computation overhead.
Traffic Encryption Key Lifetime
The traffic encryption key (TEK) lifetime should be no less than the default 3600 seconds. The TEK lifetime should never be set below 900 seconds in real deployments because a short TEK lifetime creates more key rollovers that must be synchronized among all GMs. If the KS has insufficient time to complete key distribution before prepositioning the security association with the next TEK, the system operates in an unstable state. The longer lifetime improves network stability and minimizes network change. A TEK lifetime of two hours (7200 seconds) is the recommended value to use.
Access-list in Traffic Encryption Policy
The permit entries in the access control list (ACL) for encryption policy should include the subnets which must be encrypted. The maximum number of lines in a traffic ACL is 100. Note that each permit statement in the KS ACL results in a SA on the GM, so the number of permit entries should be limited to minimize the SA database (SADB) on the GM. As mentioned, it is possible to add a single “
permit ip any any” entry in the ACL to encrypt all
traffic. However, explicit deny entries should be configured in the ACL to exclude control traffic (for example, routing protocols) from encryption. The network designer must determine what traffic requires encryption. The following protocols, which are commonly denied in encryption policy, are provided for reference.
access-list extended get-acl
deny esp any any
deny tcp any any
any eq tacacs
deny tcp any any
any eq ssh any
! when GM‟s use BGP:
deny tcp any any
any eq bgp
! when GM‟s use OSPF:
any 126.96.36.199 0.0.0.255
! NTP unless the IOS hardware clock is made authoritative
deny udp any any
deny udp any any
deny udp any any
!deny udp any any
eq dns ;
!deny udp any any
eq snmp ;
!deny udp any any
eq syslog ;
When PKI is used for authentication, certificates are validated during the initial session establishment between GM and KS. If a certificate gets revoked after the session is established, these existing sessions are not affected by the revocation of that certificate. The GETVPN CRL Checking feature notifies KSs through public key infrastructure (PKI) when a new CRL is available for a configured trustpoint. The KS creates a new Key Encryption Key (KEK) and sends a reauthentication message to the group member devices, which print a syslog message, delete the current KEKs, and reregister to the KS. The GETVPN CRL Checking feature provides the following
- New reauthentication configuration for GETVPN to specify a PKI trustpoint.
- PKI notifies GETVPN when a new CRL is available for download at the PKI server.
- GETVPN verify if new CRL matches the configured PKI trustpoint.
- If the CRL matches, GETVPN KS start a re-authentication process to have all GMs re-register.
- The re-authentication process will be similar to a GM removal.
One needs to configure several components prior to enabling the GETVPN CRL Checking feature. These include:
- A defined PKI certificate authority (CA) so that group members and key servers are PKI clients and, therefore must enroll to get certificates.
- KSs configured to have certificate revocation list (CRL) checking enabled in PKI.
- KSs configured to download the CRL when it is available on the CA and on a first-needed basis.
- This means that the KSs download the CRL following the first group member (GM) registration after the new CRL is available.
- CRL checking disabled on the group member devices for PKI.
- Internet Key Exchange (IKE) authentication set to certificates.
Key Encryption Key Lifetime
The key encryption key lifetime should be left at the default of 86400 seconds. Since the KEK is used to encrypt the control plane messages between the KS and GM. Changing the KEK value frequently subjects the GM to possible rekey misses and subsequently requiring the GM to re-register more frequently than is necessary. It is recommended that the KEK lifetime should always be at least double the TEK lifetime.
Re key Re-transmit Interval
Re-key re transmits should be configured using one of the following schemes:
- Two re-transmissions at 60 second intervals or
- Three re-transmissions at 40 second intervals.
- 3 scheduled rekeys
The rekey re-transmit interval should be set as shown because for groups with many GMs, it can take a significant time to send unicast rekey messages. Re-transmission should start after a complete cycle of rekey messages with sufficient time for acknowledgments. Larger rekey intervals and re-transmissions ensure that TEKs are prepositioned well in advance of TEK expiration and mitigate the impact of network partitioning. The re-transmission and rekey interval duration should also exceed the KS DPD, and IP convergence in the core network.
The key-servers in the assessed network use “rekey retransmit 40 number 3”, which deviates from the recommended values. As the number of GMs is below four hundred, the shorter time should be OK.
The key-server configuration uses IKEv1. IKEv1 is configured according to best practices.
The Cisco GETVPN implementation doesn’t include Perfect Forward Secrecy (PFS). PFS assures, that the session keys will not be compromised even if the private key of the server is compromised. PFS creates a unique session key for every session independent of any previous key. Thus, every session will have to be decrypted by a potential attacker (e.g. brute force) independently, which considerably increases the overall security. In Cisco’s GETVPN implementation PFS is introduced by using IKEv2 with the GETVPN G-IKEv2 feature.
COOP KS Configuration
The preceding configuration is sufficient for a standalone KS in an enterprise network. This section describes the configuration of a COOP KS. Before deploying COOP KS configurations, consider the following:
- Generate RSA keys in the primary KS (as required for rekeys) and export both private and public keys to all the COOP KSs. This is required in case the primary KS goes down; the rekeys sent by the newly elected primary KS will still be properly verified by the GM.
- The election between the KSs is based on the highest-priority value configured. If they are same, it is based on the highest IP address. It is suggested to configure priorities for selecting the primary KS for easy setup and troubleshooting.
- Periodic ISAKMP keepalive (dead peer detection, or DPD) must be configured on the COOP KSs so that the primary KS can track the secondary KS state.
- Rekey configuration, policies, and anti-replay configurations must be the same for all KSs. This is not done automatically in the current phase of GETVPN. The user must manually track configurations.
IKEv2 Proposal Between KS and GM
The AES mode of encryption with 128 bit (or better) keys are recommended for ISKAMP policy, since it provides much more robust security with minimal computational complexity compared to 3DES while DES provides minimal security capabilities. For data integrity, SHA-256 (or higher) is recommended since it is more secure and stronger than SHA-1.
Design Around MTU
Because of additional IPsec overhead added to each packet, MTU related issues are very common in IPsec deployments, and MTU size becomes a very important design consideration. If MTU value is not carefully selected by either predefining the MTU value on the end hosts or by dynamically setting it using PMTU discovery, the network performance will be impacted because of fragmentation and reassembly. In the worst case, the user applications will not work because network devices might not be able to handle the large packets and are unable to fragment them because of the df-bit setting. Some of the scenarios which can adversely affect traffic in a GETVPNGETVPN environment and applicable mitigation techniques are discussed below.
LAN MTU of 1500 – WAN MTU 44xx (MPLS)
In this scenario, even after adding the 50-60 byte overhead, MTU size is much less than the MTU of the WAN. The MTU does not affect GETVPN traffic in any shape or form.
LAN MTU of 1500 – WAN MTU 1500
In this scenario, when IPsec overhead is added to the maximum packet size the LAN can handle (i.e. 1500 bytes) the resulting packet size becomes greater than the MTU of the WAN. The following techniques could help reduce the MTU size to a value that the WAN infrastructure can actually handle.
Manually setting a lower MTU on the hosts.
By manually setting the host MTU to 1400 bytes, IP packets coming in on the LAN segment will always have 100 extra bytes for encryption overhead. This is the easiest solution to the MTU issues but is harder to deploy because the MTU needs to be tweaked on all the hosts.
Configure ip tcp adjst
-mss 1360 on GM LAN interface. This command will ensure that resulting IP packet on the LAN segment is less than 1400 bytes thereby providing 100 bytes for any overhead. If the maximum MTU is lowered by other links in the core (e.g. some other type of tunneling such as GRE is used in the core), the adjust-mss value can be lowered further. This value only affects TCP traffic and has no bearing on the UDP traffic.
Steps to Upgrade Key servers & Group members
This section focuses on the steps to upgrade the IOS and/or IOS-XE versions on the Key Servers and Group Members in a GETVPN network. The intent of these steps is to minimize changes in the TEK and KEK during the upgrades of the Key Servers. Setting the TEK lifetime to 7200 seconds (and KEK 86400 seconds), would give a two-hour window to upgrade the Key Servers where no key changes are needed. If an upgrade of both Key Servers and Group Members is required, it is recommended to start with the Key Servers and then upgrade the Group Members.
Below are the steps:-
- Upgrade a Secondary Key Server.
- Wait for the COOP election to complete till the next Secondary Key Server is upgraded.
- Repeat the above steps to upgrade all Secondary Key Servers in the COOP network. The Secondary Key Servers should reboot and synchronize with the existing Primary Key Server. They should resume their previous role as Secondary Key Server.
- Finally, upgrade the Primary Key Server. The Primary Key Server upgrade will force one of the Secondary Key Servers to be promoted to Primary status. Once the previous Primary reboots, it should assume the role of a Secondary Key Server. It is recommended to complete the Key Server upgrades when there is plenty of time remaining in both the KEK and TEK.
Steps to change RSA keys on Key Servers & Group Members
While changing the RSA keys on the Key Servers, it is recommended to do so using the following steps. This will ensure a smooth transition from the old keys to the new with no traffic disruption.
- Verify that there is sufficient time remaining with the KEK and TEK on the Key Servers. This can be checked using the command ―
ks policy. The intent is to complete the change on all the Key Servers with sufficient time remaining in both the KEK and TEK. If it is not possible to complete the RSA key change within the remaining KEK/TEK lifetime, it is recommended to wait for a rekey before starting the process (steps 2 thru 4 below).
- Remove the RSA keys on all the Key Servers starting with the Primary KS.
- Use the command ‘
ks policy‘ to find the RSA key associated with the gdoi group.
- Use the command ‗
crypto keyzeroize rsa ‘ to delete the RSA key from each of the Key Servers
- Generate an exportable RSA key using the following command on the Primary Key Server:
Primary-KS(config)#crypto key generatersa
modulus 2048 label exportable
- Export the RSA key generated on the Primary Key Server to all Secondary Key Servers.
Here is a sample output of the export and import process using the console option. Instead of the console the keys can be exported to and imported from a TFTP location also.
Export the RSA key on the Primary Key Server:
Primary-KS(config)#crypto key export rsa pem
terminal 3des % Key name: Usage: General Purpose Key Key data: -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCuKbSROW7eSqxC+IjB0ipplVkT .. NtSRSR51ooWQW5CXRwIDAQAB -----END PUBLIC KEY----- -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,B2CE8D823EE52FDC Zi82W/lX3u0WiHN0ezi6qH5Jeo1baptdqzLlVk2jioAyZabWJqc7+svFY+DJ8rT+ ... p3dHnQSBaLu1pH3YI9gebQhMgqH6Ie00ucEYVl4/jArzUjifjdCvkQ== -----END RSA PRIVATE KEY----
Import the RSA key on each of the Secondary Key Servers:
Execute the below command on the configuration prompt of the router. “Passcode” is same as the one used to export the key.
Secondary-KS(config)#crypto key import rsa pem
terminal % Enter PEM-formatted public General Purpose key or certificate. % End with a blank line or "quit" on a line by itself.
% Enter PEM-formatted encrypted private General Purpose key. % End with "quit" on a line by itself. quit !
- Now the next scheduled rekey from the Primary Key Server will be rejected by the Group Members since they still have the old RSA keys. This is the expected behavior. Following is a syslog message displayed on the Group Member when this occurs:
*Jun 5 18:20:22.383: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of GDOI mode failed with peer
- As a result, GMs will re-register with their KSs just before the expiry of their TEK/KEK. After the registration, the Group Members should have the latest policies and keys (including the new RSA keys).
Note: GETVPN configuration and troubleshooting guide coming soon.
For interview question click on the following links