Dynamic Crypto Maps
| Dynamic crypto maps enable IPSec to negotiate ISAKMP and IPSec Security Associations (SA) that are initiated from remote endpoints, the addresses of which are unknown. Dynamic crypto maps by themselves do not enable a virtual private network (VPN) endpoint to proactively discover remote and unknown IPSec peers and does not enable a VPN endpoint to initiate ISAKMP and IPSec SA negotiation to undiscovered peers. Indeed, traffic that is in the crypto-protected path of a dynamic crypto map without TED will be dropped unless the remote peer has already initiated and negotiated an IPSec tunnel with the IPSec endpoint using that dynamic crypto map. In order to initiate ISAKMP and IPSec SA negotiation with unknown remote peers, dynamic crypto maps must be used in conjunction with TED, which is discussed later in this chapter. With static crypto maps, an IPSec peer is specified statically. This is not the case with dynamic crypto maps. Instead, because the peer is unknown, dynamic crypto maps will respond to ISAKMP and IPSec SA negotiation attempts from an array of previously unknown peers. Because of this, dynamic crypto maps have distinct differences from static crypto maps that change various concepts surrounding IPSec and ISAKMP design, deployment, and administration. Here are some key components of static IPSec peering designs that can be dynamically discovered and configured by altering the design to use dynamic crypto maps:
Note In remote access VPN deployments, dynamic crypto maps are commonly used to facilitate additional dynamic functionality, such as the dynamic assignment of VPN client IP addresses, DNS/WINS servers, and IP domain names using IKE Mode Config. These scenarios are discussed in greater detail in Chapter 9, "Solutions for Remote Access VPN High Availability." With static crypto maps, all of the above items must be manually configured at both the local and remote peers. In a dynamic crypto map solution, only the remote endpoint must be statically configuredthe local endpoint can use its dynamic crypto map to retroactively discover the remote peer's IP address. Indeed, it is this dynamic nature that distinguishes dynamic crypto maps from static ones. We will explore configurations that enable dynamic functionality later in the chapter, but first we will explore the impact that dynamic crypto maps have on the operation of ISAKMP and IPSec. Dynamic Crypto Map Impact on VPN BehaviorIncorporating dynamic crypto maps into an IPSec VPN design can dramatically change the behavior of the VPN. It is therefore important that network administrators understand the way that dynamic crypto maps alter the behavior of the VPN. In the following sections, we will discuss the impact of dynamic crypto map design on ISAKMP SA negotiation and what routing considerations must be addressed in an IPSec VPN deployment using dynamic crypto maps. Then we will discuss security considerations of dynamic crypto maps when compared against static ones, as well as some measures to consider when securing VPN implementations using dynamic crypto maps. Dynamic Crypto Map Impact on ISAKMP/IKEDynamic crypto maps will dynamically allocate a remote peer to the local IPSec configuration based on information provided by the remote peer itself. Indeed, ISAKMP negotiation cannot begin until a remote peer is defined. Therefore, once a router that uses dynamic crypto maps receives a request to initiate ISAKMP SA negotiation using a matching, locally configured ISAKMP policy, it creates and installs a temporary crypto map entry populated with the initiating endpoint's peer so that it can then carry on with Phase 1 negotiation. This order of operations is illustrated later in Figure 12-1. Figure 12-1. Reverse Route Injection and Dynamic Crypto Maps A VPN endpoint that uses dynamic crypto maps must be configured with an ISAKMP policy that matches one proposed by the remote VPN endpoint. This behavior is consistent with static crypto maps with one exceptiondynamic crypto maps typically use wildcard preshared keys. The use of wildcard preshared keys allows network administrators to define a key for use with a range of IP addresses, as opposed to just one. This is particularly useful in a dynamic crypto map scenario where there are a varying number of peers whose addresses are unknown. Wildcard preshared keys eliminate the need to know the peer's exact address during IKE authentication, requirng only that it fall within a specific range. Example 12-1 illustrates a sample IKE configuration using a wildcard preshared key. Note The use of wildcard preshared keys leads to difficulties when attempting to evict an endpoint from the IPSec VPN. When the administrative overhead of static preshared keys is a concern, it is recommended that RSA signatures be used instead of wildcard preshared keys. Example 12-1. Wildcard Preshared Keys in ISAKMP Authentication.
Note For increased security using dynamic crypto maps, IKE Extended Authentication (x-auth) can be used instead of pre-shared keys. IKE x-auth leverages a robust set of authentication and authorization commands in conjunction with centrally maintained TACACS+/RADIUS databases for increased security and scalability. Routing Considerations with Dynamic Crypto MapsDesigns leveraging the functionality of dynamic crypto maps introduce some additional design considerations that network designers must address within their routed infrastructures. The following list provides a brief introduction and explanation of considerations for IPSec VPNs with dynamic crypto maps:
Figure 12-1 illustrates an IPSec VPN deployment in which dynamic crypto maps are used in conjunction with RRI. The following is the operation of the IPSec-enabled infrastructure numbered in Figure 12-1:
Security Considerations for Dynamic Crypto MapsAs the number of remote peers associated with a dynamic crypto map scales upward, so too escalates the security concerns surrounding the use of wildcard preshared keys. Next, we will discuss two of these concerns, both directly related to key management for dynamically addressed peers, and how to use x-auth during ISAKMP authentication to harden security for dynamically addressed VPN peers. Key Administration and ScalabilityMultiple wildcard preshared keys can be defined, but the manual configuration involved makes it very difficult for each peer to use its own unique key for IKE authentication, since the number of remote and unknown peers scale upward. Therefore, using wildcard preshared keys for a large number of unknown peers presents a security risk, because many of those unknown peers typically use a common key. Using IKE x-auth in conjunction with a TACACS+ or RADIUS database such as Cisco Secure Access Control Server (ACS) provides a highly scalable, highly available solution for IPSec peers to authenticate with their own unique credentials. The addition of a peer to the group using a common wildcard preshared key for IKE authentication is a simple processa single configuration of that key on the remote peer. However, removing a peer from that group is more involved and presents security risks. Once a peer is evicted from a group using a common preshared key, that key has become compromised, and must therefore be changed and updated on every remaining peer in the group. For this reason, it is apparent that wildcard preshared keys do not offer the administrative flexibility needed for secure IKE negotiation with dynamically addressed peers. Instead, IKE x-auth should be used so that a peer in the group can be removed without compromising the credentials that the remaining, dynamically addressed peers use for IKE authentication. IKE x-auth offloads Phase 1 authentication and authorization of remote peers to either a locally configured database on the aggregating router or to a centrally maintained database using TACACS+ or RADIUS. Figure 12-2 describes the authentication process used during IKE x-auth. Figure 12-2. ISAKMP Phase 1 Negotiation Using Extended Authentication (x-auth) The following is a description of the numbered process in Figure 12-2:
In the configuration in Example 12-2, the remote 3745 acts as an EZVPN client, connecting dynamically to the 7304, which in this case acts as the VPN concentrator. The concentrator receives the VPN group credentials and password, and uses the group password as the IKE preshared key. IKE x-auth is configured for additional security and flexibility in group and peer administration. Using x-auth, the concentrator prompts the client for an additional authentication check against its locally configured database. The client authenticates using its locally configured username and password under the appropriate group settings. Note IKE x-auth occurs after an IKE SA has been created but before an IPSec SA can be created. IKE x-auth therefore does not replace IKE itself, but rather occurs in addition to it. As such, IKE x-auth negotiation is commonly referred to as Phase 1.5 negotiation. Example 12-2. Configuring IKE X-Auth Using TACACS+ and AAA
Unrestricted Peering and Traffic FlowsBy default, dynamic crypto maps allow peering sessions from any peer that IKE can authenticate. Likewise, by default, all traffic is allowed to and from all peers associating with that dynamic crypto map. Both of these areas can be secured by restricting peering sessions and using dynamic crypto map ACLs to restrict traffic. Example 12-3 describes a scenario in which a dynamic crypto map allows HTTP traffic only from peers 192.168.1.15, but allows both http and SMTP traffic from peers 192.168.1.610. Example 12-3. Restricting IPSec Peering and Traffic Flows in Dynamic Crypto Maps
Dynamic Crypto Map Configuration and VerificationThe design topology illustrated in Figure 12-3 outlines a site-to-site extranet deployment in which an organization maintains secure connectivity to its extranet partners, which are numerous. The organization relies on data feeds from extranet partners for services critical to the operation of the business but does not maintain control over the configuration of remote routers on the extranet partner's premises. Instead, those configurations are maintained by the partner, and they are subject to change over time. As such, the organization has chosen to deploy dynamic crypto maps at its local aggregation point for extranet IPSec VPNs, allowing the extranet partners to change their configuration on the fly and dynamically update the IPSec SA peer configuration information on the aggregation router with minimal administrative overhead. Figure 12-3. Extranet Deployment and Dynamic Crypto Maps Note the size of the extranet in Figure 12-3. The simple hub-and-spoke extranet design listed in this figure presents a fair amount of administrative overhead at the hub, especially when the partner sites control the policy on their VPN endpoint and are liable to make changes to their session on the fly. Deploying dynamic crypto maps (and TED, if necessary) can dramatically ease the hub administrator's burden of accommodating the many anticipated changes made at the numerous extranet partner sites. To highlight the configuration of a dynamic crypto map, we will select a fixed (extranet partner) end of the tunnel and the dynamic end of the tunnel, and explore the connectivity between those two peers, as the greater extranet design is merely an extension of that dynamically established point-to-point IPSec VPN. Note For extranet designs such as this one, there typically will exist a certain amount of High Availability (HA) designed into the aggregation points. Our conversation in this chapter will focus solely on dynamically addressed peering, and, because of this, HA concepts are not incorporated into these configurations. Example 12-4 provides a sample configuration for a hub router (AS1-7304A) supporting the extranet design discussed in Figure 12-3. Example 12-4. Configuration of AS1-7304A
Example 12-5 provides a sample branch router (AS113-3745A) configuration used to establish an IPSec VPN tunnel to the corresponding hub router (AS1-7304A). The extranet topology for this configuration is illustrated in Figure 12-3, and hub configuration is provided in Example 12-5. Example 12-5. Configuration of AS113-3745A
Example 12-6 illustrates some basic techniques that administrators can use to verify the operation of a dynamic crypto map configuration such as the one on AS1-7304A. Example 12-6 illustrates the dynamic IPSec SA using the dynamic crypto map referenced in Example 12-4. The protected VRF (proxy) noted in the IPSec SA is consistent with the access list referenced in the dynamic crypto map of Example 12-4. The remote peer, 192.168.111.1, was learned dynamically. The IPSec SA is built from the IPSec headend loopback interface to the dynamically learned remote peer, 192.168.111.1. It is important to note that sourcing Phase 1 and 2 SAs from the router's loopback behavior represents a departure from the default behavior, which is to source the IPSec tunnel from the physical interface to which the crypto map is bound. The encryption/decryption statistics for this SA show that five Internet Control Message Protocol (ICMP) messages were sent across the IPSec tunnelfour were encrypted and their responses were decrypted while the first was dropped during the negotiation of Phase 1 and 2 SAs. Example 12-6. Verifying the Dynamic Crypto Maps
The output in Example 12-7 verifies the operation of the crypto engine as traffic is passed along the VPN path. Note that four packets were decrypted/received from the remote host to initiate tunnel negotiation and that four responses to the packets were encrypted on the return path. This is consistent with the traffic statistics in the IPSec SA diagnostic output in Example 12-6. Example 12-7. Verifying Security Association Cryptographic Operations
|
EAN: 2147483647
Pages: 113