Vendor Interoperability Impact on Peer Availability

In an IPSec HA environment, it is not only critical to determine the availability of both IPSec VPN tunnel endpoints, but also to quickly determine when a tunnel endpoint has become unavailable. Design issues discussed within this context all pertain to IPSec peer availabilitythe ability to determine the availability of a remote peer and to rapidly detect the change in a remote peer's availability. This chapter discusses several vendor interoperability path availability limitations that preclude HA and must therefore be addressed in an IPSec HA environment, including the inability to specify multiple peers and the lack of peer-availability mechanisms.

The Inability to Specify Multiple Peers

Figure 8-1 shows a network in which a remote branch office connects across an ISP to its campus internet edge, where there exist two VPN headend routers that are aggregating the termination of IPSec VPN tunnels from all remote branches. In this configuration, the enterprise has invested in out-of-chassis HA at their IPSec aggregation points. The solution does not use virtual interfaces (Hot Standby Router Protocol/Virtual Router Redundancy Protocol [HSRP/VRRP]) but instead relies on the ability of the branch to failover to the redundant aggregation point when the primary aggregation point becomes unavailable.

Figure 8-1. Vendor Interoperability and Peer Availability: Inability to specify multiple peers

In this scenario, the remote VPN gateway does not have the ability to define multiple IPSec peers, Reverse Route Injection (RRI), or IPSec+GRE. Instead, the branch encryptor, IPSec-GW-A1, relies on manually defined static routes to preserve continuity between the two routed domains at Sites A and B across the IPSec VPN tunnel. Therefore, the expected behavior is as follows (as numbered in Figure 8-1):

1.	IPSec-GW-A1 is configured to negotiate an IPSec VPN tunnel with C7206VXR-A1 with the IP address of 200.1.1.1. IPSec-GW-A and C7206VXR-A1 successfully negotiate Phase 1 and 2 SAs with each other to establish the IPSec VPN tunnel.
2.	A failure on the serial link between C2800ISR-A1 and C7206VXR-A1 occurs, forcing traffic across the redundant serial link between C2800ISR-A1 and C7206VXR-B1.
3.	IPSec-GW-A1 does not support the definition of multiple IPSec peers and is therefore incapable of negotiating a Phase 2 Security Assotiation with C7206VXR-B1.
4.	Because the traffic flows to be included in the crypto switching path on IPSec-GW-A1 remain consistent before and after the failure of the serial link between C7206VXR-A1 and C2800ISR-A1, IPSec-GW-A1 will continually try and fail to encrypt traffic using the IPSec SA with C7206VXR-A1, which is now unavailable.
5.	IPSec-GW-A1's Phase 2 negotiations continually fail, causing all traffic flows in the crypto switching path to be discarded.

It is important to consider that in number 5, above, the results depend heavily on the capabilities of IPSec-GW-A1. For example, if IPSec-GW-A1 has the ability to distinguish between ciphertext and cleartext traffic flows (as is the case with crypto ACLs), then IPSec+GRE could be used to differentiate the traffic flows (flows would be based on source and destination GRE tunnel endpoints) by encapsulating them in GRE before the traffic were to reach IPSec-GW-A1 for crypto processing. Because IPSec-GW-A1 is still incapable of negotiating an IPSec SA with a redundant peer, the redundant path cannot be leveraged for ciphertext communications. However, the redundant path could still be used for cleartext data transfer, since IPSec-GW-A1's crypto ACL equivalent would be configured to bypass crypto operations for the redundant GRE tunnel traffic. Although this method may be unacceptably insecure in failover scenarios, it does provide a cleartext alternative in emergency situations.

Another solution to this problem is to somehow combine the two peering endpoints on C7206VXR-A1 and C7206VXR-B1 into a single yet redundant point of termination for remote IPSec endpoints. This would provide an HA solution for the vendor-diverse environment discussed above that is independent of the operation of IPSec-GW-A1 in Step 5. Recall that in Chapter 6, "Solutions for Local Site-to-Site High Availability,"we discussed the option of using HSRP or VRRP to create a virtual interface for tunnel termination point redundancy. In this scenario, HSRP or VRRP could be deployed between C7206VXR-A1 and C7206VXR-B1 to provide the same out-of-chassis HA benefits while presenting a single tunnel termination point for the branches.

Note

