Vendor Interoperability Design Considerations and Options

At this point, we have covered some of the most prevalent and effective means to address site-to-site and remote-access VPN High Availability. However, the design options presented in previous chapters may not be available in multi-vendor deployments, depending on the capabilities of the IPSec VPN gateways themselves. This section discusses some additional alternatives that can be used to increase the degree of availability of an IPSec VPN in vendor-diverse deployments.

Phase 1 and 2 SA Lifetime Expiry

The most rudimentary form of IPSec failover is driven by expiry of Phase 1 and 2 SA lifetimes from a stale SA left over after a failure in the primary IPSec VPN tunnel. This method entails the simple process of allowing the lifetimes of the previously negotiated SA lifetimes to expire after an IPSec VPN tunnel fails. After these SAs timeout, new SAs can be then negotiated to redundant peers.

SA lifetimes are required (per RFC 2401) for security reasons. Coincidentally, they are the only HA-related means addressed as a requirement in the RFC. Therefore, expiry of Phase 1 and 2 SA lifetimes are the only means of HA that administrators can count on, regardless of the capabilities implemented by a vendor's IPSec VPN gateway, so long as that vendor's implementation of IPSec is compliant with the RFC.

Unfortunately, relying on SA lifetimes to expire before establishing a new set of SAs to a redundant IPSec gateway is the slowest of all available HA processes. As such, many alternatives to this method have been developed to speed reconvergence of IPSec VPN tunnels in HA environments. We've explored many of these design options in detail in previous discussions of HA, including the following:

• IKE keepalives and dead peer detection (Chapter 5)

• VPN concentrator clustering and the VCA protocol (Chapters 5 and 9)

• DNS-based VPN Concentrator HA (Chapters 5 and 9)

• Stateless HA with IKE keepalives and DPD (Chapter 6)

• Stateful HA with SSO (Chapter 6)

• Redundant peers with IKE keepalives and DPD (Chapter 6 and 7)

• Redundant physical interfaces with IKE keepalives and DPD (Chapter 6 and 7)

• Highly available (loopback) interfaces (Chapter 6)

Unfortunately, because HA is largely unaddressed by standards bodies, not all of these design options are globally available across all vendor implementations of IPSec. Now we will explore some additional alternatives to expiration of SA lifetimes that address potential limitations introduced by vendor interoperability in platform and vendor-diverse IPSec HA designs.

SADB Management with Quick Mode Delete Notify Messages

Recall from our discussions in Chapter 3, "Basic IPsec VPN Topologies and Configurations," that the management of SAs in an IPSec VPN gateway's SADB are managed over a secure channel, called an IKE security association (or Phase 1 SA). This SA can be negotiated in one of two modesmain mode or aggressive mode. Once the Phase 1 SA has been negotiated, two Phase 2 SAs, called IPSec SAs, are negotiated (one in each direction) securely over the IKE SA.

Unlike Phase 1 SA negotiation, Phase 2 SAs can only be negotiated in one modequick mode. Because IKE manages the setup and teardown of IPSec SAs, there must be some means for IKE to communicate to IPSec that it must tear down its Phase 2 SAs. The IKE module in an IPSec VPN gateway accomplishes this by sending a quick mode DELETE_NOTIFY message to the IPSec module within the gateway.

Consider the case in which two gateways have negotiated an IPSec VPN tunnel successfully. The Phase 2 SA lifetime is the Cisco IOS default of 3600 seconds (1 day). Due to a failure somewhere within the IPSec VPN deployment, the VPN gateways have determined that the Phase 1 SA should be reaped from the SADB (via DPD or IKE keepalives). Phase 2 SAs, however, still remain in the IPSec SADB, and packets in the crypto path are dropped until these stale SAs are removed. If the gateways support quick mode DELETE_NOTIFY messages, the IKE module in each IPSec VPN gateway will send a DELETE_NOTIFY message to the IPSec module, instructing it to remove the Phase 2 (IPSec) SAs from its SADB. The result of this behavior is quicker teardown of stale IPSec SAs so that new, valid, Phase 1 and 2 SAs can be negotiated between the peers within the IPSec VPN tunnel.

Invalid Security Parameter Index Recovery

Invalid Security Parameter Index (SPI) Recovery allows for reduced IPSec recovery times when an IPSec peer resets or goes offline and then returns. Figure 8-6 shows a standard site-to-site IPSec VPN in which vendor-diverse IPSec VPN gateways are used to terminate the IPSec VPN tunnel.

Figure 8-6. Expediting IPSec VPN Tunnel Recovery with Invalid SPI Recovery

