Dynamic Crypto Maps






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:

  • Dynamic acceptance and configuration of the remote (initiating) peer's IP address in the negotiated IPSec SA

  • Dynamic acceptance and configuration of the crypto-protected address space in the IPSec SA

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 Behavior

Incorporating 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/IKE

Dynamic 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.

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. Figure 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.


Wildcard Preshared Keys in ISAKMP Authentication.

!#<--This example of a wildcard preshared key will allow any peer with an IP
!address within the range of 192.168.0.0/16 to negotiate an ISAKMP SA-->
crypto isakmp key extranet address 192.168.0.0 255.255.0.0

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 Maps

Designs 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:

  • IGP Multicast Routing Updates Dynamic crypto maps allow broader definition of protected traffic sets, since multiple unknown peers can now dynamically negotiate different protected traffic sets with the same dynamic crypto map. However, caution should be exercised against using the any keyword in the dynamic crypto map's ACL when defining broad scopes of protection, so that multicast routing protocol updates are not encrypted or dropped unnecessarily. As we've mentioned previously, traffic in the crypto path using a dynamic crypto map will not initiate IPSec tunnel negotiation; it will instead be dropped. Therefore, defining multicast and broadcast traffic in the crypto path using dynamic crypto maps can oftentimes lead to the discarding of routing updates and loss of RP adjacencies. When using any keyword on the dynamic crypto map ACL, traffic such as multicast RP updates should be explicitly denied first.

  • Reverse Route Injection (RRI) RRI is a feature that will dynamically inject routes into the IPSec VPN gateway's routing table. Effective implementation of RRI allows network administrators to keep the routing table size manageable. With RRI, routes are injected dynamically into the routing table, which can subsequently be redistributed into the enterprise's IGP for propagation throughout the network. This allows the VPN concentrator or router to inject routes for only those remote networks that have active IPSec VPN connections. This method can be used to efficiently scale the Interior Gateway Protocol (IGP) of an IPSec VPN implementation when used in conjunction with dynamic crypto maps.

Figure 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:

1.
The remote network attempts to contact a resource on the enterprise network.

2.
The remote VPN endpoint sees the traffic in Step 1, successfully matches it against a crypto ACL, and initiates ISAKMP SA negotiation.

3.
The VPN aggregation point receives the request and finds a locally configured ISAKMP policy to match the ISAKMP proposal that it received in Step 2. The VPN aggregator creates a temporary crypto map entry populated with the remote peer address so that ISAKMP negotiation can continue.

4.
The VPN aggregator on the enterprise network uses a temporary crypto map installed in Step 3 to negotiate Phase 1 and 2 with the remote VPN endpoint.

5.
The VPN aggregator uses RRI to dynamically inject the 199.1.1.0/24 network into the enterprise network. This allows enterprise resources to route traffic over the VPN to the appropriate destination on the remote end of the IPSec VPN tunnel. When the ISAKMP and IPSec SAs for the remote network time out, the routes injected using RRI are allowed to time out.

Security Considerations for Dynamic Crypto Maps

As 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 Scalability

Multiple 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 describes the authentication process used during IKE x-auth.

ISAKMP Phase 1 Negotiation Using Extended Authentication (x-auth)


The following is a description of the numbered process in Figure:

1.
The remote peer sends an ISAKMP proposal.

2.
The local peer checks the ISAKMP proposal against its locally configured policies and finds a match; an IKE SA is established with that proposal using preshared keys.

3.
The local peer sends a TACACS+ access-request message to the AAA server.

4.
The AAA server responds with either an access-accept or access-reject message, depending on whether the peer is successfully authenticated or not. In this case, the peer is authenticated by the AAA server and a TACACS+ access-accept message is forwarded back to the local peer.

5.
The local peer installs a temporary crypto map using the IP address peer that sent the ISAKMP proposal in Step 1.

6.
The two peers continue to negotiate IPSec SAs.

In the configuration in Figure, 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.


Configuring IKE X-Auth Using TACACS+ and AAA

AS1-7304A#
!
!#<--This username and password configured in the local database are referenced
!by the AAA model when authenticating IPSec clients-->
!
username as111 privilege 15 password 0 cisco111
!
!#<--These AAA statements are used when IPSec clients require x-auth.
!The AAA statements below reference the local database, in which there
!is an appropriate username and password for the client.-->
!
aaa authentication login vpn-auth local
aaa authorization network vpn-auth local
!
!#<--The VPN group "extranet" is used for group authentication with the
!IKE pre-shared key "cisco". This group template protects traffic using
!the crypto ACL 111 and the dynamic crypto map "extranet-dyn".
!The "save-password" command allows clients to hard code their usernames and
!passwords into their client configurations. As such, they can be automatically
!offered for authentication, rather than having to enter them manually
!when prompted by the concentrator.-->
crypto isakmp client configuration group extranet
 key cisco
 acl 111
 save-password