For the purposes of this chapter, the problem is presented only in the context of multiple tunnel termination points to illustrate issues with IPSec HA interoperability. For more information on stateful and stateless IPSec HA designs using HSRP and VRRP, please refer to Chapter 6, "Solutions for Local Site-to-Site High Availability."

Although there are multiple widely deployed solutions, such as stateful and stateless HA using virtual interfaces, there are other alternatives for handling vendor interoperability within HA, such as QM Delete Notify, relying on IPSec and IKE SA lifetimes, and Invalid SPI recovery.

Although these solutions may not provide the same degree of HA as the HA solutions discussed in Chapters 5, 6, 7, and 8 (for example, stateful HA with Stateful Switchover [SSO], as discussed in Chapter 6), we will discuss these designs later in this chapter as alternative design options where best practices may not be possible.

Lack of Peer Availability Mechanisms

An IPSec HA deployment relies on the rapid detection of a failure along the primary path and the ability to quickly re-establish communications across the redundant path, a concept referred to as IPSec reconvergence. Without a mechanism to detect whether or not a failure has occurred somewhere along the path of the primary IPSec VPN tunnel that has eliminated the availability of one of the IPSec peers actively used as an IPSec tunnel termination point, the ability of the IPSec VPN tunnel to reconverge along the redundant path is greatly impacted.

Note

Cisco VPN concentrators, clients, and couters supporting IPSec provide for several mechanisms for managing peer availability, including IKE keepalives and Dead Peer Detection (DPD). For a more detailed discussion of IKE keepalives and DPD, please refer to Chapter 5, "Designing for High Availability."

Figure 8-2 illustrates a network in which there is a remote IPSec VPN gateway that is dually homed to a pair of IPSec VPN headend devices at the enterprise's headquarters.

Figure 8-2. Lack of Peer Availability Mechanisms and the Impact on IPSec VPN Reconvergence

The remote VPN gateway, IPSec-GW-A2, supports the use of multiple peers but does not support any peer availability mechanisms outside of those required by the RFC. For example, IPSec-GWA2 does not support IKE keepalives or DPD, but as per RFC 2401, IPSec-GW-A2 does associate lifetimes with Phase 1 and 2 SAs. The following revisits the failover scenario in Figure 8-2 and describes the expected step-by-step outcome:

IPSec-GW-A2 successfully negotiates an IPSec VPN Tunnel (Phase 1 and 2 SAs) with C7206VXR-A2 (200.1.1.1).

1.	The serial interface between C2800ISR-A2 and C7206VXR-A2 fails, forcing traffic that was in the crypto path to use the redundant tunnel termination point on C7206VXR-B2 (200.1.1.5).
2.	IPSec-GW-A2 does not have a mechanism for determining that the availability of the peer used to populate the Phase 2 SA in its Security Assotiation Database (SADB) (200.1.1.1) is now unavailable. IPSec-GW-A2 therefore waits for the lifetime of the Phase 2 SA in its SADB to expire.
3.	Upon expiration of the existing Phase 2 SA lifetime in IPSec-GW-A2's SADB, IPSec-GWA2 then tries to renegotiate Phase 1 and 2 SAs with 200.1.1.1, which is still unavailable. IPSec-GW-A2 initiates Phase 1 and 2 SA negotiations with the redundant peer, C7206VXRB2 (200.1.1.5), after failing to negotiate SAs with C7206VXR-A2.

The impact on HA in this situation is realized in step 3. Although the system eventually reconverges after the lifetime of the Phase 2 SA (3600 seconds by default) expires, application data is being dropped while the stale SA remains in the SADB. The presence of the stale SA in IPSec-GW-A2 effectively inserts an unacceptably large delay in the overall reconvergence of the IPSec VPN onto the redundant path.

If there were peer availability mechanisms present to speed the detection of the stale SA left over from the failure situation described in Figure 8-2, then the overall reconvergence process of the IPSec VPN would be greatly expedited. For more information on the operation IPSec with IKE Keepalives and Dead Peer Detection, please refer to Chapter 5, "Designing for High Availability."

We've discussed two popular options for expediting the detection of stale SAs in HA environments, IKE keepalives and DPD, and presented the design alternatives accordingly in Chapters 5 and 6. It is therefore important to integrate these options into the design of the IPSec VPN where possible. However, there may be situations where this is not possible, such as the scenario presented in Figure 8-2. Later in this chapter, we will discuss several design alternatives for handling this design consideration when peer availability mechanisms are not supported on the selected IPSec VPN gateways in the system design.