The Cisco IOS® Software-based Group Encrypted Transport Virtual Private Network (Cisco IOS GET VPN) is a tunnel-less technology that provides end-to-end security for voice, video, and data in a native mode for a fully meshed network. It uses the core network's ability to route and replicate the packets between various sites within the enterprise. Cisco IOS GET VPN preserves the original source and destination addresses in the encryption header for optimal routing; hence, it is largely suited for an enterprise running over a private Multiprotocol Label Switching (MPLS)/IP-based core network. Cisco IOS GET VPN uses Group Domain of Interpretation (GDOI) as the keying protocol for encrypting and decrypting the data packets.
The Cisco® Enterprise-Class Teleworker (ECT) solution is a highly scalable Cisco IOS Software-based solution that securely integrates the network infrastructure, management infrastructure, managed services, and applications across the entire enterprise, including LAN, WAN, branch, and teleworker locations.
The solution is an integral part of the Cisco Service-Oriented Network Architecture (SONA), a framework that enables enterprise customers to build integrated systems across a fully converged, intelligent network. Using the Cisco SONA framework, the enterprise network can evolve into an Intelligent Information Network-one that offers the kind of end-to-end functions and centralized, unified control that promote true business transparency and agility.
Cisco has successfully deployed the ECT solution within its own organization, increasing productivity and improving efficiency while enabling "zero-touch" deployment, manageability, and low-to-negative total cost of ownership (TCO). Enterprises and service providers can use the Cisco ECT solution to offer the benefits of network services to their end users and customers, while maintaining an effective ROI.
This deployment guide covers the integration of Cisco IOS GET VPN within the Cisco ECT/SONA framework. The ECT `teleworker' is broadly viewed as the remote branch office for this purpose. Cisco IOS GET VPN is the baseline solution (Figure 1), interconnecting remote branch offices to the corporate network using private MPLS core along with manageability, applications, and services enabled by Cisco ECT.
Figure 1. Cisco ECT Solution Overview
Document Scope
This document provides deployment guidelines to enable Cisco IOS GET VPN in an enterprise network. This document does not cover in-depth technical details about various features comprising Cisco IOS GET VPN. Please refer to the References section for more details.
Why GET VPN?
Enterprise customers face numerous security challenges based on their network application and connectivity requirements. Though MPLS VPNs can provide a certain level of security, many critical applications need end-to-end encryption as well. Some solutions involving Dynamic Multipoint Virtual Private Network (DMVPN) or Enhanced Easy VPN can be used to achieve end-to-end encryption, but these are basically an overlay "hub-and-spoke" model. This could introduce sub-optimal routing even for a fully meshed deployed network using MPLS, delay setting up a full mesh of connections among all sites, and result in sub-optimal support for multicast causing scaling limitations and provisioning and troubleshooting overheads.
An alternative to the overlay model is to deploy virtual routing and forwarding (VRF)-aware IP security (IPsec) on provider edge (PE) routers. Here, the traffic is encrypted only between customer edge (CE) and provider edge routers. The traffic is not encrypted between provider edge routers, but is secured using MPLS labels. This has an additional overhead for provider edge routers, requiring them to decrypt the traffic before forwarding it to the core, and to encrypt the traffic before forwarding it to customer edge routers.
Cisco IOS GET VPN is a group key-based solution that provides end-to-end security for both unicast and multicast applications. Cisco IOS GET VPN is enabled in customer edge routers without using tunnels; it is a better solution than the overlay and VRF-aware IPsec solutions.
The GDOI protocol is the foundation for Cisco IOS GET VPN. GDOI is documented in RFC3547. For more information, visit http://www.ietf.org/rfc/rfc3547.txt.
• Centralized management of policies and keys in the key server
• End-to-end security for voice, video, and data
• Any-to-any enterprise connectivity for critical applications
• Optimal routing by preserving source and destination addresses in the encryption header
• Flexibility to use unicast or multicast rekey mechanisms based on the core network support
• Multicast encryption in native mode
• Uses (requires) multicast replication in the MPLS/IP core, removing the need for a group member to replicate multiple copies for each receiver (such as a hub in a hub-and-spoke tunneled network)
• Less overhead in PE routers; they do not need to decrypt/encrypt traffic
• Efficient distribution of rekeys using multicast transport
• Zero-touch provisioning in key server for addition of new group members if planned addressing schemes are in place
• Redundancy in key server failure by using cooperative key server feature
• Prevention of replay attacks
• Selective bypass of encryption using group member ACL
• Scalable security solution for large-scale networks
Deployment Considerations
Network Addressing
It is recommended to use subnets of a single major network for the inside interfaces of all group members. This way, a simple policy can be defined in the key server, for example: `permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255'. This helps the group members to install a single IPsec SA for the entire network. This also eases the key server management when new group members are added. Network reachability between the group members and the key servers are critical. Routing must be set up properly before enabling the routers for the Cisco IOS GET VPN.
Group Rekey Using Unicast Transport
If any part of the enterprise network is not multicast-capable either due to the core or the enterprise itself, it is recommended to use the unicast transport mechanism to distribute rekeys for all group members. The key server will send a separate rekey for every group member and the group member must respond to the key server with an acknowledgement. The key server will retransmit rekeys if it did not receive the acknowledgement from the group member.
The number of retransmit attempts and the interval are user-configurable. If the key server did not receive the acknowledgement for up to three rekeys from a group member, no further rekeying is sent to that group member. The group member has to re-register with the key server to be able to receive the latest policies for the group.
Note: If the network is large, it poses a load on the key server to send unicast rekey messages and process the acknowledgements received from every group member.
The key server maintains all the registered group members in the database and tracks the number of rekeys sent and acknowledged per group member. This also helps to troubleshoot any issues with a specific group member.
Group Rekey Using Multicast Transport
To use multicast transport, the entire network must be multicast-capable, including the MPLS/IP core. That is to say, multicast VPN (mVPN) is required in the MPLS core. To understand more about mVPN, please visit the link provided in the References section.
When it is time for the key server to send out rekeys to the group members, it sends out a single rekey packet to the core and the core does the replication for all the group members. Since there is no acknowledgement sent by the group member, it is recommended to retransmit the rekeys an additional 2 or 3 times during every rekey period. Using multicast transport is efficient and highly recommended for a larger network as it uses the multicast replication provided by the core. In turn, it reduces the load on the key server to process the rekey messages for each group member and the acknowledgements received from every group member. Moreover, the group member does not send any acknowledgements as required in the unicast transport mechanism.
Note: If the network is large and a small part of the network is not multicast-capable, the customer can still use the multicast transport mechanism for rekeying. This will cause that small set of group members to re-register, but this poses a little load on the key server when compared to the load the key server will have if the entire network is using unicast transport. Each unicast group member forced to re-register will do so before the current group key expires. This avoids any loss of data traffic.
Group Member Access Control List
Group member access control lists (ACLs) are optionally required on selective group members to permit exceptions to the key server policy. Ideally, the use cases for this ACL are to permit routing protocol packets and any other control traffic between the customer edge and provider edge routers unencrypted or to allow unencrypted traffic between the key server and the group member due to the network topology and addressing. The ACL must contain only "deny" statements to allow the specified traffic to go in the clear text; "permit" statements are not allowed. To help understand the usage, a group member ACL is deployed in this configuration.
Cooperative Key Server
This feature of Cisco IOS GET VPN synchronizes the policies and keys distributed by several cooperating key servers deployed in the network. There can be a maximum of 8 key servers. Only one key server can act as the primary, which coordinates the actions of the group. The key servers can be placed anywhere within the enterprise network as long as they are reachable. There are two reasons for keeping multiple key servers: so the group member can register with the nearest key server, and for key server redundancy.
From the key server perspective, if the primary key server goes offline due to network partition or device failure, one of the remaining key servers will assume the role of primary based on an election and start distributing the rekeys. The election of the primary key server is based on the highest priority, which is configurable. In case of more than one key server having the same highest priority, the election is based on the highest IP address. However, if the previous primary key server comes back online, it will only assume the role of secondary. It will not immediately become the primary again. In case of a network partition, it is quite possible that two or more key servers may function as the standalone primaries. Hence during the network rejoin, a new primary is selected for the network. It is a rare case scenario for all 8 key servers to become primaries and involved in a network rejoin.
Note: Rekey configuration, policies defined, and anti-replay configurations must be identical in all key servers.
Multiple Key Servers Configured in Group Member
From the group member perspective, the group member tries to register with the first key server listed in the configuration. If the first key server listed is not reachable, the group member then tries to reach the next key server listed in its configuration. The group member keeps trying this way until it can successfully register with one of the key servers. However, only the primary key server will send further rekeys to the entire network.
Note: In case of bringing up the network for the first time, it is recommended to enable cooperative key server first. Once the primary and secondary key servers are running with the policies and the group keys synchronized, the selective group members can be configured with primary or secondary key servers for further registrations. For the network comprising multiple standalone key servers, enabling cooperative key server will be treated as network merge and the newly elected primary will send out rekeys to all group members. In case of adding a new key server and a set of new group members to the existing network, it is advisable to bring up cooperative key servers first and then to configure group members with respective key servers for registrations.
Time-Based Anti-Replay
Cisco IOS GET VPN uses a time-based anti-replay mechanism to protect the group members from replay attacks in a multisender environment. The time window, within which the group member accept the packets, is user-configurable up to 100 seconds. It is highly recommended to use the default value of five seconds for better protection. Time-based anti-replay must be enabled manually. The replay method and the time window must be the same in all the cooperative key servers.
Manageability
Managing the key server and the group member can be done using a separate dedicated IPsec tunnel, either by the enterprise itself or by the service provider. The management traffic should be excluded from the key server policy. Refer to the Management section for more details.
Network Infrastructure
Recommended Platforms and Images
Images based on Cisco IOS Software Release 12.4(11)T are recommended for both key server and group member routers. The recommended image subset is `adventerprisek9' for both the key server and the group member routers.
Key server: Cisco 2800/3800 Series Integrated Service Routers, Cisco 7200 Series Routers, Cisco 7301 Routers
Group member: Cisco 1800/2800/3800 Series Integrated Service Routers, Cisco 7200 Series Routers, Cisco 7301 Routers
Note: The Cisco 871 Integrated Service Router can also be used as a group member if the customer is deploying this solution with very few IPsec SAs (1 to 3). In case of using more IPsec SAs and if a multiple rekey happens in the network before the expiration of existing IPsec SAs, the group member may easily override the hardware resources of the Cisco 871 and further policies may not be installed properly. This is purely a hardware limitation.
Topology
Figure 2. Modified ECT Topology with GET VPN (Logical View)
Deployment
1. Baseline Solution
From the Cisco IOS GET VPN deployment perspective, the IP/MPLS core is just a transport medium. Hence, the enterprise customer just needs to configure the key server and group members in their networks. In most cases, the key server and group members are the customer edge routers maintained by the customer. The customer edge router, acting as a group member, will encrypt the multicast traffic and forward it to the MPLS core for replication. The MPLS core is responsible for multicast packet replication for all other group members distributed across the core. This can be achieved only if the original data source and destination networks are routable, since the original network addresses are used on the IPsec/IP header (header preservation) after encrypting the multicast packet.
Figure 3. Enterprise Network Topology Using GET VPN (Physical View)
This deployment shows the configuration steps required for an enterprise-owned key server solution using a single group. This deployment is based on the ECT topology shown above (Figure 3) for enabling end-to-end security between the corporate network and multiple branches running over the MPLS core. The core network is enabled with MPLS/VPN and mVPN technologies to provide both unicast and multicast security for the enterprise VPN network. As shown in the topology, two key servers are deployed and connected to different provider edge routers and the group members are configured with the nearest key server.
Pre-requisites
• The enterprise network must have full network reachability between the routers configured as key server and group member.
• Customer edge routers should be configured for a group member or key server based on the deployment.
• Port UDP 848 must be open in the firewall located in front of group members and key servers for successful GDOI protocol registration.
• To use multicast data encryption and group rekeying through multicast transport, the core must support end-to-end multicast. For the MPLS core, multicast VPN must be enabled in the core.
• Protocol Independent Multicast (PIM) sparse-mode must be enabled in the provider edge-facing interfaces of the group members and the key servers.
• PIM Rendezvous Point (RP) must be reachable from all the group members and the key servers for the multicast group address used for group rekeying.
• DNS, NTP, PKI, and AAA servers must be reachable in the network.
This deployment has integrated PKI, PKI AAA, Cisco IOS Firewall, Context-Based Access Control (CBAC), Dynamic Host Configuration Protocol (DHCP) Server, Network Address Translation (NAT) for Internet-bound traffic, and quality of service (QoS) for prioritizing voice traffic, along with Cisco IOS GET VPN to demonstrate a complete Cisco ECT solution. Complete configuration for these features is provided in the Full Configuration section.
Key Server Configuration
!!!! Before starting key server configuration, generate the RSA key used for rekey. !!!!
!!!! The following configuration enables the key server in a router. Each group defined in the key server has an identity that is shared among the members within the group. Here the identity is set to 1234 for group `GROUP-VPN'. The key server also defines the policies using access-list sa-acl to be distributed to group members upon registration. Further rekeys are sent through unicast transport mechanism with 2 more retransmits at 10 seconds apart. The key server uses this retransmit configuration to resend rekeys in case the acknowledgements are not received from the group member for the rekey sent earlier. The lifetime validity of rekey policy is configured for 3 hours. Time-based anti-replay is enabled with default 5 seconds. !!!!
!
crypto gdoi group GROUP-VPN
identity number 1234
server local // local keyword identified this router as key server //
rekey lifetime seconds 10800 // lifetime of rekey policy set to 3 hours //
rekey transport unicast // Rekeying through unicast transport //
sa ipsec 1
profile vpnprof // Negotiates transform-set for group members //
match address ipv4 sa-acl // Policies downloadable to group members //
replay time window-size 5 // Time based anti-replay with 5 sec //
address ipv4 10.10.10.23 // This is the source address of the rekey packet //
Note: The policies defined in the key server are downloaded to all group members irrespective of which group member has the network addresses defined in the policy. As you can see below, this deployment use multiple policies to showcase the configuration required when using multiple networks. However, it is highly recommended to use a single major network as mentioned in the previous note.
!!!! ISAKMP and IPsec profile configuration are defined below. The lifetime configuration for the group IPsec SA is defined under the `crypto ipsec profile' configuration below. This configuration uses the default value of 1 hour and hence it is not explicitly shown here. This deployment uses PKI certificates for authentication; PKI-related configurations are shown in the Full Configuration section later in the document. !!!!
!!!! The following configuration shows that there is no crypto map associated with any physical interface. !!!!
!
interface Loopback0
ip address 10.10.10.23 255.255.255.255
ip pim sparse-dense-mode
!
interface GigabitEthernet0/1
description Connected to PE2
ip address 10.10.10.26 255.255.255.252
ip pim sparse-dense-mode
duplex auto
speed auto
media-type gbic
negotiation auto
!
!!!! The following ACL defines the policies to be pushed to group members.
Note: The policies are defined for both unicast and multicast data. The group members use subnets within 10.1.0.0 to 10.1.3.255 for inside interfaces and the corporate network has multiple major networks, including other subnets of 10.0.0.0/8 and 172.16.0.0, 192.168.0.0 networks. Since both the inside interfaces and the CE-PE interfaces fall under the same major network 10.0.0.0/8, only the inside interface subnets are defined in the policy for encryption. In addition, the group member at the corporate network needs the IPsec SA to support the traffic from corporate to branches. This is why the ACL contains mirrored entries. It is highly recommended to use a single major network for the entire network to reduce these ACL entries. !!!!
!
ip access-list extended sa-acl
permit ip 10.1.0.0 0.0.3.255 10.0.0.0 0.255.255.255
permit ip 10.1.0.0 0.0.3.255 192.168.0.0 0.0.255.255
permit ip 10.1.0.0 0.0.3.255 172.16.0.0 0.15.255.255
permit ip 10.0.0.0 0.255.255.255 10.1.0.0 0.0.3.255
permit ip 172.16.0.0 0.15.255.255 10.1.0.0 0.0.3.255
permit ip 192.168.0.0 0.0.255.255 10.1.0.0 0.0.3.255
permit ip any 239.192.0.0 0.0.255.255
!
To Convert Unicast Rekeying to Multicast Rekeying
!!! With retaining all other configuration, removing "rekey transport unicast" will enable the key server to send rekeys using multicast transport. Also, the multicast group address, to which rekeys are sent, needs to be configured. PIM must be enabled on the respective interfaces. !!!
!
crypto gdoi group GROUP-VPN
identity number 1234
server local // local keyword identifies this router as key server //
rekey address ipv4 rekey-multicast-group //multicast group address to which rekey is sent//
profile vpnprof // Negotiates transform-set for group members //
match address ipv4 sa-acl // Policies downloadable to group members //
replay time window-size 5 // Time based anti-replay with 5 sec //
!!! The following configuration shows PIM is enabled in the loopback interface also as the rekey uses the loopback interface as the source address. The source address is also defined in the access list used by the rekey. !!!
!
ip multicast-routing // Enable multicast routing //
!
interface Loopback0
ip address 10.10.10.23 255.255.255.255
ip pim sparse-dense-mode // PIM enabled //
!
interface GigabitEthernet0/1 // No crypto map is applied in interface //
description Connected to PE2
ip address 10.10.10.26 255.255.255.252
ip pim sparse-dense-mode // PIM enabled //
duplex auto
speed auto
media-type gbic
negotiation auto
!
// The following access list defines the multicast group to which rekeys are sent. //
// This deployment uses auto-RP for this multicast group 239.192.1.190. Optionally, static RP can be configured. //
!
ip pim rp-address 10.10.10.26 multicast_rp_blockdensemode
!
ip access-list standard multicast_rp_blockdensemode
remark ACL to block dense-mode operation of client broadcasts
remark during routing instability (applied to pim rp-address command)
deny 224.0.1.39
deny 224.0.1.40
permit any
!
!!!! The following ACL defines the policies to be pushed to group members.
Note: The first deny ACL for multicast group 239.192.1.190 is specified to allow the group members to receive the rekey packets sent using multicast transport. For this configuration, rekeying using multicast transport use group address 239.192.1.190. Since the policy includes encryption for all multicast groups in the 239.192.x.x range, the group members would expect the rekey packets also to be encrypted by the traffic encryption key, which is not possible and hence the group member will drop the rekey packet. This is why the explicit deny is mentioned at the top of the access list. The other option is to specify the group member access list in all the group members, which is cumbersome. !!!!
!
ip access-list extended sa-acl
deny ip any host 239.192.1.190
permit ip 10.1.0.0 0.0.3.255 10.0.0.0 0.255.255.255
permit ip 10.1.0.0 0.0.3.255 192.168.0.0 0.0.255.255
permit ip 10.1.0.0 0.0.3.255 172.16.0.0 0.15.255.255
permit ip 10.0.0.0 0.255.255.255 10.1.0.0 0.0.3.255
permit ip 172.16.0.0 0.15.255.255 10.1.0.0 0.0.3.255
permit ip 192.168.0.0 0.0.255.255 10.1.0.0 0.0.3.255
permit ip any 239.192.0.0 0.0.255.255
!
Note: The policies defined in the key server ACL did not include "deny" statements for customer edge/provider edge communication, including routing traffic, PIM, and other control plane traffic. If customer edge/provider edge addressing involves a subnet from any of the protected traffic (as defined using "permit" statements), it is recommended to configure "deny" statements for customer edge/provider edge traffic at the top of the ACL. The optional configuration of the group member ACL is provided in the group member configuration.
Enabling Cooperative Key Server
The above configuration is sufficient to enable the key server as a standalone for an enterprise network. Let us now configure the cooperative key server. First, a few things need to be considered:
• Generate RSA keys in the primary key server (as required for rekeys) and export both private and public keys. Import these keys into all secondary key servers. This is required in case the primary key server goes down; the rekeys sent by the newly elected primary key server will still be decrypted by the group member.
• The default redundancy timers are large and hidden. However, if the customer needs to change those timers to speed up the detection of the key server failure, one must enable "service internal" to access those timers.
• Election between the key servers is based on the highest-priority value configured. If they are same, it is based on highest IP address. It is suggested to configure priorities for selecting the primary key server for easy setup and troubleshooting.
• Rekey configuration, policies defined, and anti-replay configurations must be the same between all key servers.
The procedure to export and import RSA keys is given below.
!!! Import this key using cut-and-paste on all the other key servers. Exportable option is to allow this procedure for any other key servers deployed later. !!!
Now, let us enable redundancy in both key servers.
Primary Key Server
!
crypto gdoi group GROUP-VPN
server local
redundancy // enabling cooperative key server function //
local priority 100 // priority decides the role of this key server //
peer address ipv4 10.10.10.56 // All other key servers must be configured //
!
Secondary Key Server
!
crypto gdoi group GROUP-VPN
server local
redundancy // enabling cooperative key server function //
local priority 75 // priority decides the role of this key server //
peer address ipv4 10.10.10.23 // All other key servers must be configured //
Group Member Configuration
!!!! IPsec transform-sets and profile configurations are not required as they are part of the negotiation with the key server when establishing the GDOI session. Only ISAKMP configurations are required to be defined to allow the group member and the key server to authenticate each other. !!!!
!
crypto isakmp policy 1 //Using PKI authentication. Refer to the Full Configuration. //
encr 3des
group 2
!
crypto isakmp keepalive 10
!
!!!!
Note: For using preshared key authentication method, preshared keys are needed in each group member only to authenticate the key server. It is not required to define preshared keys to authenticate other group members. !!!!
!!!! Group member is defined with same identity and location of key server. !!!!
!
crypto gdoi group getvpn
identity number 1234
server address ipv4 10.10.10.56 // Registration with secondary key server //
server address ipv4 10.10.10.23 // If previous server is not reachable, then register with this server //
!
!!!! Crypto map has a new type `gdoi' and is tied to group member created above. !!!!
!
crypto map gdoi 1 gdoi
set group getvpn
match address no-encryption-acl // GM ACL defined here //
!
!!!! GDOI is enabled by applying crypto map to outside physical interface. !!!!
!
interface FastEthernet0/0
description outside interface to PE2
ip address 10.10.10.42 255.255.255.240
ip pim sparse-dense-mode // To support multicast rekey //
Note: The following GM ACL has deny statements. The first statement allows any communication to the key server in clear text. There is no crypto map enabled in the key server, so it cannot understand an encrypted packet. Without this line, group member would encrypt the packet based on the policy defined in the key server. The third line makes the group member accept the multicast rekey packet sent to the group 239.192.1.190. This is due to the common policy defined in the key server to allow encryption for all 239.192.x.x range addresses. The alternative is to deny the policy itself defined in the key server. The other suggested line for this ACL is to deny traffic between CE-to-PE-only communication, such as routing protocol adjacency, PIM transport, etc. !!!!
!
ip access-list extended no-encryption-acl
deny ip 10.1.1.0 0.0.0.255 host 10.10.10.23
deny ip host 10.10.10.42 host 10.10.10.41 // excludes routing traffic to PE from encryption //
deny ip any host 239.192.1.190
!
2. Management
Out-of-band management of remote group members and key servers is done using a separate dedicated IPsec tunnel. For this, a separate management gateway is deployed to which all remote devices build a management tunnel. It is recommended to place this management gateway outside of any group members. In case of network issues for any remote device, the remote device can be always reachable through this management tunnel.
The servers for PKI, AAA, and any other management stations are placed behind this management gateway (Figure 3). As part of PKI authentication, the group member may need to download a Certificate Revocation List (CRL), and any AAA validations. Hence the group member will bring up this management tunnel before successful registration with the key server.
Note: As shown in this deployment below, it is recommended to use a separate subnet and assign host addresses to a loopback interface in each remote device. This would simplify excluding only this subnet from the key server policy.
In addition, this management tunnel will be useful for secure provisioning of new group members or key servers using Secure Device Provisioning (SDP). The SDP servers should be placed behind the management gateway. For more information about provisioning, visit http://www.cisco.com/en/US/products/ps6809/products_ios_protocol_option_home.html.
Key Server
The deny entries configured at the top of the access list exclude the management traffic from the group key encryption for the group members. This is required because the management gateway resides in one of the corporate subnets.
!
ip access-list extended sa-acl
1 deny ip 10.1.3.0 0.0.0.31 172.16.1.96 0.0.0.31
2 deny ip 172.16.1.96 0.0.0.31 10.1.3.0 0.0.0.31
Group Member
The management gateway uses a separate PKI server as part of the ECT_PKI recommendation. The group member should enroll with the PKI server. Here is the configuration needed for enabling the management tunnel.
