Site icon Networkhunt.com

Cisco GETVPN Concept Explained

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 

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:

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).

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.

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.

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.

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.

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.

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.

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 

GETVPN Data path

Multicast Rekey 

 Time-Based Anti-Replay 

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.

IPSEC

 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.

ip access-list extended get-acl

deny esp any any

deny tcp any any eq tacacs

deny tcp any eq tacacs any

deny tcp any any eq ssh

deny tcp any eq ssh any

! when GM‟s use BGP:

deny tcp any any eq bgp

deny tcp any eq bgp any

! when GM‟s use OSPF:

deny ospf any any

deny pim any 224.0.0.0 0.0.0.255

! NTP unless the IOS hardware clock is made authoritative

deny udp any any eq ntp

deny udp any any eq 500

deny udp any any eq 848

!deny udp any any eq dns ; optional

!deny udp any any eq snmp ; optional

!deny udp any any eq syslog ; optional

permit ip any any

CRL Checking

 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

One needs to configure several components prior to enabling the GETVPN CRL Checking feature. These include:

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:

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.

IKE Authorization

 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:

 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:-

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.

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.

quit

% Enter PEM-formatted encrypted private General Purpose key. % End with "quit" on a line by itself. quit !

GM1#

*Jun 5 18:20:22.383: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of GDOI mode failed with peer at 10.0.8.1

 

 Note: GETVPN configuration and troubleshooting guide coming soon.

For interview question click on the following links

Cisco ISE basic interview question and answer

Cisco FirePower (FTD) Interview Questions and Answers

Information Security interview questions

Cisco Stealthwatch basic interview questions and answers

 

 

 

 

 

Exit mobile version