!
crypto dynamic-map extranet-dyn 10
 set transform-set extranet-trans
 reverse-route
!
!#<--The crypto map "extranet" is instructed to use the AAA model "vpn-auth"
!for extended authentication and authorization of IPsec VPN clients.-->
crypto map extranet client authentication list vpn-auth
crypto map extranet isakmp authorization list vpn
!#<--The dynamic crypto map "extranet-dyn" is referenced here so that it can
!be applied indirectly via the application of the static crypto map "extranet"
!to the physical interface-->
crypto map extranet 10 ipsec-isakmp dynamic extranet-dyn
!
Interfaces Serial0/0
 crypto map extranet

AS111-3745A#
!
!#<--Instead of static or dynamic crypto maps, the remote router is configured
!as an ezvpn client, so that x-auth can be used for greater flexibility in
!group management and additional security-->
crypto ipsec client ezvpn as111-client
 connect auto
!#<--The VPN concentrators will use these credentials to identify which group
!and pre-shared key this client will use for ISAKMP Phase 1 negotiation-->
 group extranet key cisco
 mode client
 peer 200.1.1.1
!#<--The VPN concentrator will authenticate these credentials against its
!AAA model (must match username and password configuration on AS1-7304A)-->
 username as111 password cisco111
!
!#<--This ezvpn client does not use crypto acls to determine the crypto protected
!traffic. Instead, all traffic from the ezvpn "inside" interface being sent out
!of the concentrator-facing physical interface is crypto protected-->
interface Loopback192
 crypto ipsec client ezvpn as111-client inside
!
interface Serial0/0
 crypto ipsec client ezvpn as111-client

Unrestricted Peering and Traffic Flows

By 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.

Figure 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.

Restricting IPSec Peering and Traffic Flows in Dynamic Crypto Maps

AS1-7304A#
!
crypto dynamic-map extranet-dyn 10
 set peer 192.168.1.1
 set peer 192.168.1.2
 set peer 192.168.1.3
 set peer 192.168.1.4
 set peer 192.168.1.5
 set ip access-group 113 in
 set transform-set extranet-trans
 match address 111
 reverse-route
crypto dynamic-map extranet-dyn 20
 set peer 192.168.1.6
 set peer 192.168.1.7
 set peer 192.168.1.8
 set peer 192.168.1.9
 set peer 192.168.1.10
 set ip access-group 114 in
 set transform-set extranet-trans
 match address 111
 reverse-route
!
access-list 113 permit tcp 192.168.111.0 0.0.0.255 192.168.1.0 0.0.0.255 eq www
access-list 113 permit tcp 192.168.111.0 0.0.0.255 192.168.1.0 0.0.0.255 eq smtp
access-list 114 permit tcp 192.168.111.0 0.0.0.255 192.168.1.0 0.0.0.255 eq www
access-list 114 permit tcp 192.168.111.0 0.0.0.255 192.168.1.0 0.0.0.255 eq smtp

Dynamic Crypto Map Configuration and Verification

The design topology illustrated in Figure 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.

Extranet Deployment and Dynamic Crypto Maps


Note the size of the extranet in Figure. 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.


Figure provides a sample configuration for a hub router (AS1-7304A) supporting the extranet design discussed in Figure.

Configuration of AS1-7304A

!#<--In this case, the ISAKMP policy is configured as if the crypto map
!were static. However, it is applied to all peers negotiating IPSec and
!ISAKMP SAs with this router using its local dynamic crypto map.-->
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
!#<--Because the specific peer address is unknown, wildcard preshared keys are
!used to authenticate extranet peers initiating ISAKMP SA negotiation with
!addresses in the range of 192.168.0.0/16-->
crypto isakmp key extranet address 192.168.0.0 255.255.0.0
!
crypto ipsec transform-set extranet-trans esp-3des esp-md5-hmac
!
!#<--The dynamic crypto map requires that a transform set be specified and
!a protected address set to populate the dynamically configured VRF in the
!IPSec SADB. However, the peer does not need to be defined, which is useful
!as in this case, the specific peer addresses of the various extranet partners
!are unknown and change frequently.-->
crypto dynamic-map extranet-dyn 10
 set transform-set extranet-trans
 match address 111
!#<--Each time a remote IPSec peer negotiates a VPN tunnel with this router
!using the dynamic crypto map defined above, a specific route for that
!endpoint will be dynamically injected backwards into the organizations'
!IGP routing table.-->
 reverse-route
