get-vpn

To provide a true full mesh or even dense partial mesh of connectivity, tunnel-based solutions require the provisioning of a complex connectivity mesh. Such a complex mesh not only has higher processor and memory requirements, but is difficult to provision, troubleshoot, and manage.

Cisco‘s 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. The IETF standard RFC-3547 Group Domain of Interpretation (GDOI) is an integral part of GETVPN. The GDOI protocol was introduced in 12.4(2)T but the GET VPN solution with several enhancements was released in 12.4(11)T.

Following are some of the advantages of GETVPN over other VPN technologies:

  • Provides highly scalable any to any mesh topology natively and eliminates the need for complex peer-to-peer security associations.
  • For Multiprotocol Label Switching (MPLS) networks, maintains network intelligence (such as full-mesh connectivity, natural routing path, and QoS). Grants easy membership control with centralized key servers.
  • Helps ensure low latency and jitter by enabling full-time, direct communications between sites, without requiring transport through a central hub.
  • GETVPN allows replication of the packets after encryption. This allows the multicast traffic to be replicated at the core, thereby reducing the load and band width requirement on the Customer Premises Equipment (CPE).
  • IP Address Preservation enables encrypted packets carry the original source and destination IP addresses in the outer IP header rather than replacing them with tunnel endpoint addresses. This technique is known as IPSec Tunnel Mode with Address Preservation. Some of the IP header parameters are also preserved. Many network features like routing, basic firewall, QoS, traffic management etc. work based on the information contained in the IP header. Since the IP header is persevered, all the network features will work as before. This eliminates lot of issues associated with deploying point to point encryption in a core network

GROUP ENCRYPTED TRANSPORT

get-vpn-a get-vpn-b

GET VPN:

  • Suitable only in PRIVATE network, because it preserves original header
  • QOS is possible because GETVPN preserves original header
  • It eliminates POINT-TO-POINT VPN (site-site), overlay vpn (DMVPN)

get-vpn-c

Centralized location for interesting traffic

Cisco‘s Group Encrypted Transport VPN (GET VPN) 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 GET VPN networks, there is no need to negotiate point-to- point IPsec tunnels between the members of a group, because GET VPN is ―tunnel-less. ● GDOI (RFC 3547) ● Key servers (KSs) ● GMs ● IP tunnel header preservation ● Group security association ● Rekey mechanism ● Time-based anti-replay (TBAR)

The GDOI group key management protocol is used to provide a set of cryptographic keys and policies to a group of devices. In a GET VPN 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 a Phase 1 Internet Key Exchange (IKE) SA. All participating VPN gateways must authenticate themselves to the device providing keys using IKE. GDOI introduces two different encryption keys. One key secures the GET VPN 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).

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 GET VPN, 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. Used in wan, not suitable for internet.

Key Server (KS)

A key server (KS) is an IOS device responsible for creating and maintaining the GET VPN 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 Phase 1 (pre-shared keys or PKI) and then download the encryption policies and keys required for GET VPN 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, whether or not the GM owns that network.

Group Member (GM)

A GM is an IOS router responsible for actual encryption and decryption i.e. a device responsible to handle GETVPN data plane. A GM is only configured with IKE phase 1 parameters and KS/Group information.

Group SA

Unlike traditional IPsec encryption solutions, GET VPN uses the concept of group SA. All members in the GET VPN 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. Note: In a GET VPN group, up to 100 ACL permit entries can be used to define interesting traffic for encryption. Each permit entry results in a pair of IPsec SAs; the maximum number of IPsec SAs in a group cannot exceed 200.

Rekey Process

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. GET VPN 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 60 seconds before the existing IPsec SAs expire. 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.

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 to active GMs. If a GM does not acknowledge three consecutive rekeys (retransmissions are considered part of the rekey), the KS removes the GM from its active GM database and stops sending rekey messages to that GM.

Multicast Rekey

In the multicast rekey process, a KS generates a rekey message and sends one copy of the message to a multicast group address that is predefined in the configuration. Each GM joins the multicast group at registration time, so each GM receives a copy of the rekey message. Unlike unicast rekey, multicast rekey does not have an ACK mechanism.

Time Based Anti-Replay (TBAR)

GET VPN uses time-based anti-replay (TBAR), which is based on a pseudo-time clock that is maintained on the KS. An advantage of using pseudotime for TBAR is that there is no need to synchronize time on all the GET VPN devices using NTP. The primary KS is responsible for establishing and maintaining the pseudo-time for a group. The primary KS must also keep pseudotime synchronized on all GMs via rekey updates. Every GM includes its pseudo-time as a time stamp in the data packets. A receiving VPN gateway then compares time stamp of the received packet with the GM reference pseudotime clock it maintains for the group. If the packet arrived too late, it is dropped.

Fail-Close Mode

