Separate Termination of IPsec and GRE (GRE-Offload)
| In Chapter 3, "Basic IPsec VPN Topologies and Configurations," we introduced the need to encapsulate traffic to be included in the crypto switching path in generic routing encapsulation (GRE) prior to crypto processing, a technique we've referred to as IPsec+GRE. Until now, we've explored integrated design options in which IPsec and GRE processing both occurred on the same VPN platform. In this section, we will discuss situations in which it is more appropriate to separate the processing of IPsec and GRE on to different platforms, a technique referred to as IPsec+GRE with GRE-offload. GRE-Offload Design OverviewThe need to forward IP Multicast traffic in the crypto switching path is the most prominent driver for IPsec+GRE designs. This is because IPsec alone will not support the encrypted multicast traffic. However, if one were to encapsulate a multicast packet in GRE prior to encryption, this would present a unicast traffic flow (the GRE traffic flow, with a multicast payload) to the IPsec crypto engine. This enables IPsec to forward the unicast GRE packet to the opposite end of the tunnel, where the IPsec headers (ESP, AH, or both) are decapsulated before the GRE headers are decapsulated. This operation results in an IP multicast packet presented in cleartext to be forwarded in normal IP multicast forwarding path at the opposite end of the tunnel. In previous chapters, we've discussed several design issues that GRE encapsulation prior to encryption presents, including the effect of tunnel fragmentation (Chapter 5, "Designing for High Availability") and the impact on geographic HA (Chapters 5 and 7, "Solutions for Geographic Site-to-Site High Availability"). These design considerations, however, apply to both consolidated and separated termination of IPsec and GRE in IPsec+GRE solutions. But, there are two key design considerations that mandate separate termination of IPsec+GRE tunnel terminationlack of support for GRE on the VPN gateways and insufficient performance for GRE on the IPsec VPN gateways. Lack of Support for GRE ProcessingIn many circumstances, IPsec VPN-enabled devices will not support the termination of GRE. One such example in which IPsec VPNs are commonly terminated on IPsec VPN devices that do not support GRE is when PIX firewalls are used as the IPsec gateways. This is a perfectly valid solution for IPsec VPN tunnel termination, but in situations in which IPsec+GRE is required, a separate device is required to perform the GRE encapsulate/decapsulate operations on the firewall inside interface or DMZ. Figure 10-12 illustrates a GRE-offload scenario with PIX used as the IPsec VPN tunnel termination point. Figure 10-12. PIX IPsec VPN Tunnel Termination with GRE-Offload Low GRE PerformanceIPsec+GRE is driving increased GRE performance in many integrated routing and switching platforms that support IPsec VPN tunnel termination. Many of today's midrange routers and IPsec appliances still do not support hardware-based GRE forwarding. However, GRE performance is a critical design requirement in large-scale site-to-site IPsec VPN tunnel concentration platforms. It is therefore very common to see IPsec VPN processing and GRE tunnel processing separated in this type of environment, as illustrated in Figure 10-13. Figure 10-13. Large-Scale Site-to-Site IPsec+GRE VPN Tunnel Concentration with GRE-Offload In Figure 10-13, IPsec is processed in hardware with high-speed IPsec VPN SPA included in the Catalyst 6500 switches at the enterprise campus WAN edge. The GRE processing is offloaded to the 7304 VXR routers behind 6500s so as to present all multicast traffic on egress to the branch in a unicast format to the 6500 VPN SPAs responsible for crypto processing. This design scenario is a very popular option, yielding high-speed hardware-assisted crypto forwarding for both unicast and multicast GRE payloads. The following case study aims to reinforce this design, in a real-world enterprise deployment. Note The Internet Engineering Task Force (IETF) is current working on a draft for encrypted multicast forwarding technique called Group Domain of Interpretation (GDOI) that enables native IPsec (without GRE) to support encryption of multicast IP flows. It further enables the multicast fanout to occur after encryption, which greatly decreases the load on the crypto engine relative to an IPsec+GRE scenario. GDOI is outside of the scope of book, but more information on IPsec, GDOI, and IP Multicast forwarding can be found within the following Internet draft for RFC 3547 located here: http://tools.ietf.org/wg/msec/draft-ietf-msec-gdoi/rfc3547.txt Case Study: Large-Scale IPsec VPN Tunnel Termination with GRE OffloadA large retail bank currently employs multiple large-scale WAN aggregation hubs for its thousands of retail branch offices scattered across the nation. Although the WAN edge deployments all follow the same design layout illustrated in Figure 10-13, the bank's IT staff has decided on multiple Internet-edge deployments located in Charlotte, Seattle, and Chicago to concentrate inbound WAN connectivity for the branches located in the eastern, western, and central United States, respectively. This offers the firm a measure of increased scalability and resiliency to disaster recovery over a consolidated single-site design. The bank had decided to expand its service offering some time ago by purchasing an investment-banking arm and a private equity arm. In order to increase workforce flexibility, and expand the geographic presence of these services, the bank employs these staff members at remote locations from time to time. One key service that these professionals rely on is the timely and accurate feed of stock quotes using an IP multicast stock quote server application residing in one of the organization's data centers in Dallas, Texas. The multicast traffic must therefore be confidentially transmitted from the data center across the WAN links to the remote branch locations. As such, multicast data is required to be encapsulated in GRE prior to being encrypted in IPsec, a technique we've previously referred to as IPsec+GRE. The typical bank branch is capable of terminating the IPsec+GRE traffic sequentially on the same IPsec VPN gateway. Therefore, a consolidated point of termination for IPsec and GRE tunnels is employed at the bank branch. However, due to sheer number of branches terminating their WAN connections at the three Internet-edge locations, scalability problems have presented themselves with a consolidated termination approach:
For these reasons, the firm decides to make some key alterations to its Internet-edge design using GRE-Offload. First, the IT staff has decided to increase the crypto switching capacity at the headend by introducing newer crypto hardware assist modules to its current platforms. The existing platforms, however, will not process the GRE traffic in the fast switching path. As such, the IT staff has decided to make a complementary investment to their new crypto processing hardware by investing in newer switching engines with onboard crypto hardware assist processors. Lastly, the firm has decided upon a staged update of its branch platforms to include increased crypto processing power. These branch platforms do not require GRE processing in hardware, as GRE scalability limitations were only being reached at the aggregation point of the IPsec+GRE VPN tunnels, not on the branches themselves. These changes all culminate in an Internet-edge design that follows the topology illustrated in Figure 10-13. Additionally, the firm decides to implement the following features in to the platform-specific design elements of its larger IPsec VPN architecture:
Dynamic Crypto Maps and GRE-OffloadDynamic crypto maps are used on the headend platforms aggregating the IPsec VPN tunnels. This allows for better management of the SADB on the headend platforms. It also allows for decreased management of peering sessions to the branches as they are moved, added, or changed. Note that this option does not use Tunnel Endpoint Discovery (TED), and therefore only the branch routers can initiate the establishment of an IPsec VPN tunnel. It is important to consider the administration and configuration management differences between a traditional IPsec+GRE headend configuration and an IPsec+GRE configuration with GREOffload. With a traditional IPsec+GRE scenario in which both IPsec and GRE configuration occurs on the same box, the addition of a new IPsec+GRE tunnel on the IPsec+GRE headend forces the configuration to be changed regardless of whether dynamic crypto maps are used or not. The separation of IPsec and GRE configurations on IPsec+GRE changes the administration requirements in a GRE-Offload deployment. Although the configuration of the GRE headend router must be changed whenever an IPsec+GRE tunnel is added in an IPsec+GRE Offload scenario, dynamic crypto maps can be used on the router terminating the IPsec portion of the IPsec+GRE headend to eliminate the need to change the configuration of the crypto headend when a new IPsec+GRE tunnel is added. This design element of the IPsec with GRE-Offload configuration therefore eliminates the opportunity for configuration or administration errors during maintenance windows. Tip Dynamic Multipoint VPN can eliminate configuration changes on the headend router further. Like IPsec+GRE Offload, DMVPN employs the use of dynamic crypto maps to negate the need to alter the crypto configuration on the headend. In addition, DMVPN employs NHRP to provision the GRE portion of the IPsec+GRE tunnel dynamically. DMVPN headend configuration is therefore considered to be "touchless" when deploying new IPsec+GRE tunnels. We will discuss DMVPN in greater detail in Chapter 7, "Solutions for Geographic Site-to-Site High Availability." Example 10-9 provides several key configuration elements required for IPsec+GRE with IKE x-Auth. First, the two ends of the IPsec VPN tunnel must agree on parameters used to authenticate the IKE channel during Phase 1 negotiation. The IKE policy (10) used to accomplish this task is displayed in lines 1-5 of Example 10-9 following. In this case, an added layer of authentication is used to authenticate the IKE channel against a TACACS+ database. This is known as IKE x-Auth and is commonly referred to as IKE Phase 1.5 negotiation (Example 10-10). The dynamic map provided in lines 10 and 11, "c10-iedge-dyn," references the transform set provided in line 8, "c10-iedge-trans," that defines the cryptographic transforms to be used in the Phase 2 SA. This dynamic crypto map is then bound to a static crypto map defined in configuration lines 13-14, which is then applied to the crypto interface with configuration line 21. Example 10-9. Dynamic Crypto Map Configuration on IPsec+GRE Crypto Headend Platform
IKE Extended Authentication (X-Auth)IKE x-Auth provisions another layer of authentication of the IKE SA using a unique username/password on a centrally managed authentication, authorization, and accounting (AAA) server using either TACACS+ or RADIUS. This design option enables the enterprise to manage preshared keys (PSKs) used during x-Auth more granularly, eliminating issues with peer eviction from the group. IKE x-Auth is discussed in greater detail in Chapter 12, "Solutions for Handling Dynamically Addressed Peers." The crypto headend platforms use the IKE X-Auth configuration supplied in Example 10-10. Example 10-10. IKE X-Auth Configuration on IPsec+GRE Crypto Headend Platform
Firewalled Cleartext TrafficThere are two paths through the firewall, allowing cleartext traffic to flow directly from inside to outside interface, and allowing crypto-switched traffic to flow bidirectionally between the outside and DMZ interfaces on the firewall. This design option allows for increased security for cleartext traffic, while allowing branches to establish IPsec tunnels through the firewall (hereby leveraging the dynamic crypto map on the headend IPsec VPN router). Example 10-11 provides the sample configuration for the IPsec+GRE deployment in Figure 10-13. Example 10-11. Firewall Configuration Example for IPsec+GRE Concentration in DMZ
High-Speed GRE Tunnel Termination for GRE-OffloadGRE tunnel termination is offloaded from the crypto headends to platforms that can encapsulate and decapsulate the GRE tunnel traffic in the fast switching path. In this case, as illustrated in Figure 10-13, the enterprise has elected Catalyst Supervisor 720 switching engine on their Internet-edge distribution switch pair to aggregate termination of the GRE tunnels from the Branch routers. |
EAN: 2147483647
Pages: 113