Consider the scenario in which C2800ISR-A6 was to go offline and then return due to an interface failure, a system reset, or a power failure. When the C2800ISR-A6 goes offline, it loses its Phase 1 and 2 SA entries in its SADB. Because IPSec-GW-A6 does not support the use of IKE Keepalives and DPD, it has no ability to reap the SAs in its SADB before their lifetimes expire. In order to expedite the initiation of Phase 1 and 2 SA renegotiations between the two peers, C2800ISR-A6 must therefore have some means by which to detect that the SAs must be reaped at the opposite end so that new ones can be negotiated. Invalid SPI Recovery is used on C2800ISR-A6 to accomplish this task. The following sequence of events summarizes the events occurring after a system reset occurs on C2800ISR-A6 in the network illustrated in Figure 8-6:

1.	C2800ISR-A6 reloads due to a power failure, losing all current entries in its SADB in the process. Upon recovery and a crypto ACL match, C2800ISR-A6 attempts to build new IKE and IPSec SAs (with new SPIs) with IPSec-GW-B6.
2.	Phase 1 and 2 SA lifetimes have not expired on IPSec-GW-A6, so IPSec-GW-A6 continues to forward packets to C2800ISR-A6 using the previously negotiated (now stale) SAs with C2800ISR-A6 in its SADB.
3.	C2800ISR-A6 receives the encrypted traffic from IPSec-GW-A6 and finds no SPI in its SADB for the received traffic. C2800ISR-A6 thereby detects an invalid SPI from IPSec-GW-A6.
4.	C2800ISR-A6 forwards an INVALID_SPI_NOTIFY message to IPSec-GW-A6 over the Phase 1 SA established in Step 4.
5.	IPSec-GW-A6 receives the INVALID_SPI_NOTIFY message forwarded in Step 5 and reaps the corresponding SAs from its SADB.
6.	IPSec-GW-A6 receives traffic to be forwarded in the crypto path to C2800ISR-A6, triggering a new negotiation of Phase 1 and 2 SAs with C2800ISR-A6.

Vendor Interoperability with Stateful IPSec HA

As mentioned before, vendor-interoperability issues within HA can present themselves when an IPSec VPN gateway does not support the ability to use multiple, redundant, IPSec peers. One way to solve this is to use stateful IPSec HA on the opposite end of the IPSec VPN tunnel in order to make the two peering IP addresses look as if they were one single interface. As discussed previously in Chapter 6, "Solutions for Local Site-to-Site High Availability," this is achieved using a virtual interface with HSRP or VRRP and communicating IPSec state information between the redundant IPSec gateways participating in the HSRP or VRRP group using SSO and SCTP.

Figure 8-7 illustrates an extranet deployment in which extranet partners are given their choice of IPSec VPN gateways while still being offered a certain level of IPSec HA at the enterprise campus. This is done using stateful IPSec HA with HSRP and SSO.

Figure 8-7. Addressing Vendor Interoperability HA Issues with Stateful IPSec HA with HSRP and SSO.

In this scenario, the two IPSec VPN gateways at the enterprise's internet edge DMZ present only one HSRP virtual interface instead of multiple physical or loopback interfaces for the extranet partners' IPSec VPN gateways to peer to. This eliminates the need for several key capabilities that would be required for HA peering to redundant interfaces:

• Multiple Peering Statements Only one interface (the HSRP or VRRP virtual interface) is presented to the remote IPSec VPN gateway. Therefore, only one peering statement is required on the remote VPN gateway instead of two peering statements in the case of peering to multiple redundant physical or loopback interfaces.

• IKE Keepalives or DPD The use of a virtual interface keeps peering information consistent during a failover scenario from the perspective of the remote IPSec VPN gateway. SSO communicates the SADB state in advance of the failure to the redundant IPSec VPN gateway, precluding the need for Phase 1 and 2 renegotiations with the redundant IPSec VPN gateway after failover.

Note

Detailed information on stateless and stateful IPSec HA can be found in Chapter 6. Likewise, detailed operational information on IKE keepalives and DPD can be found in Chapter 5, "Designing for High Availability."

The design benefits of stateful IPSec HA extend far beyond the added flexibility of IPSec VPN gateway selection at the opposite end of the VPN tunnel, including, among others, subsecond IPSec VPN failover convergence with HSRP. Alternatively, when cost is an issue, achieving HA with DPD and or IKE keepalives to multiple peers could be a more appropriate design option. As such, flexibility in IPSec VPN gateway selection should not drive HA strategy by itself. Instead, it is important to fully understand and consider all of the design benefits of each option presented in Chapters 5 through 7 when selecting a strategy for IPSec HA.