!
!
!#<--The static crypto map is necessary to configure, as it is eventually
!referenced by the physical interface configuration. There is no additional
!mandatory configuration within the static crypto map when a dynamic crypto map
!is referenced. This particular crypto map sources updates from a loopback
!address for increased stability-->
crypto map extranet local-address Loopback1
crypto map extranet 10 ipsec-isakmp dynamic extranet-dyn
!
!
!
!
interface Loopback1
 ip address 201.1.1.1 255.255.255.255
!
interface Loopback192
 ip address 192.168.1.1 255.255.255.0
!
interface Serial0/0
 ip address 200.1.1.1 255.255.255.252
 encapsulation frame-relay
 frame-relay interface-dlci 102
 frame-relay lmi-type ansi
!#<--The static crypto map is referenced in the physical interface configuration.
!The dynamic crypto map is indirectly referenced here, as it is bound directly
!to the specified static crypto map below.-->
 crypto map extranet
!
!#<--The crypto protected address space used to populate the VRF each negotiated
!IPSec SA must be configured and referenced in the dynamic crypto map-->
access-list 111 permit ip 192.168.1.0 0.0.0.255 any

Figure 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, and hub configuration is provided in Figure.

Configuration of AS113-3745A

!#<--The extranet partner side of the tunnel is configured with static
!crypto maps and no wildcards in the preshared key-->
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key extranet address 201.1.1.1
!
!
crypto ipsec transform-set extranet-trans esp-3des esp-md5-hmac
!
!<#--Static crypto maps, sourced from a loopback address for stability-->
crypto map extranet local-address Loopback192
crypto map extranet 10 ipsec-isakmp
 set peer 201.1.1.1
 set transform-set extranet-trans
 match address 111
!
!
!
!
interface Loopback111
 ip address 111.1.1.1 255.255.255.0
!
interface Loopback192
 ip address 192.168.111.1 255.255.255.0
!
interface Serial0/0
 ip address 200.1.1.2 255.255.255.252
 encapsulation frame-relay
 no fair-queue
 clockrate 128000
 frame-relay interface-dlci 201
 crypto map extranet
!
access-list 111 permit ip any 192.168.1.0 0.0.0.255

Figure 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.

Figure illustrates the dynamic IPSec SA using the dynamic crypto map referenced in Figure. The protected VRF (proxy) noted in the IPSec SA is consistent with the access list referenced in the dynamic crypto map of Figure. 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.

Verifying the Dynamic Crypto Maps

AS1-7304A#show crypto ipsec sa
 interface: Serial0/0
     Crypto map tag: extranet, local addr. 201.1.1.1
    protected vrf:
    local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
    remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
    current_peer: 192.168.111.1:500
      PERMIT, flags={}
     #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
     #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 0, #recv errors 0
      local crypto endpt.: 201.1.1.1, remote crypto endpt.: 192.168.111.1
      path mtu 1500, media mtu 1500
      current outbound spi: ACD63558

      inbound esp sas:
       spi: 0x1EDD5D8D(517823885)
         transform: esp-3des esp-md5-hmac ,
         in use settings ={Tunnel, }
         slot: 0, conn id: 2000, flow_id: 5, crypto map: extranet
         crypto engine type: Software, engine_id: 1
         sa timing: remaining key lifetime (k/sec): (4474400/1132)
         ike_cookies: 0636F569 27CE6A48 BC7118C8 F037E068
         IV size: 8 bytes
         replay detection support: Y

      inbound ah sas:

      inbound pcp sas:

      outbound esp sas:
       spi: 0xACD63558(2899719512)
         transform: esp-3des esp-md5-hmac ,
         in use settings ={Tunnel, }
         slot: 0, conn id: 2001, flow_id: 6, crypto map: extranet
         crypto engine type: Software, engine_id: 1
         sa timing: remaining key lifetime (k/sec): (4474401/1130)
         ike_cookies: 0636F569 27CE6A48 BC7118C8 F037E068
         IV size: 8 bytes
         replay detection support: Y

      outbound ah sas:

      outbound pcp sas:

The output in Figure 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 Figure.

Verifying Security Association Cryptographic Operations

AS1-7304A#show crypto engine connections active

  ID Interface            IP-Address      State  Algorithm           Encrypt  Decrypt
   3 Serial0/0            200.1.1.1       set    HMAC_MD5+3DES_56_C        0        0
2000 Serial0/0            200.1.1.1       set    HMAC_MD5+3DES_56_C        0        4
2001 Serial0/0            200.1.1.1       set    HMAC_MD5+3DES_56_C        4        0



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows