Chapter 17. Group Encrypted Transport VPN (GET VPN)
Today’s highly integrated and large-scale meshed networks require a secure transport solution that provides instantaneous connectivity between sites without compromising service quality or adding complexity and overhead to the overall network.
In response to this need, Cisco introduced the innovative enhanced encryption solution—Cisco IOS GET VPN—that uses a tunnel-less VPN approach, based on the revolutionary Cisco Group Encrypted Transport (GET VPN) technology.
GET VPN technology offers global enterprise networks the capability to scale voice, video, and data applications with increased network efficiency, any-to-any encrypted connectivity, and highly scalable network environments.
This chapter provides a complete overview of the Cisco IOS GET VPN solution architecture, implementation, and deployment guidelines.
GET VPN Solution Architecture
GET VPN is a revolutionary new concept introduced by Cisco that provides a tunnel-less VPN solution. It is “tunnel-less” because it retains the original IP header of the packet and encrypts only the data payload. To retain the original IP header (including QoS markings), the original header is copied and placed before the IPsec header. GET VPN does not rely on a point-to-point VPN mechanism. By eliminating the need for traditional point-to-point tunnels, networks can further expand with the capability of scaling any-to-any intersite VPN connectivity.
GET VPN, a next-generation encryption technology, is a new category of VPN that offers a standards-based IPsec model that is based on the concept of trusted group members. Routers in a trusted group use a common security methodology that is independent of any point-to-point IPsec tunnel relationship. There is any-to-any dynamic connectivity because the group has already negotiated the security parameters by using a shared key. GET VPN provides end-to-end security for both IP unicast and multicast traffic that traverses a private WAN.
GET VPN offers a secure solution for large-scale, meshed networks by providing encrypted connectivity with higher scalability, increased network performance for latency-sensitive traffic, and always available any-to-any communications among sites.
GET VPN Features
Cisco GET VPN technology offers a wide range of benefits. Key features include the following:
• Easy-to-manage, high-scale, encrypted communications
• Always-on any-to-any intersite connectivity
• Authentication and encryption of both unicast and multicast traffic
• IP header preservation
• Secure packets that use existing routing infrastructure
• Easier distribution and management of security policies
• Prevention of overlay routing
• Provision of an anti-replay feature based on synchronization of pseudotime across group members
• Improved network performance
• Reduced latency for real-time applications
• Networkwide, advanced QoS for encrypted traffic
• Preservation of networkwide QoS and multicast capabilities for improved application performance
• Optimal multicast replication that leverages the core network
• Reduced traffic flows, because multicast is handled natively rather than having to transmit broadcast frames
• Enhanced multilevel fault isolation capabilities
• Management of encryption by either subscribers or service providers
Note
The Cisco GET VPN solution is available from Cisco IOS 12.4(11)T and later on Cisco Integrated Services Routers (ISR) 870, 1800, 2800, and 3800 series routers, as well as on the Cisco 7301 and 7200 series routers.
Table 17-1 shows a summary comparison between traditional point-to-point IPsec tunnel technology and the GET VPN tunnel-less technology.
Table 17-1. Traditional Point-to-Point IPsec and GET VPN Comparison Chart
Figure 17-1 illustrates the concept of GET VPN and relationships with each other.
Figure 17-1. Cisco GET VPN Concept
Why GET VPN?
As mentioned earlier, today’s highly integrated large-scale meshed networks require a solution that provides instantaneous connectivity between sites without compromising service quality or adding complexity and overhead to the overall network.
One of the solutions commonly used to address this is MPLS VPN, which provides secure communication. However, MPLS VPN does not provide end-to-end encryption, which is critical to many applications. Other solutions are DMVPN and Easy VPN to achieve end-to-end encryption, but these solutions are overlay models using point-to-point topology that can introduce delay and suboptimal routing for large-scale meshed networks, thereby causing provisioning limitations and adding overhead to the overall network.
Another alternative solution available to address the overlay model is VRF-aware IPsec (Virtual Routing and Forwarding) on Provider Edge (PE) routers. Again, like MPLS VPN, the limitation of using this model is that it does not provide end-to-end encryption. Traffic is encrypted between the Customer Edge (CE) and PE devices only. Traffic between PE-PE is not encrypted but is secured through MPLS labels, thereby causing additional overhead on PE routes and requiring them to decrypt the traffic before forwarding it to core, and to encrypt the traffic before forwarding to the CE.
GET VPN solution is an efficient alternative to the overlay models and VRF-aware IPsec model, providing end-to-end security on CE routers without using tunnels. GET VPN offers secure encrypted communication for both IP unicast and multicast applications for any-to-any secure connectivity.
GET VPN is WAN-agnostic and can be deployed on any type of network, based on IP, MPLS, Frame Relay, or ATM.
Table 17-2 illustrates the technical advantages of Cisco GET VPN technology.
Table 17-2. Technical Benefits of GET VPN
GET VPN and DMVPN
The GET VPN and DMVPN are complementary solutions. Basic DMVPN provides hub-to-spoke and spoke-to-spoke connectivity using multipoint GRE (mGRE) and Next Hop Resolution Protocol (NHRP) functions. When a spoke needs to send packets to another spoke destination, it queries the NHRP server for real (outside) addresses of the other spoke’s destination so that it can build direct tunnels, thereby bypassing the hub. Until the dynamic tunnel is built, traffic continues to pass through the hub, causing possible delays and suboptimal routing for large-scale meshed networks.
By using GET VPN together with DMVPN, the delay caused by IPsec tunnel negotiation is eliminated because connections are static.
Note
When group keying is applied to the tunnel in a DMVPN context, all tunnel traffic is encrypted with the group key.
GET VPN Deployment Consideration
GET VPN is an enhanced Cisco solution that enables encryption for “native” multicast packets and unicast packets over a private WAN.
GET VPN can be implemented in a variety of deployment models in a range of environments. Consider deploying Cisco GET VPN when
• Deploying latency-sensitive applications
• Deploying applications requiring any-to-any encryption
• Deploying voice or similar collaborative applications
• Securing IP unicast and multicast traffic
• Encrypting data over MPLS networks
• Encrypting data over satellite links
Note
The GET VPN implementation in Internet-based deployments requires DMVPN because it requires public IP addresses.
GET VPN Solution Components
GET VPN solution is a combination of some newly introduced protocols combined with current IPsec standard protocols. The major functional components in GET VPN include the following:
• Group Domain of Interpretation (GDOI): GDOI is a protocol that defines the ISAKMP Domain of Interpretation (DOI) for group key management to support secure group communications. GDOI is the foundation of the GET VPN solution architecture. In a trusted group model, the GDOI protocol operates between a group member and a group controller/key server (GCKS) to establish security associations (SA) among authorized group members. GDOI messages are used to create, maintain, or delete SAs for a group. GDOI protocol uses UDP port 848. GDOI is documented in IETF RFC 3547.
• Group Controller/Key Server (GCKS): GCKS is the router responsible for maintaining the policy and creating and maintaining the keys for the group. When a group member registers, the key server sends the policy and the keys to the group member. The key server also rekeys the group before existing keys expire. The server can send two types of keys: the traffic encryption key (TEK) and the key encryption key (KEK). The TEK becomes the IPsec SA, which is used to communicate with group members within the same group. The TEK key is essentially the group key that is shared by all the group members for secure communication with each other, whereas the KEK is used to encrypt the rekey messages and is used by the group members to decrypt the incoming rekey messages from the key server.
• Group Member: The Group Member is the router that registers with the key server to get the IPsec SA to communicate with other devices in the group. The group member registers with the key server to provide the group ID and receives the security policy and keys for this group from the server.
Figure 17-2 illustrates the basic components of the GET VPN solution.
Figure 17-2. GET VPN Components
How GET VPN Works
Cisco IOS Software-based GET VPN technology is a tunnel-less solution providing end-to-end security for voice, video, and data using the core network’s capability to route the packets between various sites within a fully meshed network.
GET VPN uses the keying protocol Group Domain of Interpretation (GDOI) combined with IPsec standards encryption to encrypt and decrypt the packets, thereby providing an efficient mechanism to secure native (nontunneled) IP multicast and unicast traffic. GET VPN eliminates the requirement of configuring tunnels to secure traffic. The GDOI protocol is the foundation for Cisco GET VPN architecture. GDOI is documented in RFC 3547.
Figure 17-3 illustrates the packet flow, the process of registration, and how group members participate within a group to establish a secure tunnel-less communication:
1 Each group member sends a registration request to the key server. Using the GDOI protocol, the key server authenticates and authorizes the group member and sends the IPsec policy and the keys that are required to encrypt and decrypt IP multicast and unicast packets.
2 After the group member is registered with the IPsec SA, and upon receiving the respective keys, group members can directly exchange encrypted IP multicast and unicast packets with each other, bypassing the key server, thus establishing secure communication. The traffic encryption key (TEK) is used by all the group members to communicate securely.
3 As needed, the key server sends a rekey message to all the group members within the group. The rekey message contains the new IPsec policy and keys that are used when the outdated IPsec SA expires. Rekey messages are sent in advance of the SA expiration time to ensure that valid group keys are always available.
Figure 17-3. GDOI Registration Flow and Tunnel-less Encrypted Communication
The GDOI protocol is used between the key server and a group member to distribute the security policy (IPsec SA) and keys within the group. The key server is responsible for creating and maintaining the IPsec SA and keys and downloading the IPsec SA and keys to the authenticated group members. The authenticated group members can then communicate with each other (within the same group) by using the IPsec SA received from the key server.
As shown in Figure 17-4, the GDOI protocol is protected by an ISAKMP Phase 1 exchange. The GDOI key server and the GDOI group member must have the same ISAKMP policy. Figure 17-4 shows the GDOI protocol four-message exchange that follows the Phase 1 ISAKMP policy.
Figure 17-4. GDOI Registration Protected by ISAKMP Phase 1
As shown in Figure 17-4, the entire GDOI registration process includes the ISAKMP Phase 1 message and the four GDOI protocol messages, which are protected by ISAKMP Phase 1.
The GDOI registration process is a unicast exchange that uses UDP port 848 (with NAT-T, it floats to port 4500).
During the GDOI registration process, each group member also receives the address of the multicast group, and each member registers with the multicast group that is required to receive the multicast rekeys. After the registration is successful, the key server sends a multicast rekey to all the group members that have registered within a group.
IP Header Preservation
One of the main attributes and advantages of using GET VPN is that it offers header preservation. Packets protected by IPsec in GET VPN retain the original source and destination addresses in the “outer” IP header, rather than replacing them with tunnel endpoint addresses. This is why this approach is called “tunnel-less” technology, because it retains the original IP header of the packet and encrypts only the data payload. To retain the original IP header, the original header is copied and placed before the IPsec header. Figure 17-5 depicts this function.
Preserving the original header is largely suited for optimal routing in an enterprise network running over a private MPLS/IP-based core network.
Figure 17-5. IP Header Preservation
Group Member ACL
Traffic that requires encryption is statically defined on the key server through an access control list (ACL). This policy is defined for both unicast and multicast traffic. The ACL determines which traffic is encrypted. The information is sent to all authenticated group members to create a trusted domain of communication. Policies that are downloaded from the key server are appended to the locally configured ACL on the group member. Any ACL that is configured locally on the group member takes precedence over what is downloaded from the key server.
Cisco recommends using a private subnet addressing scheme from a single major network for all the inside network interfaces on the group members that require protection. For example, use a Class A major net 10.0.0.0/8 for all LAN interfaces behind the group members. Subnet the Class A into smaller chunks of /24 subnets for each member site, and so on. This will greatly reduce the complexity of defining the policy on the key server. With a contiguous network block, you can define one ACL permit statement—for example, access-list 101 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255—to represent all the private subnets in your network behind each group member. If group members use the same contiguous network block for all private LAN interfaces, they will install only one summarized SA for the 10.0.0.0/8 in the database. If different network blocks are used, separate SAs need to be installed for each subnet block.
The key server is flexible in its capability to change the policy dynamically as needed, when newer networks are introduced and group members are dynamically updated with new security policy.
Implementing Cisco IOS GET VPN
Based on the illustration shown in Figure 17-6, the following configuration examples provide deployment guidelines for implementing a Cisco IOS GET VPN solution in an any-to-any design, thereby offering end-to-end CE-CE encryption in an MPLS VPN network environment.
Figure 17-6. Implementing Cisco IOS GET VPN
Example 17-1 shows the Key-Server-1 configuration.
Example 17-2 shows the Key-Server-2 configuration.
Example 17-3 shows the Group-Member-1 configuration.
Example 17-4 shows the Group-Member-2 configuration.
Example 17-5 shows the Group-Member-3 configuration.
The topology shown in Figure 17-6 is used in Examples 17-1 through 17-5 to demonstrate an intranet VPN scenario. The MPLS VPN core interconnects VPN sites as shown in Figure 17-6. The CE/CPE routers (Group Members 1 through 3) on each VPN site are grouped into a single GDOI group that correlates with the VPN of which these sites are a part. All the key servers and group members are part of the same VPN. Key-Server-1 is the primary key server and Key-Server-2 is the secondary key server.
Example 17-1. Configuring Cisco IOS GET VPN Key-Server-1 Router—Primary
hostname KeyServer-1
!
<..>
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp key cisco address 100.1.1.5
crypto isakmp key cisco address 100.1.1.9
crypto isakmp key cisco address 100.1.1.13
crypto isakmp key cisco address 100.1.1.17
!
crypto ipsec transform-set mygdoi-trans esp-3des esp-sha-hmac
!
crypto ipsec profile gdoi-profile-getvpn
set security-association lifetime seconds 1800
set transform-set mygdoi-trans
!
crypto gdoi group getvpn
identity number 1234
server local
rekey lifetime seconds 86400
rekey retransmit 10 number 2
rekey authentication mypubkey rsa getvpn-export-general
rekey transport unicast
sa ipsec 1
profile gdoi-profile-getvpn
match address ipv4 199
replay counter window-size 64
replay time window-size 5
address ipv4 100.1.1.1
redundancy
local priority 100
peer address ipv4 100.1.1.5
!
interface Ethernet0/0
description Outside interface to PE1
ip address 100.1.1.1 255.255.255.252
!
ip classless
ip route 0.0.0.0 0.0.0.0 100.1.1.2
!
access-list 199 remark ACL policies to be pushed to authenticated group members
access-list 199 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255
!
<..>
Example 17-2. Configuring Cisco IOS GET VPN Key-Server-2 Router—Secondary
hostname KeyServer-2
!
<..>
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp key cisco address 100.1.1.1
crypto isakmp key cisco address 100.1.1.9
crypto isakmp key cisco address 100.1.1.13
crypto isakmp key cisco address 100.1.1.17
!
crypto ipsec transform-set mygdoi-trans esp-3des esp-sha-hmac
!
crypto ipsec profile gdoi-profile-getvpn
set security-association lifetime seconds 1800
set transform-set mygdoi-trans
!
crypto gdoi group getvpn
identity number 1234
server local
rekey lifetime seconds 86400
rekey retransmit 10 number 2
rekey authentication mypubkey rsa getvpn-export-general
rekey transport unicast
sa ipsec 1
profile gdoi-profile-getvpn
match address ipv4 199
replay counter window-size 64
replay time window-size 5
address ipv4 100.1.1.5
redundancy
local priority 75
peer address ipv4 100.1.1.1
!
interface Ethernet0/0
description Outside interface to PE2
ip address 100.1.1.5 255.255.255.252
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.6
!
access-list 199 remark ACL policies to be pushed to authenticated group members
access-list 199 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255
!
<..>
Example 17-3. Configuring Cisco IOS GET VPN Group-Member-1 Router
hostname GroupMember-1
!
<..>
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp key cisco address 100.1.1.1
crypto isakmp key cisco address 100.1.1.5
!
crypto gdoi group getvpn
identity number 1234
server address ipv4 100.1.1.1
server address ipv4 100.1.1.5
!
crypto map getvpn-map 10 gdoi
set group getvpn
!
interface Ethernet0/0
description Outside interface to PE3
ip address 100.1.1.9 255.255.255.252
crypto map getvpn-map
!
interface Ethernet0/1
description Inside interface
ip address 10.1.11.1 255.255.255.0
!
router bgp 1111
no synchronization
bgp log-neighbor-changes
network 10.1.11.0 mask 255.255.255.0
neighbor 100.1.1.10 remote-as 1000
no auto-summary
!
<..>
Example 17-4. Configuring Cisco IOS GET VPN Group-Member-2 Router
hostname GroupMember-2
!
<..>
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp key cisco address 100.1.1.1
crypto isakmp key cisco address 100.1.1.5
!
crypto gdoi group getvpn
identity number 1234
server address ipv4 100.1.1.1
server address ipv4 100.1.1.5
!
crypto map getvpn-map 10 gdoi
set group getvpn
!
interface Ethernet0/0
description Outside interface to PE4
ip address 100.1.1.13 255.255.255.252
crypto map getvpn-map
!
interface Ethernet0/1
description Inside interface
ip address 10.1.12.1 255.255.255.0
!
router bgp 2222
no synchronization
bgp log-neighbor-changes
network 10.1.12.0 mask 255.255.255.0
neighbor 100.1.1.14 remote-as 1000
no auto-summary
!
<..>
Example 17-5. Configuring Cisco IOS GET VPN Group-Member-3 Router
hostname GroupMember-3
!
<..>
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp key cisco address 100.1.1.1
crypto isakmp key cisco address 100.1.1.5
!
crypto gdoi group getvpn
identity number 1234
server address ipv4 100.1.1.1
server address ipv4 100.1.1.5
!
crypto map getvpn-map 10 gdoi
set group getvpn
!
interface Ethernet0/0
description Outside interface to PE5
ip address 100.1.1.17 255.255.255.252
crypto map getvpn-map
!
interface Ethernet0/1
description Inside interface
ip address 10.1.13.1 255.255.255.0
!
router bgp 3333
no synchronization
bgp log-neighbor-changes
network 10.1.13.0 mask 255.255.255.0
neighbor 100.1.1.18 remote-as 1000
no auto-summary
!
<..>
The following show commands can be used to verify functionality on key-server (ks) and group-members (gm).
• show crypto isakmp sa
• show crypto gdoi
• show crypto gdoi ks acl
• show crypto gdoi ks members
• show crypto gdoi ks policy
• show crypto gdoi ks rekey
• show crypto gdoi ks replay
• show crypto gdoi ks coop
• show crypto session detail
• show crypto gdoi gm acl
• show crypto gdoi gm rekey
• show crypto gdoi gm replay
Summary
As demand for VPN implementation grows, organizations with large-scale, full-meshed networks require scalable and instantaneous cryptographic solutions that interconnect sites with robust security, without compromising service quality or adding complexity and overhead to the overall network.
Cisco introduced the groundbreaking new category of VPN technology, which is a tunnel-less approach, based on the revolutionary Cisco IOS Group Encrypted Transport (GET VPN) solution, which provides end-to-end security for voice, video, and data in a highly scalable network environment.
Through numerous examples and diagrams that explain how it works, this chapter provides a comprehensive explanation of the Cisco IOS GET VPN solution architecture and components that make up the GET VPN solution.
The chapter presents implementation guidelines for deploying the Cisco IOS GET VPN solution that offers end-to-end encryption in an MPLS VPN network environment, providing sample configurations from key servers and group members.
References
http://www.cisco.com/go/getvpn
http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a008078e4f9.html
http://www.cisco.com/en/US/products/ps6635/products_white_paper0900aecd805cc40d.shtml
http://www.cisco.com/en/US/products/ps6635/products_qanda_item0900aecd80582072.shtml
http://www.cisco.com/application/pdf/en/us/guest/products/ps7180/c1161/cdccont_0900aecd8058203e.pdf
http://www.cisco.com/application/pdf/en/us/guest/products/ps7180/c1161/cdccont_0900aecd80582031.pdf
http://www.cisco.com/application/pdf/en/us/guest/products/ps7180/c1031/cdccont_0900aecd80582078.pdf
http://www.cisco.com/application/pdf/en/us/guest/products/ps7180/c1031/cdccont_0900aecd80582078.pdf