|
|
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 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.
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
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.
Figure 17-1 illustrates the concept of GET VPN and relationships with each other.
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.
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 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 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.
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. |
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.
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.
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.
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.
|
|