Until a group member registers with a key server, traffic passing through the group member is not encrypted. This state is called “fail open.” To prevent unencrypted traffic from passing through a group member before that member is registered, you can configure the Fail-Close feature. If the feature is configured, an implicit “permit ip any any” policy is installed, and all unencrypted traffic passing through the group member is dropped (this state is called fail-close mode).

  • Group Encrypted Transport
  • Cisco Proprietary
  • Components:
    • GDOI (Group Domain of Interpretation) [RFC 3547]
      • It is a protocol used to share keys
      • It runs on protocol UDP 848
      • ISAKMP Phase 1 protects GDOI
      • GDOI has 2 keys:
        • Key Encryption Key (KEK) [KS –> GM]
        • Traffic Encryption Key (TEK) [GM <–> GM]
    • Key Servers (KS)
      • It generates Keys for encryption
      • It is used for policy generation, which guides as to which traffic needs to be encrypted and what encryption algorithm to use
    • Group Member (GM)
    • Rekeying
      • It is a process of retransmission of keys by Key Server
      • There are 2 types:
        • Unicast: Where KS sends keys to GM and GM replies with ACK
        • Multicast: Where KS sends keys to multicast address 239.0.0.0 and GMs registered to that address receives it. No ACK!
    • Time based Anti Replay
      • It is a mechanism to prevent Replay attack
      • It uses metadata to create a psuedo clock which times the time between transmission and reception.
      • IPSec sequence number technique does not work because in GET VPN a group SA is formed and the communication happens with multiple GM’s and the sequence numbers will not be continuous
    • IP Header preservation makes a copy of the Tunnel IP header and uses it in the IP (Hence not suitable on the Internet, to be used only on WAN.

get-vpn-d

TASK: Configure GET VPN for the topology given below

get-vpn-e

  1. Please do the initial configuration on the routers by assigning ip addresses as shown above
  2. Please define static routes on all the devices such that R3 and R4 should know the R1 ip address of 10.1.12.1 (Key Server) and should use R2 as the next hop to reach each other’s loopback address
  3. Please note: Due to the IP Address preservation property of GET VPN (as defined above), R2 needs to know routes to the loopbacks of R3 and R4

Let us first start with Key Server Configuration

First let us generate an RSA 1024 length key

R1(config)# ip domain-name cisco.com
R1(config)# crypto key generate rsa modulus 1024 label GET_KEY

Now let us start configuration for Phase 1 - ISAKMP Policy

R1(config)# crypto isakmp policy 10
    R1(isakmp-policy)# authentication pre-share
R1(config)# crypto isakmp key 0 GET_R3 address 10.1.23.3
R1(config)# crypto isakmp key 0 GET_R4 address 10.1.24.4

Now let us configure the Phase 2 - IPSec Transformset and Profile

R1(config)# crypto ipsec transform-set TSET esp-3des esp-sha-hmac
R1(config)# crypto ipsec profile GET_PRO
    R1(ipsec-profile)# set transform-set TSET

Now it is time to configure the Key Server

R1(config)# crypto gdoi group GET_VPN
    R1(config-gdoi-group)# identity number 134
    R1(config-gdoi-group)# server local // At this point the GDOI will get enabled
        R1(gdoi-local-server)# rekey authentication mypubkey rsa GET_KEY
        R1(gdoi-local-server)# rekey retransmit 10 number 2
        R1(gdoi-local-server)# rekey transport unicast
        R1(gdoi-local-server)# authorization address ipv4 GM-LIST // A standard ACL with a list of Group Member's IP Address
        R1(gdoi-local-server)# address ipv4 10.1.12.1 // Key Server's IP Address
        R1(gdoi-local-server)# sa ipsec 1
            R1(gdoi-sa-ipsec)# profile GET_PRO
            R1(gdoi-sa-ipsec)# match address ipv4 LAN_LIST // The extended ACL controlling traffic (to be encrypted or not)
            R1(gdoi-sa-ipsec)# replay counter window-size 64
R1(config)# ip access-list standard GM_LIST
    R1(config-std-nacl)# permit 10.1.23.3
    R1(config-std-nacl)# permit 10.1.24.4
R1(config)# ip access-list extended LAN_LIST
    R1(config-ext-nacl)# deny udp any eq 848 any eq 848 // Telling the GM's not to encrypt traffic between GM and KS
    R1(config-ext-nacl)# permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255 // The interesting traffic between loopbacks of GMs

Now let us configure the Group Member

Please Note: The beauty of GET VPN is that the configuration on all the GMs are identical! The only change in configuration is for the peer password. In the following commands ‘Rx’ denotes both R3 and R4

Rx(config)# crypto isakmp policy 10
    Rx(isakmp-policy)# authentication pre-share
R3(config)# crypto isakmp key 0 GET_R3 address 10.1.12.1
OR
R4(config)# crypto isakmp key 0 GET_R4 address 10.1.12.1
Rx(config)# crypto gdoi group GET_VPN
    Rx(config-gdoi-group)# identity number 134
    Rx(config-gdoi-group)# server  address ipv4 10.1.12.1
Rx(config)# crypto map CMAP 10 gdoi
    Rx(config-crypto-map)# set group GET_VPN
Rx(config)# interface f0/0
    Rx(config-if)# crypto map CMAP // As soon as you apply the map to the interface, GDOI negotiation will happen with the KS as shown in syslog