Scaling IPsec Virtual Private Networks

As you saw in Chapter 6, IPsec tunnels are inherently point to point. The fact that the tunnels are point to point means that there are a number of challenges to be faced when scaling IPsec VPNs to a large number of sites. These challenges can be best illustrated by taking a look at the network shown in Figure 7-1.

Figure 7-1. Sample Topology

The network in Figure 7-1 consists of six sites. If you want direct connectivity between all sites (a full-mesh topology) you need at least n(n 1)/2 IPsec tunnels (pairs of security associations [SA]), where n is the number of sites. For 6 sites, that means 15 tunnels. Not too bad, but what if you have 200 sites? That is a mere 19,900 tunnels!

Some of the major considerations when scaling IPsec VPNs are as follows:

• The maximum number of IPsec tunnels that can be configured on a device
• The amount of configuration necessary
• The type of Internet Key Exchange (IKE) authentication that you use

Each type of device has a finite limit to the number of IPsec tunnels that it can support. This limit depends on a number of factors, including the following:

• The power of the device's CPU
• The amount of memory installed in the device
• Whether a hardware accelerator is installed into the device
• The cryptographic algorithms that you intend to use in your IPsec VPN
• The volume (and packet sizes) of traffic that is expected to pass over each IPsec tunnel

Because devices are constantly changing and new ones are being introduced, no limits are specified here. One useful document to use as a starting point when considering the number of IPsec tunnels that can be supported by a particular device can be found in the data sheet "Cisco IPSec and SSL VPN Solutions" located at the following URL:

http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/netbr09186a00801f0a72.html

Note

Note that the preceding URL contains performance data of devices tested under ideal conditions (there were no other processes running on the router, the packet sizes were fixed, there was a following wind, and so on).

The amount of configuration is also a key factor to consider when designing IPsec VPNs. It would be extremely laborious, for example, to manually configure the 19,900 IPsec tunnels mentioned in the previous example.

So, manual configuration of each IPsec tunnel is fine for small deployments, but for large-scale installations it is clearly impractical.

Another important consideration is the type of IKE authentication that you use. If you use a unique preshared key for each pair of gateways, and you require direct connectivity between all VPN sites, you need n(n 1)/2 preshared keys15 preshared keys for an IPsec VPN with 6 sites, but 19,900 preshared keys for an IPsec VPN with 200 sites.

The sections that follow examine ways to reduce the number of IPsec tunnels required, reducing the amount of configuration, and scaling IKE authentication.

Reducing the Number of IPsec Tunnels Required in a VPN

A traditional solution for the problem of the exponential growth in the number of IPsec tunnels is to deploy a hub-and-spoke architecture, such as that illustrated in Figure 7-2.

Figure 7-2. Hub-and-Spoke Network Architecture

The advantage of the hub-and-spoke architecture becomes pretty clear just by looking at Figure 7-2the number of IPsec tunnels is now n 1. So, for the 6-site VPN shown in Figure 7-2, you need 5 tunnelsa significant reduction of the 15 tunnels required for a full mesh. For a 200-site VPN, 199 tunnels are requireda huge reduction on the 19,900 tunnels required for a full mesh.

There are, however, a number of drawbacks and considerations with the hub-and-spoke topology in comparison to the full-mesh topology:

• Traffic latency is increased for spoke-to-spoke user traffic because it must transit the hub site. Traffic latency will be of particular concern if you are deploying real-time or delay-sensitive applications such as voice and video.
• Because spoke-to-spoke traffic must transit the hub router, the amount of bandwidth required at the hub site is increased. The amount of bandwidth required at the hub site depends on the amount of spoke-to-hub traffic and spoke-to-spoke traffic.
• The CPU and memory overhead is increased on the hub site router because the hub site router must decrypt and then re-encrypt traffic as it transits between spoke sites.
• There is a finite limit to the number of IPsec tunnels that a single hub site router can support.

One way to get around some of the limitations listed in the previous section is to extend the hub-and-spoke architecture so that it becomes a hierarchical hub-and-spoke architecture, such as that illustrated in Figure 7-3.

Figure 7-3. Hierarchical Hub-and-Spoke IPsec VPN

In Figure 7-3, there are three levels of hierarchy:

• The access layer (the bottom-most level)
• The distribution layer (the mid level)
• The core layer (the top level)

This type of hierarchical model is well understood and widely deployed. If you split the network into three levels of hierarchy based on traffic flow and geography, the VPN can scale to a much greater degree than the simple hub-and-spoke architecture described previously.

The hierarchical hub-and-spoke architecture alleviates two of the main concerns with the simple hub-and-spoke model:

• It alleviates the CPU and memory overhead on a single hub router. The VPN architecture is now distributed, and CPU and memory overhead should be distributed over a number of (regional) hub routers.
• The number of IPsec tunnels that each of the (regional) hub site routers must support is much smaller than the number that would otherwise have to be supported by a single-hub site router.

Reducing IPsec VPN Configuration Complexity with TED and DMVPN

One of the challenges when scaling an IPsec VPN to include a large number of IPsec VPN gateways is the sheer amount of configuration required on each gateway as the VPN grows.

In a full-mesh IPsec VPN with 250 gateways, for example, each gateway normally requires 249 static crypto map entries (1 for each other gateway). When a new gateway is added to an IPsec VPN, the new gateway must be configured with crypto map entries to support each of the existing gateways. And a new crypto map entry must be added on each existing IPsec VPN gateway.

So, in large-scale full-mesh IPsec VPNs, a large amount of configuration is normally required. This configuration can prove difficult to manage and troubleshoot.

If you want to reduce the amount of configuration on each IPsec gateway, you have two possible solutions:

• Tunnel Endpoint Discovery
• Dynamic Multipoint VPN

TED and DMVPN are discussed in detail in the following two sections.

Tunnel Endpoint Discovery (TED)

TED is a Cisco proprietary enhancement for IKE that enables IPsec peers to dynamically discover each other and then proceed with phase 1 and 2 IKE negotiation. If the peers already have an IKE SA in place, IKE phase 1 negotiation can be skipped, and the peers can jump straight to phase 2 negotiation.

Because TED dynamically discovers remote peers, static configuration of peers is not required. Instead of static configuration, a dynamic crypto map is configured on each TED-enabled IPsec peer.

Figure 7-4 shows the operation of TED.

Figure 7-4. TED Operation

In Figure 7-4, Host A at the London site sends a user packet to Host B at the Paris site.

The London gateway intercepts the user packet from Host A and checks whether there is an IPsec SA corresponding to the packet. There is no existing IPsec SA, so the London gateway drops the packet from Host A and sends a TED Probe packet toward Host B. The TED Probe packet is an unencrypted ISAKMP packet and uses the same source and destination IP addresses as the original user packet (in this case, the source IP address is 10.1.1.2 [Host A], and the destination IP address is 10.2.2.2 [Host B]).

The Paris gateway intercepts the TED Probe packet and, after it has checked that the Probe corresponds to traffic that should be protected by IPsec (Host A's and B's IP addresses), the Paris gateway sends a TED Reply (response) packet to the London gateway. The TED Reply is also an unencrypted ISAKMP packet.

The London gateway receives the TED Reply and verifies that the TED Reply corresponds to the TED Probe that it sent. After the London gateway has verified this, the London gateway initiates IKE negotiation with the Paris gateway, IPsec tunnel setup completes as normal, and user packets can be transmitted over the IPsec tunnel between Host A and Host B.

Example 7-1 shows the configuration of the London and Paris IPsec VPN gateways.

Example 7-1. Configuration of TED on the London and Paris Gateways

London#show running-config
Building configuration...
!
! London gateway's configuration
!
!
! IKE (ISAKMP) Policy
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
!
! Wildcard Pre-Shared Key
!
crypto isakmp key cisco address 0.0.0.0 0.0.0.0 (line 1)
!
!
! IPsec Transform Set
!
crypto ipsec transform-set mjlnettransform esp-des esp-md5-hmac
!
!
! Dynamic Crypto Map Entry
!
crypto dynamic-map mjlnetted 10 (line 2)
 set transform-set mjlnettransform
 match address 101
!
!
! Parent Crypto Map Entry
!
crypto map mjlnetcmap 10 ipsec-isakmp dynamic mjlnetted discover (line 3)
!
!
! Outside Interface
!
interface Serial1/0
 ip address 192.168.1.1 255.255.255.0
 crypto map mjlnetcmap (line 4)
!
!
! Inside Interface
!
interface FastEthernet3/0
 ip address 10.1.1.1 255.255.255.0
!
!
! Crypto Access List
!
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
!
Paris#show running-config
Building configuration...
!
! Paris gateway's configuration
!
!
! IKE (ISAKMP) Policy
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
!
! Wildcard Pre-Shared Key
!
crypto isakmp key cisco address 0.0.0.0 0.0.0.0 (line 5)
!
!
! IPsec Transform Set
!
crypto ipsec transform-set mjlnettrans esp-des esp-md5-hmac
!
!
! Dynamic Crypto Map Entry
!
crypto dynamic-map mjlnetted 10 (line 6)
 set transform-set mjlnettrans
 match address 101
!
!
! Parent Crypto Map Entry
!
crypto map mjlnetcmap 10 ipsec-isakmp dynamic mjlnetted discover (line 7)
!
!
! Inside Interface
!
interface FastEthernet1/0
 ip address 10.2.2.1 255.255.255.0
!
!
! Outside Interface
!
interface Serial2/0
 ip address 192.168.2.2 255.255.255.0
 crypto map mjlnetcmap (line 8)
!
!
! Crypto Access List
!
access-list 101 permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255
!
!

In highlighted line 1, you can see a wildcard preshared key (crypto isakmp key keystring address 0.0.0.0 0.0.0.0). This wildcard preshared allows all other gateways in the VPN (including Paris) to connect to the London gateway.

As discussed in Chapter 6, wildcard preshared keys can be insecure, so if you configure TED, it is a good idea to use Rivest, Shamir, and Adlemen (RSA) digital signature authentication (using digital certificates).

Line 2 shows the crypto dynamic-map dynamic-map-name dynamic-seq-num command. This command is used to configure a dynamic crypto map entry (called, in this example, mjlnetted).

Dynamic crypto maps are similar to regular (static) crypto maps but allow a gateway to accept connections from peers even if not all parameters are known in advance. In this case, the IP addresses of remote gateways are not known in advance. Notice that the dynamic crypto map does not require the configuration of the set peer command, which is used with regular crypto maps to specify the IP address or host name of remote gateways.

The crypto map map-name seq-num ipsec-isakmp dynamic dynamic-map-name discover command shown in line 3 is used to configure a parent crypto map entry (called mjlnetcmap here), which links to the dynamic crypto map entry in line 2. The parent crypto map is applied to the outside interface (see line 4).

The parent crypto map entry called mjlnetcmap links to the dynamic crypto map entry mjlnetted. The discover keyword enables TED for use with the crypto map.

Lines 5, 6, 7, and 8 show the configuration of the wildcard preshared key, dynamic crypto map entry, and parent crypto map on the Paris gateway. Notice that their configuration on the Paris gateway is identical to that for the London gateway.

And that is itpretty simple really. But, it really does reduce the amount of configuration required in large-scale IPsec VPNs because individual crypto map entries are no longer required for each remote gateway.

So, TED can help to reduce the amount of configuration required on IPsec VPN gatewaysa major benefit. However, there is one drawback to TEDthe addresses of hosts on the inside interfaces of IPsec VPN gateways (using IP addresses specified in the crypto access lists) must use globally routable IP addresses. That is, routers and other devices in the path between IPsec VPN gateways must have routes to the IP addresses specified in your crypto access lists.

In Figure 7-4, for example, networks 10.1.1.0/24 and 10.2.2.0/24 (including the addresses of Hosts A and B) must be reachable from the routers in the backbone network.

If your IPsec VPN is deployed over the Internet, addresses specified in your crypto access lists must be public (globally routable) IP addresses.

Dynamic Multipoint Virtual Private Network (DMVPN)

As discussed previously in the section "Reducing the Number of IPsec Tunnels Required in a VPN," one problem in a hub-and-spoke IPsec VPN where there is spoke-to-spoke traffic is that this traffic must transit the hub site. Spoke-to-spoke traffic puts additional demands on the hub site (gateway), both in terms of bandwidth requirements and packet processing (additional decrypt and encrypt). Furthermore, spoke-to-spoke traffic transiting the hub site incurs additional delay, which might cause problems with real-time applications such as voice and video.

One solution to these problems is to configure point-to-point IPsec tunnels between the spoke sites, but this just gives you a full or partial mesh of static IPsec tunnels. The amount of configuration required on the gateways then grows quickly because you need one tunnel interface per remote gateway, one crypto access list per remote gateway and (usually) one crypto map statement for each remote gateway.

The entry of the configuration on the gateways is onerous enough, but the additional configuration complexity also makes management and troubleshooting that much more difficultimagine wading through hundreds of lines of configuration looking for a single mistake! Not pleasant.

A much more scalable solution to the problem of spoke-to-spoke traffic and configuration complexity is Cisco-proprietary DMVPN. DMVPN was introduced in Cisco IOS Software Release 12.2(13)T.

One main advantage of DMVPN is that it dramatically reduces the amount of configuration on hub and spoke site gateways (when compared to a traditional hub-and-spoke and full/partial-mesh architectures). Additional benefits include the following:

• Spoke-to-spoke tunnels are dynamically created on an as-needed basis and do not require explicit configuration.
• Direct spoke-to-spoke tunnels created in a DMVPN environment reduce spoke site-to-spoke site latency.
• CPU and memory overhead is reduced on the hub site gateway(s) because spoke-to-spoke traffic does not now need to transit the hub (in any significant volume).
• Because spoke-to-spoke traffic does not transit the hub, bandwidth requirements at the hub site are reduced.

Before making a decision to deploy DMVPN, it is important to fully understand how it works and how it is configured. These subjects are discussed in the following two sections.

How DMVPN Works

So, DMVPN provides an answer to the problem of IPsec VPN configuration scalability, but how exactly does it work? The fundamentals of DMVPN are remarkably simple.

DMVPN is based on the Next Hop Resolution Protocol (NHRP), which is described in RFC2332. NHRP provides mechanisms that allow a source host or a router connected to a nonbroadcast multiaccess (NBMA) network to determine the network layer and associated NBMA address of either the destination host or router, or the NBMA address of the egress router that is closest to the destination host or router.

DMVPN modifies this paradigm slightly by using NHRP to enable a source DMVPN gateway to determine the physical interface IP address of the DMVPN gateway closest to a destination. The source DMVPN gateway then dynamically builds a Generic Routing Encapsulation (GRE)/IPsec tunnel directly to the DMVPN gateway closest to the destination. After the tunnel is built, the source DMVPN gateway forwards user traffic directly to the destination site.

So, that is a high-level description of DMVPN. To explain how DMVPN works in detail, it is a good idea to start with the sample topology shown in Figure 7-5.

Figure 7-5. Sample DMVPN Topology

As you can see in Figure 7-5, there are six sites in the DMVPN: the hub site in London; and spoke sites in Copenhagen, Hamburg, Berlin, Milan, and Paris.

Each of the spoke site gateways automatically initiates an IPsec-protected GRE tunnel configured to the London-1 hub site gateway as soon as it is switched on (or initially configured for DMVPN). In Figure 7-5, the letter G indicates IP addresses applied to gateway GRE tunnel interfaces, and the letter P indicates IP addresses applied to physical interfaces. The physical IP addresses are routable over the service provider backbone/Internet.

In this scenario, the gateway at the London (hub) site is configured as a Next Hop Server (NHS), and the spoke site gateways are configured as Next Hop Clients (NHC).

Each of the spoke site gateways (the NHCs) sends an NHRP Registration Request message to the London-1 gateway (the NHS) on startup. The purpose of these Registration Request messages is to notify the NHS of the NHCs' physical and GRE tunnel interface addresses. The NHS (London) caches these physical to GRE tunnel address mappings, and responds to the NHCs with a Registration Reply message.

If configured to do so, the NHS also adds broadcast/multicast mappings for spoke sites when they register. These multicast mappings allow multicast traffic such as routing protocol traffic to be sent over the tunnels between the hub-and-spoke sites.

Figure 7-6 illustrates the NHRP registration process.

Figure 7-6. The NHRP Registration Process

The NHS (hub site gateway) caches the NHCs' physical interface to GRE tunnel interface address mappings. So, after all the NHCs (spoke site gateways) have registered with the NHS, the NHS's cache will be as shown in Table 7-1.

Table 7-1. NHS's Cache After All NHCs Register

NHC	Physical Interface Address	GRE Tunnel Interface Address
Copenhagen	192.168.14.2	10.3.3.6
Hamburg	192.168.11.2	10.3.3.5
Berlin	192.168.2.2	10.3.3.2
Milan	192.168.8.2	10.3.3.4
Paris	192.168.5.2	10.3.3.3

Now what happens if one of the spoke site gateways needs to send some traffic to another spoke site? Imagine that the Paris gateway receives a packet from host 10.11.11.1 (on its local LAN) destined for host 10.13.13.1 at the Hamburg site.

In this case, the Paris gateway finds a route to destination 10.13.13.0/24 in its routing table with a next hop of 10.3.3.5 (the GRE tunnel interface address of the Hamburg gateway). So, the Paris gateway has the next-hop address (10.3.3.5), but because this next-hop address is not a globally routable IP address, the Paris router needs to find the globally routable IP address (the physical interface IP address) of the gateway to which the GRE tunnel interface address 10.3.3.5 belongs.

At this point, the Paris gateway checks its local cache of NHRP mappings and finds no mapping for next-hop address 10.3.3.5. The Paris gateway then sends a NHRP Resolution Request message to the London-1 gateway (the NHS) requesting the physical interface (globally routable) address to which the next-hop (GRE tunnel interface) address 10.3.3.5 corresponds.

The London-1 gateway looks in its NHRP cache (see Table 7-1), finds that physical interface address 192.168.11.2 corresponds to next-hop address 10.3.3.5, and sends this information back to the Paris gateway in an NHRP Resolution Reply message. The Paris gateway enters this information in its NHRP cache.

The Paris gateway now has all the information it needs (a globally routable physical interface address), and so builds an IPsec protected GRE (GRE/IPsec) tunnel directly to the Hamburg gateway. After the tunnel has been built, packets from host 10.11.11.1 at the Paris site can be sent directly to host 10.13.13.1 at the Hamburg site.

Figure 7-7 illustrates dynamic setup of the IPsec/GRE tunnel from the Paris gateway to the Hamburg gateway.

Figure 7-7. Dynamic IPsec/GRE Tunnel Setup from the Paris Gateway to the Hamburg Gateway

You might be wondering what happens to data traffic sent from host 10.11.11.1 (at the Paris site) to host 10.13.13.1 (at the Hamburg site) while the Paris gateway is in the process of setting up the IPsec/GRE tunnel directly to the Hamburg gateway. The initial few packets are, in fact, sent between the Paris and Hamburg sites via the London-1 gateway.

The IPsec/GRE tunnel between the Paris and Hamburg gateways remains in place as long as there is traffic passing over it, and for an additional (configurable) idle period. After this idle period has passed without any more traffic passing over the tunnel, it is torn down. If either gateway subsequently needs to send traffic to the other, an IPsec/GRE tunnel must again be dynamically built as previously described.

Deploying a DMVPN Architecture

When deploying a DMVPN, you must configure two types of devices:

• Hub site gateway(s)
• Spoke site gateways

Configuration of these two DMVPN device types is discussed in the following sections.

Configuring the DMVPN Hub Site Gateway

The first step in deploying the single hub router DMVPN architecture (as shown in Figure 7-5) is to configure the hub site gateway (the NHS).

Hub site gateway configuration involves the following steps:

Step 1.	Configure the IKE policy (including authentication).
Step 2.	Configure the IPsec transform set.
Step 3.	Configure the IPsec profile.
Step 4.	Configure common parameters on the multipoint GRE (mGRE) tunnel interface.
Step 5.	Configure the routing protocol for site-to-site reachability.

The first two steps have already been described in Chapter 6, and so are not discussed further here. See Chapter 6 for more information.

Steps 3, 4, and 5 are discussed further in the following sections.

It is worth noting that although this section discusses the configuration of a single DMVPN hub site gateway, it is possible to configure redundant hub site gateways in a DMVPN. Configuration of redundant hub site gateways in a DMVPN is discussed in the section "High Availability with DMVPN" later in this chapter.

Step 3: Configure the IPsec Profile A crypto profile is a way to bring together a number of IPsec policy settings that can then be referenced elsewhere in a configuration file. Although a crypto profile is similar to a crypto map, it is not possible to specify either a crypto access list or a peer address within a crypto profile.

Example 7-2 shows the configuration of the crypto profile.

Example 7-2. Configuration of a Crypto Profile

!
crypto ipsec profile mjlnetprofile
 set transform-set mjlnettransform
!

In Example 7-2, the crypto ipsec profile name command is used to configure a profile called mjlnetprofile.

The set transform-set transform-set-name command is then used to specify an IPsec transform set called mjlnettransform.

When using DMVPN, GRE/IPsec tunnels are automatically built, with the crypto access lists and (spoke) peer addresses being automatically derived from NHRP mappings.

Step 4: Configure Common Parameters on the mGRE Tunnel Interface After the IPsec profile has been configured, the next step is to configure common parameters on the mGRE tunnel interface.

Assuming one DMVPN, you need to configure one mGRE tunnel interface on the hub gateway no matter how many spoke gateways there are.

The configuration of the mGRE tunnel interface consists of several steps:

1.	Configure the IP address.
2.	Configure NHRP parameters.
3.	Configure tunnel parameters.
4.	Associate the tunnel interface with the IPsec profile.

Example 7-3 shows the configuration of the mGRE tunnel interface.

Example 7-3. Configuration of the mGRE Tunnel Interface on the Hub Site Gateway

!
interface Tunnel0
 ip address 10.3.3.1 255.255.255.0
 ip nhrp authentication mjlnet
 ip nhrp map multicast dynamic
 ip nhrp network-id 1234
 tunnel source 192.168.1.1
 tunnel mode gre multipoint
 tunnel key 5678
 tunnel protection ipsec profile mjlnetprofile
!

The ip address ip-address mask command is used to configure the IP address 10.3.3.1/24 on tunnel interface 0 in Example 7-3.

The ip nhrp authentication string command is used to configure an authentication string for DMVPN gateways. This string must be identical for all gateways in a particular DMVPN.

Next is the ip nhrp map multicast dynamic command. This command allows the hub gateway to automatically add spoke gateways to its NHRP multicast mapping table. This is necessary to ensure that dynamic routing protocols (that send multicast traffic) work correctly over the DMVPN.

The ip nhrp network-id number command is then used to configure the NHRP network ID. The NHRP network ID uniquely identifies the NHRP network, and must be configured identically on all gateways in the same DMVPN.

The tunnel source {ip-address | interface-type interface-number} command is used to configure the source IP address of the tunnel.

One thing to notice in Example 7-3 is the absence of the tunnel destination command. This command is required when configuring point-to-point GRE tunnels but not when configuring mGRE tunnels.

The tunnel mode is then configured as mGRE using the tunnel mode gre multipoint command.

The tunnel key key-number command is used to configure an ID key for the tunnel interface. This ID key, together with the authentication string and network ID specified with the ip nhrp authentication and ip nhrp network-id commands, is used to map NHRP and tunnel packets to this particular mGRE interface. The tunnel key must be configured identically on all gateways for a particular DMVPN.

The final command configured on the tunnel interface is tunnel protection ipsec profile name. This associates the IPsec profile configured in Step 3 with the tunnel interface.

Tip

Although not shown in Example 7-3, one other command that you might want to add to the configuration is ip nhrp holdtime seconds. You can use this command to configure the number of seconds that addresses are advertised as valid in authoritative NHRP responses. The default value is 7200 seconds (2 hours), but a much more practical value for DMVPN is 300 to 600 seconds. It is a good idea to add this command on all routers in a DMVPN.

Step 5: Configure the Routing Protocol for Site-to-Site Reachability Having configured the mGRE tunnel interface, the next step is to configure the routing protocol for site-to-site reachability.

You can use a number of routing protocols for site-to-site reachability in a DMVPN, the most popular of which are the following:

• OSPF
• EIGRP
• RIP

Configuration of these routing protocols on a DMVPN hub site gateway is discussed in the following three sections.

OSPF If you decide to use Open Shortest Path First (OSPF) for site-to-site reachability, be sure to enable OSPF on the mGRE interface and the inside interfaces (as appropriate). You must also ensure that the hub gateway is configured as the OSPF Designated Router (DR). If there is more than one hub site gateway, make sure that another hub site gateway is configured as the Backup Designated Router (BDR). Finally, make sure that all gateways in the DMVPN are configured to use the OSPF broadcast network type on their mGRE tunnel interfaces.

Example 7-4 provides a sample configuration of OSPF on a hub site gateway.

Example 7-4. Sample Configuration of OSPF for Site-to-Site Reachability

!
router ospf 100
 network 10.1.1.0 0.0.0.255 area 0
 network 10.3.3.0 0.0.0.255 area 0
!
interface Tunnel0
 ip ospf priority 100
 ip ospf network broadcast
!

In Example 7-4, the router ospf process-id command is used to enable OSPF process 100, and the network network [wildcard-mask] area area-number command is used to enable OSPF area 0 on the inside interface (10.1.1.1, in this example), and the mGRE tunnel interface (10.3.3.1, in this example).

The ip ospf priority priority command is then configured on the mGRE interface. This command must be used to specify high (higher than spoke site) priority values on hub site gateways' mGRE interfaces, thus ensuring that hub site gateways become the DR and BDR. In fact, it is a good idea to specify an OSPF priority value of 0 on spoke site gateways' mGRE interfaces, so that the spoke site gateways can never become the DR or BDR.

Finally, the ip ospf network broadcast command is used to specify the OSPF broadcast network type on the hub site gateways' mGRE interfaces. This command allows GRE/IPsec tunnels to be built directly between spoke sites for spoke site-to-spoke site user traffic.

EIGRP When using Enhanced Interior Gateway Routing Protocol (EIGRP) for site-to-site reachability, you should enable EIGRP on the mGRE tunnel interface and inside interfaces (as appropriate). You must also disable IP split horizon and IP next-hop-self on the mGRE tunnel interface.

Example 7-5 provides a sample configuration of EIGRP on a hub site gateway.

Example 7-5. Sample Configuration of EIGRP for Site-to-Site Reachability

!
router eigrp 100
 network 10.1.1.0 0.0.0.255
 network 10.3.3.0 0.0.0.255
 no auto-summary
!
!
interface Tunnel0
 no ip next-hop-self eigrp 100
 no ip split-horizon eigrp 100
!

In Example 7-5, the router eigrp autonomous-system command is used to enable EIGRP autonomous system 100, and the network network [wildcard-mask] command is used to enable EIGRP on the hub site gateway's inside interface (10.1.1.1 in this example), and on the mGRE tunnel interface (10.3.3.1 in this example).

The no auto-summary command in Example 7-5 ensures that networks are not auto-summarized at major network boundaries.

The no ip split-horizon eigrp autonomous-system-number command disables IP split horizon for EIGRP, thus allowing the hub site to re-advertise routes received on its mGRE interface from one spoke site to other spoke sites on the same interface. This command allows spoke site-to-spoke site reachability.

The no ip next-hop-self eigrp autonomous-system-number command is used to ensure that all EIGRP routes that are received from one spoke site are re-advertised to other spoke sites with their original (spoke site) IP next hop. Re-advertisement of routes by the hub site with their original spoke site IP next hop is important to ensure that spoke sites build GRE/IPsec tunnels directly between themselves for spoke site-to-spoke site user traffic.

RIP Configuration of Routing Information Protocol (RIP) for site-to-site reachability in a DMVPN is relatively easy. You must simply enable RIP on the mGRE interface and inside interfaces (as appropriate), and disable IP split horizon on the mGRE tunnel interface.

Example 7-6 provides a sample RIP configuration for a hub site gateway.

Example 7-6. Sample Configuration of RIP for Site-to-Site Reachability

!
router rip
 version 2
 network 10.0.0.0
 no auto-summary
!
!
interface Tunnel0
 no ip split-horizon
!

In Example 7-6, the router rip and version 2 commands are used to enable RIP Version 2. The network network and no auto-summary commands are then used to enable RIP on the mGRE (10.3.3.1) and inside (10.1.1.1) interfaces and disable auto-summarization of routes at major network boundaries respectively.

The no ip split-horizon command is used to disable IP split horizon on the mGRE tunnel interface and allow the hub site to re-advertise routes received on the mGRE interface from one spoke site to other spoke sites on the same interface. This command ensures spoke site-to-spoke site reachability. Note that because the hub site automatically re-advertises spoke site routes with their original IP next hop when using RIP, spoke sites will automatically build GRE/IPsec tunnels directly between themselves for spoke site-to-spoke site user traffic.

Complete Sample Hub Site Gateway DMVPN Configuration

Example 7-7 shows a sample hub site gateway DMVPN configuration. Only the relevant portions of the configuration are shown.

Example 7-7. Complete Sample Hub Site Gateway DMVPN Configuration

London-1#show running-config
Building configuration...
Current configuration : 2546 bytes
!
! IKE policy
!
crypto isakmp policy 10
 authentication pre-share
!
!
! Wildcard pre-shared key
!
crypto isakmp key mjlnet address 0.0.0.0 0.0.0.0
!
!
! IPsec transform set
!
crypto ipsec transform-set mjlnettransform esp-3des esp-sha-hmac
!
!
! IPsec profile
!
crypto ipsec profile mjlnetprofile
 set transform-set mjlnettransform
!
!
! mGRE tunnel interface
!
interface Tunnel0
 ip address 10.3.3.1 255.255.255.0
 no ip next-hop-self eigrp 100
 ip nhrp authentication mjlnet
 ip nhrp map multicast dynamic
 ip nhrp network-id 1234
 no ip split-horizon eigrp 100
 tunnel source 192.168.1.1
 tunnel mode gre multipoint
 tunnel key 5678
 tunnel protection ipsec profile mjlnetprofile
!
!
! Inside interface
!
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.0
!
!
! Outside interface
!
interface Serial1/0
 ip address 192.168.1.1 255.255.255.0
!
!
! EIGRP for site-to-site reachability
!
router eigrp 100
 network 10.1.1.0 0.0.0.255
 network 10.3.3.0 0.0.0.255
 no auto-summary
!
!

Although most of the configuration as been previously explained, notice that the highlighted line shows that a wildcard preshared key is used for IKE authentication. This wildcard preshared key is used for illustrative purposes only.

Configuring the DMVPN Spoke Site Gateways

After the hub site gateway has been configured, you can move on to configuring spoke site gateways.

The configuration of spoke site gateways comprises five steps:

Step 1.	Configure the IKE policy (including authentication).
Step 2.	Configure the IPsec transform set.
Step 3.	Configure the crypto map or IPsec profile.
Step 4.	Configure common parameters on the GRE tunnel interface.
Step 5.	Configure the routing protocol for site-to-site reachability.

Configuration of spoke site gateways is, as you can see, similar to that for the hub site gateway. There are, however, one or two differences when configuring the GRE tunnel interface and configuring the routing protocol for site-to-site reachability.

Configuring Common Parameters on the GRE Tunnel Interface of Spoke Site Gateways You have two choices when configuring the GRE tunnel interface on a spoke site gateway:

• You can configure point-to-point GRE tunnel interfaces.
• You can configure multipoint GRE tunnel interfaces.

Although an mGRE tunnel is required on spoke site gateways to support the transport of user traffic directly between spoke sites, point-point-point tunnels can be useful if spoke sites have not yet been upgraded to Cisco IOS Software Release 12.2(13)T or later. If you do configure point-to-point GRE tunnels on spoke site gateways, spoke-to-spoke user traffic is transported via the hub site.

Example 7-8 shows the configuration of a point-to-point GRE tunnel interface on a spoke site gateway running a Cisco IOS version prior to 12.2(13)T.

Example 7-8. Configuration of a Point-to-Point GRE Tunnel Interface on a Spoke Site Gateway

!
interface Tunnel0
 ip address 10.3.3.3 255.255.255.0
 ip nhrp authentication mjlnet
 ip nhrp map 10.3.3.1 192.168.1.1 (line 1)
 ip nhrp network-id 1234
 ip nhrp nhs 10.3.3.1 (line 2)
 tunnel source 192.168.2.2
 tunnel destination 192.168.1.1 (line 3)
 tunnel key 5678
 crypto map mjlnetmap (line 4)
!

Some of the commands shown in Example 7-8 were described in the previous section, and so are not discussed here. Commands that have not been previously described are highlighted in Example 7-8.

Highlighted line 1 shows the ip nhrp map physical-ip-address gre-tunnel-interface-ip-address command. This command is used to build an NHRP mapping of the hub gateway's outside physical interface IP address to its GRE tunnel interface IP address. In this example, the IP address configured on the hub gateway's physical interface is 192.168.1.1, and the IP address configured on its mGRE tunnel interface is 10.3.3.1.

Line 2 shows the ip nhrp nhs nhs-gre-interface-ip-address command, which is used to specify the (mGRE tunnel interface) IP address of the NHS. The NHS is the hub site gateway.

The tunnel destination {hostname | ip-address} command shown in line 3 then specifies the GRE tunnel destination. In this case, the tunnel destination is the hub site gateway's GRE tunnel source address (192.168.1.1, its outside physical interface).

Finally, the crypto map map-name in line 4 applies a crypto map to the GRE tunnel interface. Because the configuration shown in Example 7-8 applies to spoke site gateways running Cisco IOS versions prior to 12.2(13)T, you must apply a crypto map to the GRE tunnel interface in addition to the outside physical interface. See the section "Transporting Multiprotocol and Multicast Traffic over an IPsec VPN" in Chapter 6 for more details on the configuration and application of a crypto map for a point-to-point GRE tunnel.

The configuration of an mGRE tunnel interface on a spoke site gateway differs slightly, as shown in Example 7-9. In this case, the spoke site gateway is running Cisco IOS Software Release 12.2(13)T or later.

Example 7-9. Configuration of an mGRE Tunnel Interface on a Spoke Site Gateway

!
interface Tunnel0
 ip address 10.3.3.3 255.255.255.0
 ip nhrp authentication mjlnet
 ip nhrp map 10.3.3.1 192.168.1.1
 ip nhrp map multicast 192.168.1.1
 ip nhrp network-id 1234
 ip nhrp nhs 10.3.3.1
 tunnel source 192.168.2.2
 tunnel mode gre multipoint
 tunnel key 5678
 tunnel protection ipsec profile mjlnetprofile
!

There are three main differences when compared to the configuration of point-to-point GRE tunnel interfaces on spoke site gateways:

• The GRE tunnel interface is configured to use GRE multipoint mode using the tunnel mode gre multipoint command.
• The tunnel protection ipsec profile command is used apply an IPsec profile.
• Because an IPsec profile is applied to the mGRE tunnel interface, a crypto map is not required.

For more information on these commands, as well as the configuration of the IPsec profile, see the previous section, "Configuring the DMVPN Hub Site Gateway."

Configuring the Routing Protocol for Site-to-Site Reachability on the Spoke Site Gateways The configuration of the routing protocol for site-to-site reachability on the spoke site gateways is again similar to that on hub site gateways. The differences are as follows:

• When using OPSF for site-to-site reachability, you should configure an OSPF priority of 0 on the GRE tunnel interfaces of all spoke site gateways using the ip opsf priority 0 command. This command ensures that spoke gateways cannot become the OSPF DR or BDR.
• When using EIGRP, you should not disable IP split horizon using the no ip split-horizon eigrp command, nor configure the no ip next-hop-self eigrp command on the GRE tunnel interfaces of spoke gateways. This is because spoke site gateways are not required to re-advertise routes that they receive from other gateways.
• If you use RIP, you should not disable IP split horizon on the GRE tunnel interfaces of spoke gateways. Again, this is because spoke gateways are not required to re-advertise routes that they receive from other gateways.

Complete Sample Spoke Site Gateway DMVPN Configuration

Example 7-10 shows a sample spoke site gateway configuration (with an mGRE tunnel interface). Note that only relevant portions of the configuration are shown.

Example 7-10. Complete Sample Spoke Site Gateway DMVPN Configuration

Berlin#show running-config
Building configuration...
Current configuration : 2546 bytes
!
! IKE policy
!
crypto isakmp policy 10
 authentication pre-share
!
!
! Wildcard pre-shared key
!
crypto isakmp key mjlnet 0.0.0.0 0.0.0.0
!
!
! IPsec transform set
!
crypto ipsec transform-set mjlnettransform esp-3des esp-sha-hmac
!
!
! IPsec profile
!
crypto ipsec profile mjlnetprofile
 set transform-set mjlnettransform
!
!
! mGRE tunnel interface
!
interface Tunnel0
 ip address 10.3.3.3 255.255.255.0
 ip nhrp authentication mjlnet
 ip nhrp map 10.3.3.1 192.168.1.1
 ip nhrp map multicast 192.168.1.1
 ip nhrp network-id 1234
 ip nhrp nhs 10.3.3.1
 tunnel source 192.168.2.2
 tunnel mode gre multipoint
 tunnel key 5678
 tunnel protection ipsec profile mjlnetprofile
!
!
! Inside interface
!
interface FastEthernet2/0
 ip address 10.10.10.1 255.255.255.0
!
!
! Outside interface
!
interface FastEthernet2/0
 ip address 192.168.2.2 255.255.255.0
!
!
! EIGRP for site-to-site reachability
!
router eigrp 100
 network 10.2.2.0 0.0.0.255
 network 10.3.3.0 0.0.0.255
no auto-summary
!
!

Note that the wildcard preshared key shown in the highlighted line is used for illustrative purpose only. See Chapter 6 for more information on wildcard preshared keys.

Configuring DMVPN on Spoke Site Gateways with Dynamically Assigned IP Addresses

The configuration shown in Example 7-10 is applicable to spoke site gateways whose outside physical interface IP addresses are statically assigned, but it is possible to configure DMVPN on spoke site gateways whose IP addresses are dynamically assigned. This feature can prove useful when spoke sites do not have a statically assigned address, but instead rely on the assignment of an IP address by their local ISP's Dynamic Host Configuration Protocol (DHCP) server.

Example 7-11 shows the configuration of a spoke site gateway configured with a point-to-point GRE tunnel when it is using DHCP for address assignment.

Example 7-11. Configuration of a Point-to-Point GRE Tunnel Interface on a Spoke Site Gateway When Using DHCP for Address Assignment

!
! Configures the local source IP address for IPsec and IKE traffic
!
crypto map mjlnetmap local-address FastEthernet 1/0 (line 1)
!
!
! Crypto map
!
crypto map mjlnetmap 10 ipsec-isakmp
 set peer 192.168.1.1
 set security-association level per-host (line 2)
 set transform-set mjlnettransform
 match address 101
!
!
! Point-to-point GRE tunnel interface
!
interface Tunnel0
 ip address 10.3.3.3 255.255.255.0
 ip nhrp authentication mjlnet
 ip nhrp map 10.3.3.1 192.168.1.1
 ip nhrp network-id 1234
 ip nhrp nhs 10.3.3.1
 tunnel source FastEthernet1/0 (line 3)
 tunnel destination 192.168.1.1
 tunnel key 5678
 crypto map mjlnetmap
!
!
! Outside interface
!
interface FastEthernet 1/0
 ip address dhcp (line 4)
 crypto map mjlnetmap
!
!
! Crypto access list
!
access-list 101 permit gre 192.168.2.0 0.0.0.255 host 192.168.1.1 (line 5)
!

Most of the configuration shown in Example 7-11 has already been discussed, but the highlighted lines have special significance.

In highlighted line 1, the crypto map map-name local-address interface-id command is used to configure the local source IP address to be used for all IPsec and IKE traffic.

The crypto access list in line 5 differs slightly from that regularly used for a point-to-point GRE tunnel (see the section "Transporting Multiprotocol and Multicast Traffic over an IPsec VPN" in Chapter 6). If you take a closer look at the source IP address, you will notice that it is not a host address (the specific GRE tunnel source IP address, as would normally be the case), but instead an IP address range (192.168.2.0/24). The reason that it is an address range is that the local ISP DHCP server might assign any one of the IP addresses in this range to the spoke gateway (it corresponds to the DHCP server[s]' scope).

Now take a look at the command in line 2 (set security-association level per-host). This command ensures that IPsec SAs are negotiated on a per-host basis.

In the absence of the set security-association level per-host, the spoke gateway would negotiate IPsec SAs with the hub site gateway using source IP address 192.168.2.0/24 and destination IP address 192.168.1.1 as its traffic selectors (traffic selectors specify what traffic should be protected by IPsec). But in reality, the spoke gateway only needs to negotiate IPsec SAs with a single source IP address in the range 192.168.2.0/24 (whatever single IP address that the DHCP server assigns to the spoke gateway). So, the set security-association level per-host command ensures that IPsec SAs are negotiated with the hub site gateway using whatever single IP address the DHCP assigns (for example, 192.168.2.5) and 192.168.1.1 as the traffic selectors.

The tunnel source FastEthernet 1/0 command in line 3 is used to specify the outside interface name as the tunnel source rather than a fixed IP address. It is important to specify the interface name rather than a fixed IP address because it is uncertain which IP address the DHCP server will assign to the spoke gateway (again, it could any single IP address in a range).

In line 4, you can see the ip address dhcp [client-id interface-name][hostname hostname] command. This configures the spoke gateway to request an IP address for its outside interface from a DHCP server. The client-id and hostname parameters are used to specify nondefault values for DHCP options 61 and 12, respectively. DHCP options 61 and 12 are carried in DHCPDISCOVER messages sent by the spoke gateway to the DHCP server and by default carry the MAC address of the interface to which the ip address dhcp command is applied and the router host name, respectively. Check with your ISP to determine whether you need to specify nondefault values for DHCP options 61 and 12.

Okay, that is the configuration for a spoke gateway configured with a point-to-point GRE tunnel. But, how about the configuration for a spoke gateway with an mGRE tunnel?

Example 7-12 shows the configuration for a spoke gateway with an mGRE tunnel.

Example 7-12. Configuration of an mGRE Tunnel Interface on a Spoke Site Gateway When Using DHCP for Address Assignment

!
interface Tunnel0
 ip address 10.3.3.3 255.255.255.0
 ip nhrp authentication mjlnet
 ip nhrp map 10.3.3.1 192.168.1.1
 ip nhrp map multicast 192.168.1.1
 ip nhrp network-id 1234
 ip nhrp nhs 10.3.3.1
 tunnel source FastEthernet1/0 (line 1)
 tunnel mode gre multipoint
 tunnel key 5678
 tunnel protection ipsec profile mjlnetprofile
!
!
! Outside interface
!
interface FastEthernet 1/0
 ip address dhcp (line 2)
!

If you compare Example 7-12 to Example 7-10, you will notice only two differencesthe outside interface name is specified using the tunnel source command (see highlighted line 1), and the ip address dhcp command is configured on the outside interface (see highlighted line 2).

Because an IPsec profile is used when configuring an mGRE tunnel interface, and the crypto access list is automatically derived by the gateway, you do not need to worry about configuring a crypto map or a crypto access list when using an mGRE tunnel interfaces on spoke gateways.

Scaling IPsec VPNs with Digital Signature Authentication

As discussed in Chapter 6, three options exist for IKE authentication on Cisco routers:

• Preshared key authentication
• Encrypted nonce authentication
• Digital signature authentication

All three options work fine for small-scale IPsec VPNs. In fact, preshared key authentication, because of the relative ease with which it can be configured, is probably the most popular option for smaller VPNs. As VPNs begin to grow, however, IKE authentication using both preshared keys and encrypted nonces becomes less and less viable.

One problem with preshared key authentication as VPNs grow is key management.

It is a good idea to use a unique preshared key between each pair of IPsec gateways because if you use the same (wildcard) preshared key between all gateways, the compromise of a single IPsec gateway compromises the whole VPN. On the other hand, if a unique preshared key is used between each pair of IPsec gateways, the compromise of a single preshared key only compromises a single pair of routers. If a unique preshared key is compromised, it is a relatively simple task to modify that key on the two affected IPsec gateways. If you use the same preshared key on all IPsec gateways and the preshared key is compromised, it is a much more laborious task to modify the key on all the IPsec gateways. And during the period that you are modifying the preshared key, the entire VPN will be down.

So, to ensure the security of your VPN, you need to use a unique preshared key for each pair of IPsec gateways. The problem with using unique preshared keys, however, is that the number of keys grows dramatically as the number of IPsec gateways in the VPN grows.

If you require full-mesh connectivity in your VPN, you need n(n 1)/2 keys (where n is the total number of IPsec gateways). If you have 5 IPsec gateways, for example, you need 10 preshared keys. If you have 10 IPsec gateways, you need 45 preshared keys. And if you have 100 IPsec gateways, you need 4950 preshared keys.

Figure 7-8 illustrates the number of preshared keys required in a full-mesh topology with five sites.

Figure 7-8. Number of Preshared Keys Required in a Full-Mesh Topology

There are five IPsec gateways (sites) in the network shown in Figure 7-8. The number of IPsec tunnels and preshared keys (PSK) is, therefore, 5(5 1)/2 = 10.

If you choose a hub-and-spoke topology (with one hub gateway), you need s preshared keys, where s is the number of spoke gateways. So, for 5 spoke gateways, you need 5 preshared keys; for 10 spoke gateways, you need 10 preshared keys; and for 100 spoke gateways, you need 100 preshared keys.

Figure 7-9 shows the total number of preshared keys in a hub-and-spoke topology.

Figure 7-9. Number of Preshared Keys Required in a Hub-and-Spoke Topology

If you have redundant hub site gateways at a single site, the number of preshared keys is h * s, where h is the number of hub site gateways, and s is the total number of spoke site gateways. So, with 2 hub site gateways and 5 spoke gateways, you need 2 * 5 = 10 preshared keys. With 2 hub site gateways and 100 spoke gateways, you need 2 * 100 = 200 preshared keys.

Administrating a large number of preshared keys can be laborious and time-consuming. And, when you need to add a new gateway to the VPN, it might not be as simple as you might imagine. If your VPN is fully meshed, not only will you need to configure the new gateway with a preshared key for each of the existing gateways, you will also need to revisit each existing gateway and configure a new preshared key for the new gateway. If you are using a hub-and-spoke topology, things are easieryou only need to add a preshared key or keys for the hub gateway or gateways on the new device as well as a preshared key for the new device on the hub gateway or gateways.

Figure 7-10 illustrates the addition a new gateway to a fully meshed IPsec VPN with preshared key authentication.

Figure 7-10. Addition of New Gateway to Fully Meshed IPsec VPN with Preshared Key Authentication

In Figure 7-10, a new site (Paris) is added to an existing IPsec VPN. This addition requires the configuration of five preshared keys on the new gateway, as well as the configuration of one new preshared key on each of the existing IPsec VPN gateways.

So, preshared key authentication can quickly become a burden as a VPN grows, and that means it does not scale for large VPNs.

Preshared key authentication might not scale well, but how about encrypted nonce authentication? As previously discussed in the section "IKE Encrypted Nonce Authentication" in Chapter 6, when configuring encrypted nonce authentication, you need to manually configure each IPsec gateway with the public key (or keys) of every other IPsec gateway. So, although you do not have the problem of a huge number of keys in a full mesh (as you would with unique preshared keys), you still need to configure each IPsec gateway with the public keys of each other gateway.

The number of public keys that you need to configure on each gateway in a full-mesh topology is equal to n 1 (assuming you are using general-usage keys), where n is the total number of IPsec gateways. In a hub-and-spoke topology, you need to configure the hub site gateway with n 1 public keys and the spoke gateways with the public key of the hub gateway (or gateways).

Figure 7-11 shows the number of public keys required in a fully meshed IPsec VPN with encrypted nonce authentication.

Figure 7-11. Fully Meshed IPsec VPN with Encrypted Nonce Authentication

When you are using encrypted nonce authentication and you add a new gateway to a full-mesh VPN, you need to configure the new gateway with the public keys of all the other gateways in the network, and revisit all the existing gateways in the VPN to add the public key of new gateway. If you add a spoke gateway in a hub-and-spoke VPN, you need to configure the gateway with the public key of the hub site gateway or gateways. Furthermore, if you are using separate keys for signing and encryption, you need to configure twice as many public keys on each gateway in the VPN.

Figure 7-12 illustrates the addition of a new IPsec gateway to a fully meshed VPN with encrypted nonce authentication. This figure shows the addition of a new IPsec gateway (Paris) to a fully meshed IPsec VPN. In this example, gateway Paris must be configured with the public keys of all the existing IPsec gateways in the VPN. Additionally, the existing IPsec gateway must be configured with the public key of the Paris gateway.

Figure 7-12. Addition of New Gateway to Fully Meshed IPsec VPN with Encrypted Nonce Authentication

The manual configuration of public keys on gateways is a time-consuming process, and encrypted nonce authentication is therefore not a practical option for large-scale IPsec VPNs.

So, if preshared key and encrypted nonce authentication are not scalable, how about digital signature authentication? When using digital signature authentication, each IPsec peer enrolls with a (trusted) certificate authority (CA), obtains a certificate, and then during IKE negotiation, certificates are automatically exchanged. These certificates are used by IPsec VPN gateways to authenticate each other.

Figure 7-13 illustrates a fully meshed IPsec VPN with digital signature authentication.

Figure 7-13. Fully Meshed IPsec VPN with Digital Signature Authentication

In Figure 7-13, the London, Copenhagen, Hamburg, Berlin, and Milan gateways each enroll with the CA and obtain a certificate.

When a new gateway is added to the VPN with digital signature authentication, it simply has to enroll with the CA and obtain a certificate before it can establish IPsec tunnels with other gateways in the VPN. Great! There is no need to manually configure gateways with the keys of other gateways. Digital signature authentication (using digital certificates) is therefore much more scalable than both preshared key or encrypted nonce authentication.

Figure 7-14 illustrates the addition of a new gateway to a fully meshed VPN with digital signature authentication.

Figure 7-14. Addition of New Gateway to Fully Meshed IPsec VPN with Digital Signature Authentication

The Paris gateway is added to the IPsec VPN in Figure 7-14. Before the Paris gateway can establish IPsec tunnel with existing gateways in the VPN, it just has to enroll with the CA and obtain a certificate.

You might be asking yourself, "If digital signature authentication is so much more scalable than either preshared key or encrypted nonce authentication, why not use it in all IPsec VPNs deployments, both large and small?" The answer to this question is that digital signature authentication requires a Public Key Infrastructure (PKI), and the deployment of a PKI can be complex.

Background to PKI Deployment

Before considering the deployment of a PKI, it is essential to examine (in more detail) some of the background for a PKI, including the following:

• X.509 certificates
• Certificate revocation
• PKI components
• PKI trust models commonly deployed with IPsec VPNs

These elements are discussed in the sections that follow.

X.509 Certificates

A digital certificate is a certificate in electronic form that binds an end-entity identity with a public key. The end entity in question could, for example, be an IPsec VPN gateway.

There are several types of (digital) certificates, including Pretty Good Privacy (PGP) certificates, Simple Public Key Infrastructure (SPKI) certificates, and X.509 certificates. These certificate standards can be described as follows:

• PGP A way of encrypting and signing e-mail messages or files for secure transmission.
• SPKI A set of standards for a simple and easy-to-use public key infrastructure. SPKI certificates are primarily used for authorization rather than authentication. SPKI has not, however, gained wide acceptance within the industry.
• X.509 Originally defined as part of the X.500 specifications. X.500 defines a global, distributed directory structure containing the names of entities such as computers, printers, and people. In a PKI, an X.500 directory stores certificates and Certificate Revocation Lists (CRL).

There are three versions of the X.509 certificate. Versions 1 and 2 X.509 certificates lacked flexibility because they did not allow additional attributes to be included. Version 3 certificates, on the other hand, include the capability to include additional attributes in the form of extensions. X.509v3 certificates are used in conjunction with IPsec.

Figure 7-15 illustrates the format of the X.509 version 3 certificate.

Figure 7-15. X.509 Version 3 Certificate

The fields of the X.509v3 certificate can be defined as follows:

• Version The version of X.509 certificate, here 3.
• Serial Number A positive integer that identifies this certificate. The serial number is unique for each certificate issued by a particular CA.
• Signature The algorithm (hash and signature algorithm) used to calculate the digital signature that is appended to the certificate. A common combination is the SHA-1 hashing algorithm and the RSA encryption algorithm (remember that a signature is an encrypted hash).
• Issuer A unique Distinguished Name (DN) that identifies the issuer of the certificate (a CA). A DN is a hierarchical name composed of a number of attributes such as e-mail address (E or EA), country (C), state or province name (ST), locality (L), organization (O), organizational unit (OU), and common name (CN).

  Figure 7-16 shows some example DNs.

  Figure 7-16. Example DNs

  

  The DNs for the three entities shown in Figure 7-16 are C=GB, O=MJL Network Solutions, OU=Engineering, CN=Birmingham.mjlnet.com; C=GB, O=MJL Network Solutions, OU=Engineering, CN=London.mjlnet.com; and C=GB, O=MJL Network Solutions, OU=Engineering, CN=Manchester.mjlnet.com, respectively.

• Validity The period during which the certificate can be considered valid, unless the certificate has been revoked. The Validity field includes a sequence of two dates and timesthe date/time when the certificate's validity begins, and the date/time when certificate's validity ends. These times are represented as universal time coordinated (UTC) time (Zulu or Greenwich mean time), or generalized time (a standard ASN.1 type for variable-precision representation of time).

  RFC3280 specifies that UTC time must be used for validity periods up to the year 2049, and generalized time for validity periods from the year 2050.

• Subject This field contains the DN of the entity associated with the public key carried in this certificate (the certificate owner). The subject name may also be carried in the subjectAltName extension.
• Subject Public Key Info This field carries the public key and identifies the algorithm used with key (including the modulus [bit length]). Examples of algorithms include RSA and DSA.
• Issuer Unique Identifier This optional field is carried only in Versions 2 and 3 certificates and ensures that the issuer can still be uniquely identified even if an issuer name in the Issuer field is reused.
• Subject Unique Identifier This optional field is also carried only in Versions 2 and 3 certificates, and ensures that the subject can still be uniquely identified even if a name in the Subject field is reused.
• Extensions Extensions are optional, and can only be included when using Version 3 certificates. There are a large number possible extensions, including the following:

  - Key Usage Defines restrictions to the usage of the key included in the certificate. Possible usages include encipherment (encryption) and digital signature (signing). If a key can be used for either encipherment or digital signatures, the show crypto ca certificates command shows the Key Usage field as General Purpose.
   

  - Subject Key Identifier Uniquely identifies a certificate that contains a particular public key. This extension is useful when a certificate owner possesses several keys.
   

  - Authority Key Identifier Identifies a public key corresponding to a particular private key. This identifier is used when an issuer has multiple signing keys.
   

  - CRL Distribution Point(s) Identifies how CRL information can be obtained (where an IPsec VPN gateway can get a CRL).
   

  - Authority Information Access Indicates how to obtain CA information and services such as online validation services. If you are using the Online Certificate Status Protocol (OCSP) for certificate revocation status checks in your IPsec VPN, the OCSP Responder (server) is specified in this field.
   

  - Subject Alternative Name Alternative names that are bound to the subject of the certificate. Examples of alternative names include DNS name, IP address, and e-mail address.
   

• Digital Signature Algorithm ID and encrypted hash (signature) of the certificate data.

  End-entity certificates are signed by the certificate issuing CA (the CA encrypts a hash of the certificate using its private key). The root CA signs its own certificate.

  Algorithms used to calculate the hash of certificates include SHA-1.

Okay, that is the theory. Figures 7-17 and 7-18 show a certificate issued to an IPsec VPN gateway (as seen on the certificate issuing CA).

Figure 7-17. Certificate Issued to a Gateway (First Half)

Figure 7-18. Certificate Issued to a Gateway (Second Half)

Figure 7-17 shows the first half of the certificate issued to a gateway called London.mjlnet.com (as shown in the Subject field). The certificate fields shown are Version, Serial Number, Signature (algorithm), Issuer, Validity (shown as its two constituent parts, Valid from, and Valid to), Subject, and (Subject) Public Key (Info).

Figure 7-18 shows the remaining fields of the certificate issued to London.mjlnet.com. Fields (extensions) shown are Key Usage, Subject Key Identifier, Authority Key Identifier, CRL Distribution Points, Authority Information Access, and Subject Alternative Name. The hash algorithm and hash (Thumbprint algorithm and Thumbprint, respectively) are also shown.

As you can see in Figures 7-17 and 7-18, the optional Issuer Unique ID and Subject Unique ID fields (see Figure 7-15) are not included in this certificate.

You can also view certain fields in the certificate on a Cisco IOS gateway using the show crypto ca certificates commands, as demonstrated in Example 7-13. Note that much more information on verifying and troubleshooting certificates, digital signature authentication, and IPsec VPNs in general can be found in Troubleshooting Virtual Private Networks (Cisco Press).

Example 7-13. End-Entity Certificate as Seen on a Cisco IOS Gateway Using the show crypto ca certificates Command

London#show crypto ca certificates
Certificate
 Status: Available (line 1)
 Certificate Serial Number: 617EF31300000000000E (line 2)
 Key Usage: General Purpose (line 3)
 Issuer: (line 4)
 CN = mjlnet.ca1
 OU = Engineering
 O = MJL Network Solutions
 L = London
 ST = none
 C = UK
 EA =<16> [e-mail]
 Subject Name Contains: (line 5)
 Name: London.mjlnet.com
 CRL Distribution Point: (line 6)
 http://mjl-certsrv-acs/CertEnroll/mjlnet.ca1.crl
 Validity Date: (line 7)
 start date: 16:11:33 UTC May 16 2004
 end date: 16:21:33 UTC May 16 2005
 Associated Identity: mjlnetca

Highlighted line 1 shows that the certificate status is Available. This is not a field in the certificate but instead indicates that the certificate has been issued by the CA and is ready to use.

Certificate fields shown in Example 7-13 are Serial Number (line 2, Certificate Serial Number), Key Usage (line 3, a certificate extension), Issuer (line 4), Subject Name (line 5, Subject Name Contains), CRL Distribution Point (line 6, a certificate extension), and Validity (line 7, Validity Date).

Certificate Revocation

Although certificates are valid for the period specified in their Validity field, it is possible for them to be revoked before their validity period ends.

Certificates can be revoked for a number of reasons, including the following:

• The private key corresponding to the public key contained within the certificate has been compromised. This might occur if an unauthorized person gained access to an entity.
• The CA that issued the certificate has been compromised.
• The affiliation of the entity has changed. If the entity were a network device, this would, for example, happen when a division of company that owned the network device was sold to another company.

When certificates are revoked, this information must be communicated to end entities so that communications are not compromised. In the case of an IPsec VPN, a gateway performing RSA digital signature authentication (during IKE negotiation) checks whether the certificate of its peer has been revoked. If the peer's certificate has been revoked, and the gateway is able to access this information, IKE authentication fails.

Because certificates are revoked on the CA, there must be some mechanisms that allow end entities to access certificate revocation information. Two popular mechanisms that allow end entities to access this information are as follows:

• CRLs Signed lists of revoked certificates.
• OCSP End entities verify the status of a certificate on-the-fly by querying a device known as an OCSP Responder.

The two sections that follow discuss CRLs and OSCP.

CRLs

CAs can periodically make CRLs available to end entities. In an IPsec VPN, IPsec peers either download these CRLs and cache them, or download them as needed during IKE negotiation. It is also possible for a CA to delegate the issuance of CRLs to a trusted authority. In this case, the CRL is called an indirect CRL.

A complete CRL is a list of all revoked certificates within a particular scope. The scope of a CRL usually conforms to all those certificates issued by a particular CA but may include certificates issued by multiple CAs. Delta CRLs may also be issued. These list only those certificates whose status has changed since the issuance of the last complete CRL.

To ensure that certificate revocation information contained within a CRL is fresh, one important consideration is the frequency that CRLs are published. If the CRL is published once a week, for example, it is possible for IPsec devices with revoked certificates to establish IPsec tunnels with other devices for up to one week after their certificates have been revoked. In sensitive environments, it is important to ensure that CRLs are published at sufficiently short intervals such that the risk of devices with revoked certificates establishing IPsec tunnels is reduced as much as possible.

There are two CRL versions. Version 1 CRLs have a number of drawbacks, including a lack of flexibility. Version 2 CRLs address the drawbacks of version 1 CRLs. Figure 7-19 illustrates the format of a version 2 CRL.

Figure 7-19. Version 2 CRL Format

The fields of the version 2 CRL are as follows:

• Version Describes the version of the CRL (2).
• Signature Algorithm ID for algorithm used to digitally sign the certificate.
• Issuer Name DN of the entity that signed and issued this CRL. As previously mentioned, this entity is usually a CA.
• This Update The issue date of this CRL. This is represented as either UTC time or generalized time.
• Next Update The date before which the next CRL will be issued.
• Revoked Certificates This field is present only if one or more certificates have been revoked. If one or more certificates have been revoked, each revoked certificate's serial number is listed here, along with the date/time when the certificate was revoked.

  In version 2 CRLs, optional extensions containing additional information may be included for each entry in the list of revoked certificates.

  CRL entry extensions include the following:

  - (CRL) Reason Code The reason that the certificate was revoked. Possible reasons include key compromise, CA compromise, a change of affiliation of the entity, the certificate having been superseded, and a temporary certificate hold (suspension).
   

  - Invalidity Date The date on which it is known or suspected that a certificate or (private) key associated with the certificate became invalid or was compromised. This may be earlier than the date that the certificate was actually revoked.
   

• Extensions Extensions to the CRL as a whole rather than a particular entry in the CRL. These extensions allow additional information to be included with the CRL. Possible extensions include the following:

  - Authority Key Identifier Allows the end entity to identify the correct public key associated with the private key that a CRL issuer used to sign the CRL. This is important when there are multiple public keys corresponding to a CRL issuer (when it has multiple public/private key pairs).
   

  - Issuer Alternative Name Alternative names for the issuer of the CRL. Types of alternative name include e-mail address, IP address, and DNS name.
   

  - CRL Number An increasing sequence number that allows end entities to easily determine when one CRL supersedes another.
   

Figure 7-20 shows a version 2 CRL (on the publishing CA).

Figure 7-20. Version 2 CRL

In Figure 7-20, you can see the Version, Issuer, This Update (Effective Date), Next Update, Signature (algorithm), and two extensions to the CRL (Authority Key Identifier and CA Version). Note that CA Version is a Microsoft-specific extension that specifies how many times the CA has been renewed and how many signing keys the CA possesses.

Figure 7-21 shows the individual CRL entries in the Revoked Certificates List field of the CRL.

Figure 7-21. Individual CRL Entries

Figure 7-21 shows three revoked certificates in the Revoked Certificates List field of the CRL.

The upper pane in Figure 7-21 shows the serial numbers and revocation dates of the revoked certificates. The lower pane shows the CRL Reason Code CRL entry extension for the certificate with serial number 6140 9128 0000 0000 0008, and this indicates that the reason for revocation was Key Compromise.

You can also view some of the fields contained in the CRL using the show crypto ca crls command on Cisco IOS routers, as demonstrated in Example 7-14.

Example 7-14. show crypto ca crls Command Output

London#show crypto ca crls
CRL Issuer Name: (line 1)
 CN = mjlnet.ca1, OU = Engineering, O = MJL Network Solutions, L = London, ST
 = none, C = UK, EA =<16> [e-mail]
 LastUpdate: 14:04:22 UTC May 17 2004 (line 2)
 NextUpdate: 16:48:22 UTC May 18 2004 (line 3)
 Retrieved from CRL Distribution Point: (line 4)
 http://mjl-certsrv-acs/CertEnroll/mjlnet.ca1.crl
London#

Highlighted line 1 shows the Issuer (CRL Issuer Name) field of the CRL. Lines 2 and 3 then show the Last Update and Next Update fields of the CRL. Finally, line 4 shows the CRL Distribution Point (CDP) from which the CRL was obtained.

Online Certificate Status Protocol (OCSP)

As previously mentioned, end entities can verify the status of a certificate by querying an OCSP Responder.

The OCSP Responder can be either the CA that issued the certificate in question or another authorized Responder designated by the CA. If you are use an authorized Responder, this device must hold a special certificate issued by the CA that indicates that this device is authorized to issue OCSP responses on behalf of the CA.

To find out the status of a certificate, an OCSP client (an end entity such as an IPsec VPN gateway) sends an OCSP Request message to the OCSP Responder. The Responder replies with an OCSP Response message. The Request message indicates the certificate for which revocation status is required, and the Response message indicates one of three statuses:

• Good The certificate has not been revoked.
• Revoked The certificate has been revoked (either permanently or temporarily [the certificate status is "on hold"]). If the private key for a particular CA has been compromised, the OCSP Responder may also indicate a revoked status for all certificates issued by that CA.
• Unknown The OCSP Responder does not know about the certificate.

Figure 7-22 illustrates OCSP functionality. In this figure, the London and New York IPsec VPN gateways are negotiating IKE phase 1. During IKE phase 1, London and New York exchange certificates. At this point, they both request the revocation status of the other's certificate by sending an OCSP Request message to the OCSP Responder. The OCSP Responder informs London of the status of New York's certificate, and New York of the status of London's certificate using OCSP Response messages. Assuming that each IPsec VPN gateway receives an OCSP Response message indicating that the status of its peer's certificate is Good, IKE negotiation can continue, and an IPsec tunnel can be established between the two peers.

Figure 7-22. OCSP Functionality

OCSP has a number of important advantages over CRLs, including the following:

• The evaluation of certificate validity is centralized on the OCSP Responder. When you are using CRLs, each IPsec peer must download a CRL or CRLs and locally evaluate the status of certificates received from IPsec peers.
• Certificate revocation status obtained using OCSP is fresh (assuming that the OCSP Responder has access to current certificate revocation information). The information contained in CRLs, on the other hand, can often be stale. The extent to which the information contained in a CRL is stale depends on the frequency that the CA publishes the CRL.
• The amount of network bandwidth required to verify a certificate's status using OCSP is insignificant. CRLs can grow to be large, and the amount of network bandwidth that is required to allow an end entity to download a CRL can become significant.

OCSP is particularly useful in environments, such as those involving financial transactions, where the freshest possible certificate revocation information in required.

PKI Components

IKE digital signature authentication requires the deployment of a PKI. But what does a PKI consist of exactly? As the name suggests, a PKI consists of all the infrastructure elements or components necessary to enable public key security services in a network and allow automated identification, authentication, access control, and authorization. In an IPsec VPN, the PKI allows devices such as gateways (called end entities in PKI terminology) to authenticate each other, and help to ensure the integrity and confidentiality of data as it transits the network.

The PKI components include the following:

• End entities
• CA
• Registration authority (RA)
• Certificate repository
• CRL issuer

Note

It is possible for a single system to fulfill the responsibilities of more than one of the PKI components listed above (with the exception of end entities).

Figure 7-23 illustrates the relationship of the various PKI components to each other.

Figure 7-23. Relationship of PKI Components to Each Other

The sections the follow discuss the PKI components in greater detail.

End Entity

An end entity is a user or subject of a certificate. So, in an IPsec VPN, IPsec VPN gateways are all end entities (assuming they are using IKE digital signature authentication).

Certificate Authority (CA)

A CA is responsible for certifying an association of an entity identity (name) with a public key. This association is carried in a digital certificate, and a CA certifies this association by digitally signing the certificate. What a CA is doing by signing a certificate is saying, "I certify that this public key corresponds to (is owned by) this identity (entity)."

The important thing to remember about CAs and digital certificates is that the end entities in a PKI trust a CA, and because a CA certifies the association of entity identity and public key in certificates, entities also trust these certificates. So, if an IPsec VPN gateway trusts a certain CA, it also trusts certificates issued (and signed) by that CA.

Digital certificates are analogous to passports. Because immigration personnel around the world trust the passport agency that has issued your passport, they also (after they are satisfied that it is genuine) trust the identity given in your passport (name and so on).

Figure 7-24 illustrates an end entity (IPsec VPN gateway) enrolling with a CA and obtaining a certificate using SCEP.

Figure 7-24. An End Entity Enrolls with a CA Using SCEP

Note

SCEP relies on Public Key Cryptography Standards (PKCS) #7 and #10. PKCS#7 provides a general syntax for data that may have cryptography applied to it, and PKCS#10 provides a syntax for certification requests.

In Figure 7-24, the Hamburg gateway sends a SCEP certificate enrollment request message to the CA. Note that the Hamburg gateway has already obtained the CA's certificate at this point (via HTTP Get and Response messages).

In this example, the CA is configured to manually authenticate the end entity, and so the CA responds to the certificate enrollment request from Hamburg with a PENDING response message. This PENDING response message indicates that the certificate enrollment request is awaiting authentication by the CA administrator.

The Hamburg gateway periodically polls the CA using GetCertInitial messages, and the CA replies to these polling messages by sending PENDING response messages.

The CA administrator then manually authenticates the certificate enrollment request from Hamburg (which could be done by calling the Hamburg gateway administrator, for example), and when the Hamburg gateway next polls the CA, the CA now replies with a SUCCESS message. This SUCCESS message contains the Hamburg gateway's certificate signed by the CA.

It is worth noting that the CA can also be configured to automatically approve certificate requests, in which case the SCEP certificate enrollment request message sent by the Hamburg gateway in Figure 7-24 would simply be followed by a SUCCESS message sent by the CA. Also, if the certificate enrollment request is rejected, the CA can send a FAILURE message (rather than a SUCCESS message).

Other important responsibilities of the CA include reissuing certificates when they expire and revoking certificates that have become invalid.

Registration Authority (RA)

An RA is an optional component of a PKI to which some of the functions of the CA can be delegated. Functions that may be delegated to the RA include the following:

• Initial verification of the identity information supplied by the end entity
• Authentication of the end entity via a challenge password
• Verifying that the end entity is in possession of the private key corresponding to the public key submitted (Proof of Possession [POP])
• Initiation of end-entity certification with the CA

It is important to note that an RA is never responsible for the issuance of certificates or CRLs. Also, a human may perform some of the RA's functions such as verification of the end entity's identification, especially in a high-security environment.

Certificate Repository

A certificate repository is an online system (or systems) that is responsible for storing certificates and CRLs. End entities can then obtain certificates and CRLs from this repository.

Certificate repositories often consist of a distributed database accessed via protocols such as the Lightweight Directory Access Protocol (LDAP) or SCEP.

The location of the certificate repository can be indicated via certificate extensions such as the CRL Distribution Point (CDP).

CRL Issuer

A CRL issuer is an optional system to which the CA delegates the publishing of CRLs.

PKI Trust Models Commonly Deployed with IPsec VPNs

A PKI is a trust infrastructure. An end entity trusts a CA and therefore also trusts certificates signed by that CA (as long as those certificates have not been revoked). Figure 7-25 illustrates this simple trust model.

Figure 7-25. Simple PKI Trust Model

In Figure 7-25, the Berlin and Hamburg gateways enroll with CA1, and each obtain a signed certificate. Berlin and Hamburg then want to set up an IPsec tunnel, and so negotiate IKE. During IKE negotiation, Berlin and Hamburg exchange certificates, and because each trusts CA1, they also trust each other's certificates (because they are signed by CA1).

So far so good, but what happens if peer IPsec gateways are enrolled with different CAs? Figure 7-26 illustrates this situation.

Figure 7-26. Peer IPsec VPN Gateways Are Enrolled with Different CAs

In Figure 7-26, Berlin enrolls with CA1 and obtains a certificate signed by CA1. Leipzig enrolls with CA2 and obtains a certificate signed by CA2.

Berlin and Leipzig then commence IKE negotiation, and exchange certificates. Unfortunately, Berlin rejects Leipzig's certificate because it is signed by CA2 and Berlin has no trust relationship with CA2. Similarly, Leipzig rejects Berlin's certificate because it has no trust relationship with CA1.

Hmm? How can this situation be resolved? One way would be for Berlin to enroll with CA2 and obtain a certificate signed by CA2. Alternatively, Leipzig could enroll with CA1 and obtain a certificate signed by CA1. In Cisco IOS Software Release 12.2(2)T and later, it is possible for a gateway to support multiple certificates.

So, in Figure 7-26, you could, for example, enroll Berlin with CA2 in addition to CA1. Berlin could then establish IPsec tunnels with other gateways enrolled with CA1 or other gateways enrolled with CA2 (including Leipzig). In certain situations, such as extranet topologies, support for multiple certificates is useful, but there is a simpler solution to the situation shown in Figure 7-26.

If you reexamine Figure 7-26, you will notice that the problem is one of trustBerlin does not trust CA2 and Leipzig does not trust CA1. One way of getting round this problem, however, is to get CA1 and CA2 to trust each other. In this case, Berlin would trust Leipzig's certificate because the CA that it is enrolled with (CA1) would trust CA2. Also, Leipzig would trust Berlin's certificate because the CA it is enrolled with (CA2) would trust CA1.

To get CA1 and CA2 to trust each other you can cross-certify the two CAs. Figure 7-27 illustrates this trust relationship.

Figure 7-27. Cross-Certification of CAs

In Figure 7-27, CA1 and CA2 enroll with each other and are therefore cross-certified. Because the CAs are cross-certified, the end entities enrolled with each of the CAs then trust the certificates of end entities enrolled with the other CA. So, in Figure 7-27, Berlin would trust Leipzig's certificate and vice-versa.

Figure 7-28 illustrates cross-certified CAs deployed in an IPsec VPN.

Figure 7-28. Cross-Certified CAs Deployed in an IPsec VPN

In Figure 7-28, CA1 and CA2 enroll with each other and obtain signed certificates (they are cross-certified).

Berlin then enrolls with CA1 and obtains a certificate signed by CA1. Similarly, Leipzig enrolls with CA2 and obtains a certificate signed by CA2. Berlin and Leipzig exchange certificates during IKE negotiation. Berlin trusts CA1, and also trusts Leipzig's certificate because it is signed by CA2, which in turn is trusted by CA1. Also, Leipzig trusts CA2, and also trusts Berlin's certificate because it is signed by CA1, which in turn is trusted by CA2. IKE negotiation succeeds.

So, cross-certification would also work, in theory. Note that it is possible for cross-certification to be used within a single organization or department, but more often than not it is used between CAs in different organizations or departments. Because cross-certification involves a trust relationship being established right across organizations, or departments, this model should only be deployed after careful consideration of its implications.

Another way to enable Berlin and Leipzig to trust each other's certificates is to create a subordinated CA hierarchy (also called a strict CA hierarchy). In a cross-certification model, CAs enroll with each other, and neither CA is subordinate to the other. In a subordinated hierarchy, however, there is a single root CA, and other CAs in the hierarchy are subordinate to that root CA.

Figure 7-29 illustrates a subordinated CA hierarchy.

Figure 7-29. Subordinated CA Hierarchy

At the top of the subordinated CA hierarchy is the root CA. This is the ultimate source of trust in the hierarchy, and as such it is sometimes known as the trust root or trust anchor. Below the root CA are zero or more levels of subordinate (or intermediate) CAs. The subordinate CAs directly below the root CA are enrolled with the root CA, and the CAs below that level are enrolled with the CAs directly below the root CA. Finally, at the bottom level of the hierarchy, there are the end entities. The end entities are enrolled with the CAs directly above them in the CA hierarchy.

Figure 7-30 illustrates a subordinated CA hierarchy deployed with an IPsec VPN.

Figure 7-30. Subordinated CA Hierarchy Deployed in an IPsec VPN

In Figure 7-30, CA2 and CA3 enroll with and obtain certificates from root CA, CA1. CA2 and CA3 are now in a position to issue certificates to end entities (or even other CAs in the next level of the CA hierarchy). In this case, there are no CAs below CA2 and CA3 in the CA hierarchy, and so CA2 and CA3 issue certificates to end entities.

Berlin and Leipzig now enroll with and obtain certificates from CA3 and CA2, respectively. After they have obtained their certificates, Berlin and Leipzig begin IKE negotiation and exchange certificates. Berlin trusts Leipzig's certificate because it was issued by CA2, a CA whose certificate was issued in turn by CA1. Berlin trusts CA1 because Berlin's certificate was issued by CA3, whose certificate was issued in turn by CA1. So, in other words, Berlin trusts Leipzig's certificate because there is an extended trust relationship between CA3 and CA2 via CA1. Leipzig trusts Berlin's certificate because there is again an extended trust relationship between CA2 and CA3 via CA1.

In simple terms, Berlin says to Leipzig, "I trust you (and your certificate) because your certificate was issued by CA2 and CA2 is trusted by CA1 (CA1 issued CA2's certificate).

My own certificate was issued by CA3, which in turn trusts CA1. So, if CA1 trusts CA2 (which issued your [Leipzig's] certificate), and CA3 trusts CA1, your (Leipzig's) certificate is good enough for me." Leipzig (if it could speak!) would say something similar to Berlin.

Although there are only two levels of hierarchy in CA hierarchy shown in Figure 7-30, it is (theoretically) possible to have as many levels in the hierarchy as you like. So, CA2 and CA3 could issue certificates to other subordinate CAs, and they in turn could either issue certificates to other CAs or end entities.

In a subordinated CA hierarchy, one advantage is that you can take the root CA off lineeither physically disconnect it from the network, or power it down, or both. The root CA is only responsible for issuing certificates to directly subordinated CAs (that is, CAs in the next level of hierarchy), not to end entities. So, in Figure 7-30, the root CA will issue certificates only to CA2 and CA3 (and CA4). It is possible for the root CA to issue certificates to end entities, but that breaks the strict hierarchy, so it is not a good idea.

After the root CA has issued certificates to directly subordinate CAs, you can take it off line until it needs to issue another certificate to another directly subordinate CA. Being able to take the root CA off line is important because of the nature of the trust relationships in a subordinated CA hierarchyin a subordinated hierarchy, all trust relationships rely on the root CA. If the root CA's private (signing) key is compromised, and all certificates issued by the root CA and subordinate CA become invalid. This is because a hacker/cracker in possession of the private key can issue fake certificates that are indistinguishable from genuine certificates issued by the root CA (they are signed with the genuine but compromised root CA's private key). So, a hacker/cracker could easily issue him- or herself with a certificate and build an IPsec tunnel with any of the gateways in the IPsec VPN.

A compromise of the root CA's private key is the most disastrous scenario, but a compromise of the private key of any of the subordinate CAs would compromise the certificates of any subordinate CAs and end entities below that CA (only). If you refer back to Figure 7-29, the compromise of CA2's private key, for example, would compromise the certificates of CA4, CA5, and all the end entities enrolled with CA4 and CA5. The certificates of CA1, CA3, CA6, CA7, and all end entities enrolled with CA6 and CA7 would, however, not be affected if the private key of CA2 were compromised.

Because of the risk of compromise of the private keys of CAs, CA private keys are often protected using a Hardware Security Module (HSM). An HSM is separate device that provides physical isolation and tamper protection for the CA's private key(s).

Before finishing this section, it is worth emphasizing that the PKI trust model is completely independent of the network topology. So, it is possible to deploy a subordinated CA hierarchy in a full-mesh (nonhierarchical) IPsec VPN.

Deploying the PKI for an IPsec VPN: Considerations

Now that you understand the background to a PKI, it is time to take a brief look at some of the considerations that you must make before deploying a PKI for your IPsec VPN. Considerations include the following:

• Whether the present or predicted future size of your IPsec VPN would justify the use of IKE digital signature authentication and the associated deployment of a PKI.

  When considering whether to use IKE digital signature authentication, and deploying a PKI, one consideration is the size of your present IPsec VPN as well as the potential size of your future IPsec VPN. If the VPN consists of or will in the future consist of more than a few gateways, preshared key and encrypted nonce IKE authentication might not be viable (for administrative reasons).

• Whether security considerations would justify the use of IKE digital signature authentication and the associated deployment of a PKI.

  As you already know, preshared key IKE authentication is not as secure as digital signature authentication, especially when using weak preshared keys. Security considerations may dictate that you use digital signature authentication and deploy an associated PKI.

• The choice of hardware and software to support your PKI.

  Cisco gateways support a wide range of CAs, but the choice of software and hardware for your PKI (hardware/software for RA/CAs) can be bewildering.

• Whether the setup and administration of your PKI should be insourced or outsourced.

  If the IT staff do not have the time or the expertise to deploy and support a PKI, you might consider outsourcing this. However, the outsourcing of a PKI requires that your organization be satisfied with an associated (partial) loss of control and security of your VPN.

• What PKI trust model you should deploy.

  There a number of PKI trust models, but which one should you deploy? The subordinated hierarchical model described in the previous section is the most commonly deployed and works well in support of an IPsec VPN.

• Whether the PKI used to support IKE digital signature authentication for your IPsec VPN should be dedicated for this purpose only or should be part of the overall organization's PKI (encompassing e-mail security and so on).

  Although the PKI used to support an IPsec VPN can be part of a larger overall PKI, many organizations choose to deploy a separate dedicated PKI for the VPN. By choosing to deploy a separate, dedicated PKI, you can simplify administration and help to ensure security of the VPN.

Simplifying PKI Deployment with the IOS Certificate Server

The deployment of a PKI can be complex. One way to simplify its deployment is to configure a Cisco IOS Software certificate server.

The Cisco IOS certificate server was introduced in Cisco IOS Software Release 12.3(4)T and has a number of advantages, including the following:

• It provides a basic PKI in support of IKE digital signature authentication in an IPsec VPN.
• It simplifies the choice of hardware and software for a PKI.

  The Cisco IOS certificate server is an integrated component of Cisco IOS Software Release 12.3(4)T and later. Support for this feature on a particular router platform can be verified using the Cisco IOS Feature Navigator (login required):

  http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp

• It eases the requirement to retrain IT staff or outsource deployment and administration of a PKI

  Assuming that IT staff are already familiar with the Cisco IOS command-line interface, it is a simple task to train them to deploy and administer a Cisco IOS certificate server.

• It provides support for a subordinated CA hierarchy

  The initial release of the Cisco IOS certificate server in Cisco IOS Software Release 12.3(4)T supported only one level of CA hierarchy (see Figure 7-29). Support for additional levels of hierarchy was added in Cisco IOS Software Release 12.3(14)T.

• It provides a dedicated PKI for the IPsec VPN.

You must consider a number of tasks when deploying a Cisco IOS certificate server, including the following:

• Determining the Cisco IOS certificate server deployment model
• Configuring the Cisco IOS certificate server
• Administrating the Cisco IOS certificate server

The following three sections examine these tasks in detail.

Determining the Cisco IOS Certificate Server Deployment Model

Before you can deploy a Cisco IOS certificate server, you must decide whether you want to configure it as an integrated element of an IPsec VPN gateway or to deploy it as a separate device.

In the case of a small VPN (with a small number of certificates, and therefore a small CRL), it is possible to deploy the Cisco IOS certificate server as an integrated element of an IPsec VPN gateway.

When deployed in a small hub-and-spoke IPsec VPN, the Cisco IOS certificate server is typically deployed as an integrated element of a hub site gateway. If the VPN is full mesh, the Cisco IOS certificate server can potentially be deployed as an integrated element of any of the IPsec VPN gateways.

The choice of which Cisco IOS router to use as the certificate server depends largely on the (free) CPU and memory capacity of the routers in the VPN. You should always ensure that the Cisco IOS certificate server is deployed on a router with plenty of spare memory and CPU capacity (the router is relatively lightly loaded) and that this router is easily accessible from all of the gateways in the IPsec VPN. You should also take into account additional bandwidth requirements at the site where the certificate server is deployed, particularly if there are a large number of IPsec VPN gateways and the CRL grows to a large size.

Assuming that files (including the CRL) are stored locally, the router configured as the Cisco IOS certificate server will not only need to be available to issue certificates to new gateways and to renew existing gateways' certificates, but also to provide the CRL to gateways when they negotiate IKE and need to verify the revocation status of peer gateways' certificates.

Figure 7-31 illustrates the deployment of an integrated Cisco IOS certificate server in a small-scale IPsec VPN.

Figure 7-31. Deploying a Cisco IOS Certificate Server as an Integrated Element of an IPsec VPN Router

As illustrated in Figure 7-31, an integrated Cisco IOS certificate server needs to be able to enroll new gateways, re-enroll existing gateways, and make a CRL available to gateways negotiating IKE and verifying the revocation status of peer gateways' certificates.

The alternative to deploying a Cisco IOS certificate server as an integrated element of an IPsec VPN gateway is to deploy a Cisco IOS certificate server as a separate dedicated device, as illustrated in Figure 7-32.

Figure 7-32. Deploying a Cisco IOS Certificate Server as a Separate Device in an IPsec VPN

In Figure 7-32, a separate device is deployed as a Cisco IOS certificate server. Deployment of a separate device ensures that the hub site IPsec VPN gateway is not too heavily loaded.

Configuring a Cisco IOS Certificate Server

Basic configuration of a Cisco IOS certificate server consists of the following seven steps:

Step 1.	Set the time on the router.
Step 2.	Generate and export the Cisco IOS certificate server key pair (recommended).
Step 3.	Configure the HTTP server (recommended).
Step 4.	Configure the Cisco IOS certificate server's database parameters.
Step 5.	Configure certificate attributes.
Step 6.	Specify the CRL lifetime.
Step 7.	Enable the Cisco IOS certificate server.

The following seven sections describe the configuration of a Cisco IOS certificate server.

Step 1: Set the Time on the Router

The first step in the configuration of the Cisco IOS certificate server is to set the time. You can either set the clock using the clock set command or you can configure the Network Time Protocol (NTP).

The clock set command should only be used if your router has a hardware clock, because otherwise the time will be lost whenever the router is reloaded. Configuration of NTP is discussed in detail in the section "Setting the Time on IPsec VPN Gateways Using NTP" in Chapter 6. Note that you cannot enable a Cisco IOS certificate server if you have not first set the time on the router.

Finally, it is a good idea to set the time zone using the clock timezone and clock summer-time commands.

Step 2: Generate and Export the Cisco IOS Certificate Server Key Pair (Recommended)

After you have set the time, the next step is to generate and export the Cisco IOS certificate server's public/private key pair, as demonstrated in Example 7-15.

Example 7-15. Generating the Cisco IOS Certificate Server's Key Pair

London(config)#crypto key generate rsa general-keys label mjlnetca modulus 2048
 exportable
The name for the keys will be: mjlnetca
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys ...[OK]
London(config)#exit
London#

In the highlighted line, the crypto key generate rsa general-keys label key-label modulus modulus exportable command is used to generate a public/private keys pair for the Cisco IOS certificate server with a modulus of 2048 bits.

The key-label parameter is used to specify a label for the key pair, and the exportable keyword ensures that the exportable flag is set and that the key pair can be backed up. In the event that the Cisco IOS certificate server fails catastrophically, the backed-up key pair can be used to re-create the certificate server on another Cisco IOS router.

Recommended best practice dictates that you should specify a modulus of at least 1024 bits for the certificate server's key pair. Remember the certificate server's private key is used to sign the certificates that it issues to end entities (gateways), and the key modulus dictates the security of that signature.

You can then verify the RSA key pair using the show crypto key mypubkey rsa command, as shown in Example 7-16.

Example 7-16. Verifying the RSA Key Pair

London#show crypto key mypubkey rsa
% Key pair was generated at: 19:22:28 UTC May 22 2004
Key name: mjlnetca
 Usage: General Purpose Key
 Key is exportable.
 Key Data:
 30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101
 00C7E22A AB04B6BB 5A6AEF00 89DBC028 FD1F92DF 63376ABB 09D7B1A7 8EAED052
 1E990469 2AECF141 62DCD3D7 2C7C51E3 EE3D5196 1317B3EC F990C7DF 8A5430E7
 EF96171B B5DA9C09 65802EA9 A4703266 10CF52A6 141EC102 070976B3 1BC745E6
 B0390D84 4BD6EA88 E74011FE 3FB5B6FF A4AD3DE7 7F381646 CEBE37EB C1D201DC
 4DB0E7F3 86604680 ECB2AB14 4FB217CB 6A91906B FC2DCD08 0745C3EE 8E38A3BB
 C012C706 862E4C8C 0769D607 3B3E79C9 8FB47F17 F0BBDFDD 9844F1E2 CA63C9D2
 DAC83351 48101112 EA002934 49679B7E E29C7B48 B4EE84CC B6E6C19A 6624A4B8
 F5091652 0FA1E84C AF84CDF8 87F55DEB 82638A09 96758ED8 547FBA5D BE35E4A1
 BD020301 0001
% Key pair was generated at: 19:22:30 UTC May 22 2004

As you can see in the highlighted line, the key pair is marked as exportable, allowing it to be backed up.

After the key pair has been generated, you can back it up to a variety of locations, including a Flash memory card, an FTP server, and a TFTP server, using the crypto key export rsa key-label pem url url {3des | des} passphrase command. This command backs up the keys pair in a Privacy Enhanced Mail (PEM) format, to a specified location (URL), encrypted using the specified algorithm (either DES or 3DES) with the specified passphrase. Note that PEM (base64) format is just an ASCII form of the original binary certificate.

Note that it is not mandatory to manually generate a public/private key pair (as shown in Example 7-15), but if you do not, when you enable the Cisco IOS certificate server (Step 3) the router will automatically generate a 1024-bit key pair that is not exportable.

Example 7-17 demonstrates exporting the key pair to a Flash disk.

Example 7-17. Exporting the RSA Key

Router(config)#crypto key export rsa mjlnetca pem url disk0: 3des mjlnetvpn (line 1)
% Key name: mjlnetca
Usage: General Purpose Key
Exporting public key...
Destination filename [mjlnetca.pub]? (line 2)
Writing file to disk0:mjlnetca.pub
Exporting private key...
Destination filename [mjlnetca.prv]? (line 3)
Writing file to disk0:mjlnetca.prv

Highlighted line 1 in Example 7-17 shows that the RSA key pair is encrypted using 3DES with the passphrase mjlnetvpn, and exported to Flash disk 0. The key label identifies the key pair to export (in this example, mjlnetca), which must be the same as that specified when generating the key pair using the crypto key generate rsa general-keys label key-label modulus modulus exportable command.

Highlighted lines 2 and 3 show the destination filenames of the public and private keys, respectively. For the reasons previously described, you should ensure that the certificate server's private key is stored securely.

Step 3: Configure the HTTP Server (Recommended)

Now that the key, pair has been backed up, you can move on to configuring the HTTP server, as shown in Example 7-18.

Example 7-18. Configuring the HTTP Server

London#conf t
London(config)#ip http server
London(config)#exit
London#

The ip http server command in the highlighted line is used to enable the HTTP server on the router.

The ip http server command is essential if you want to allow certificate enrollment requests from end-entity routers to be transmitted to the certificate server using SCEP (which operates over HTTP). If you do not configure the HTTP server on the certificate server, end entities can only enroll with the certificate server manually using PKCS#10.

Step 4: Configure the Cisco IOS Certificate Server's Database Parameters

The next step is to configure certificate server database parameters, as demonstrated in Example 7-19. The certificate server database stores information related to certificates issued by the certificate server.

Example 7-19. Configuring the Cisco IOS Certificate Server's Database Parameters

London#conf t
London(config)#crypto pki server mjlnetca (line 1)
London(cs-server)#database url tftp://10.10.10.9 (line 2)
London(cs-server)#database level complete (line 3)
London(cs-server)#database username mjlnet password cisco (line 4)

The crypto pki server cs-label command in line 1 is used to enter certificate server configuration mode. The cs-label must exactly match the key-label specified in the crypto key generate rsa general-keys label key-label modulus modulus exportable (shown in Example 7-15).

In line 2, the database url root-url command is used to specify the location to which certificate server database entries (including certificates issued to end entities) will be written. In this example, certificate server database entries will be written to a TFTP server at IP address 10.10.10.9.

Caution

Make sure that if you do specify an external server as the location for database files that this server is reachable from the Cisco IOS certificate server. If the external server is unreachable, you will be unable to enable the Cisco IOS certificate server (see Step 7).

The certificate database can be located on any file system support by the router (for example, FTP, TFTP, and Flash), but you should ensure that the file system specified can support (potentially) a large number of read and write operations and has sufficient storage for a large number of certificates (assuming a large number of IPsec routers in the VPN).

If you choose to locate the database on an external server, seriously consider configuring an IPsec tunnel between the Cisco IOS certificate server and the external server to protect communications with that external server.

Although storing certificate server database files on an external server is attractive, carefully consider all the advantages and disadvantages of doing this.

Advantages of storing database files on an external server include the fact that there is generally a greater amount storage space available and the fact that files can be backed up periodically using the server's regular backup processes.

Disadvantages of storing database files on an external server include the fact that if the server is unavailable (off line) and the revocation-check crl none or crl optional commands are not configured on IPsec VPN gateways, IKE phase 1 negotiation may fail between these peers (and IPsec tunnel will not be established). Note, however, that if the server is unavailable and the revocation-check crl none or crl optional commands are configured on IPsec VPN routers, IPsec VPN routers with revoked certificates may be able to negotiate IKE phase 1 and establish IPsec tunnels with other IPsec VPN routers. For more information on the revocation-check command, see the section "Step 4: Declare the Certificate Authority (CA)" in Chapter 6.

The next command (shown in line 3) is database level {minimal | names | complete}. This command dictates the form of information written to the certificate server database.

If the minimal level is specified using the database level minimal command, a minimum amount information is written to the database. This minimum amount of information consists of a file named cs-label.ser, which holds the serial number of the previously issued certificate.

If the names level is specified using the database level names command, the subject names in human-readable and distinguished encoding rules (DER) form (a way of encoding certificate fields) as well as serial numbers of certificates are written to the database in files named cs-label.cnm. Subject names and serial numbers are necessary for administrators to locate a specific certificate in the database and revoke it, if required. Certificate expiration dates and certificate states (valid or revoked) can also be written to the cs-label.cnm file.

Finally, if the complete level is specified using the database level complete command, complete certificates are written to the database. In this case, each certificate is stored in binary form in an individual file named certificate-serial-number.cer. Depending on the number of certificates issued, the complete level can potentially cause a large number of files to be written to the database storage location.

The complete level should be specified only if the database location is an external database (such as an FTP or TFTP sever), it is anticipated that only a small number of certificates will be issued (that there will only be a small number of IPsec routers in the VPN), or the local router file system has a great deal of spare file system memory capacity and the file system can support a large number of write operations.

In line 4, the database {username username | password password} command is used to specify a username and password to access the certificate database. This protects against an attacker who attempts to modify the .ser and .crl files in the database. If these files are illegally modified or deleted, the Cisco IOS certificate server may stop issuing certificates.

The username and password specified using the database {username username | password password} command are no substitute, however, for good server security and an IPsec tunnel to protect communications between the Cisco IOS certificate server and an external database server. Note that the username and password specified in highlighted line 4 are not secure and are used for illustrative purposes only!

Step 5: Configure Certificate Attributes

After the certificate server database has been configured, you can begin to configure certain attributes of the certificates that the Cisco IOS certificate server will issue.

Example 7-20 shows configuration of certificate attributes. Note that certificate attributes are specified in certificate server configuration mode.

Example 7-20. Configuring Certificate Attributes

London(cs-server)#issuer-name C=GB, O=MJL Network Solutions, OU=Engineering,
 CN=mjlnetca.mjlnet.com (line 1)
London(cs-server)#lifetime ca-certificate 1825 (line 2)
London(cs-server)#lifetime certificate 365 (line 3)
London(cs-server)#cdp-url http://mjlnetcrlrepos.com/mjlnetca.crl (line 4)

The DN of the issuer (the Cisco IOS certificate server itself) is specified in line 1 using the issuer-name DN-string command. The issuer DN is included in the issuer field of the X.509 certificates issued by the certificate server. For more information on DNs, see the section, "X.509 Certificates" earlier in this chapter.

The lifetime of the certificate server's X.509 certificate is then specified using the lifetime ca-certificate days command. The default lifetime of the certificate server's certificate is 1095 days (3 years) and can be from 1 to 1825 days (5 years). The lifetime specified using this command is used to derive the Validity field of the certificate server's own X.509 certificate.

Note that the certificate server's certificate will be self-signed if the Cisco IOS certificate server is a root CA.

The next step is to specify the lifetime of X.509 certificates issued by the certificate server to gateways (or other CAs) using the lifetime certificate days command (line 3). The lifetime specified using this command is used to derive the Validity field of certificates issued by the certificate server.

Finally, the location of the CRL distribution point (CDP) is specified using the cdp-url url command. Because of the additional overhead that would otherwise be required on the Cisco IOS certificate server, if you are deploying a large-scale IPsec VPN you should specify an external server using this command. If you do not specify a CDP using this command, the X.509 certificate CDP extension will not be included in certificates issued to end entities, but (assuming that the HTTP server is configured) Cisco IOS IPsec gateways will be able to obtain the CRL via SCEP from the Cisco IOS certificate server. The CRL, whether stored locally on the Cisco IOS certificate server or on an external server, has the file name cs-label.crl.

Other information contained in other fields in the X.509 certificates issued to end entities (or CAs) is specified by the end entities (or CAs) themselves during certificate enrollment.

For more information on X.509 certificate fields, see the section "The X.509 Certificates" earlier in this chapter.

Step 6: Specify the CRL Lifetime

Next, you should specify the lifetime of the CRL issued by the Cisco IOS certificate server using the lifetime crl hours command, as shown in Example 7-21. Again, this command is specified in certificate server configuration mode.

Example 7-21. Configuring the CRL Lifetime

London(cs-server)#lifetime crl 72

In Example 7-21, a CRL lifetime of 72 hours (3 days) is specified, and so the Cisco IOS certificate server will publish a new CRL every 72 hours. The default CRL lifetime is 168 hours (1 week), and the maximum lifetime that can be specified is 336 hours (2 weeks).

As previously mentioned, the CRL publishing interval (CRL lifetime) is a key consideration when configuring your certificate server. It is possible for an IPsec VPN gateway with a revoked certificate to build IPsec tunnels to other IPsec VPN gateways during the period between the revocation of its certificate and the time at which the next CRL is published.

Step 7: Enable the Cisco IOS Certificate Server

The configuration of the Cisco IOS certificate server is now complete, and it can be enabled using the no shutdown command in certificate server configuration mode, as shown in Example 7-22.

Example 7-22. Enabling the Cisco IOS Certificate Server

London(cs-server)#no shutdown
% Once you start the server, you can no longer change some of
% the configuration.
Are you sure you want to do this? [yes/no]: y
!!!!!!!!
Loading mjlnetca.ser from 10.10.10.9 (via FastEthernet3/0): !
[OK - 32 bytes]
Loading mjlnetca.crl from 10.10.10.9 (via FastEthernet3/0): !
[OK - 416 bytes]
% Certificate Server enabled.
London(cs-server)#end
London#

In Example 7-22, the Cisco IOS certificate server is enabled using the no shutdown certificate server configuration mode command.

After the Cisco IOS certificate server has been enabled, you can verify its configuration and status using the show crypto pki server command, as shown in Example 7-23.

Example 7-23. Using the show crypto pki server Command to Verify Cisco IOS Certificate Server Configuration and Status

London#show crypto pki server
Certificate Server mjlnetca:
 Status: enabled, configured (line 1)
 Issuer name: C=GB, O=MJL Network Solutions, OU=Engineering, CN=mjlnetca (line 2)
 CA cert fingerprint: 40B54845 6984A34E 8CCD75FF 1A6BAE95 (line 3)
 Granting mode is: manual (line 4)
 Last certificate issued serial number: 0x1 (line 5)
 CA certificate expiration timer: 19:24:02 UTC Jul 30 2009 (line 6)
 CRL NextUpdate timer: 19:24:04 UTC Aug 3 2004 (line 7)
 Current storage dir: tftp://10.10.10.9 (line 8)
 Database Level: Complete - all issued certs written as .cer (line 9)
London#

In highlighted line 1, you can see that the Cisco IOS certificate server has been enabled. Line 2 shows the issuer DN for certificates issued by this Cisco IOS certificate server. Then in line 3, you can see the fingerprint of the Cisco IOS certificate server's certificate.

The certificate issuing mode is shown in line 4 (in this case, manual). The serial number of the last certificate issued is shown in line 5. In line 6, you can see the date and time at which the Cisco IOS certificate server's own certificate will expire.

Line 7 shows the date and time when the next CRL will be published. The location of the Cisco IOS certificate server's database is shown in line 8. Finally, in line 9, you can see the database level configured on the Cisco IOS certificate server (complete, in this example).

Note

The default enrollment URL for a Cisco IOS certificate server is http://IOS-certificate-server-name-or-IP-address:80. The default enrollment mode is CA (the enrollment mode ra command is not required on gateways enrolling with the Cisco IOS certificate server, by default).

The enrollment URL if you enroll from a Cisco VPN 3000 or a Cisco VPN client is http://IOS-Certificate-server-name-or-IP-address/cgi-bin/pkiclient.exe

 

Approving, Rejecting, Revoking, and Manually Requesting Certificates

The main responsibility of the certificate server administrator is approving, rejecting, revoking, and manually requesting certificates. These responsibilities are detailed in this section.

Approving and Rejecting Certificate Requests

End entities request certificates from the certificate server during enrollment. The certificate server administrator must either approve or reject those certificate requests.

An administrator can either manually grant SCEP certificate requests or use a preshared to pre-authorize certificate requests.

You can use the crypto pki server cs-label grant {all | transaction-id} command to manually grant (issue) certificates requested using SCEP. The cs-label that you specify must match that used when configuring the certificate server (see Example 7-19). If you specify the all keyword with this command, all pending certificate requests will be granted (issued); and if you specify a particular transaction-id, only the certificate request associated with the particular transaction ID will be granted.

Before you grant a certificate, you can verify its transaction ID using the crypto pki server cs-label info requests command.

Example 7-24 shows the granting of a certificate using the crypto pki server cs-label grant {all | transaction-id}.

Example 7-24. Manually Granting a Certificate Using the crypto pki server Command

London#crypto pki server mjlnetca info requests (line 1)
Enrollment Request Database:
RA certificate requests:
ReqID State Fingerprint SubjectName
--------------------------------------------------------------
Router certificates requests:
ReqID State Fingerprint SubjectName
--------------------------------------------------------------
1 pending 235A10BFCB166B85A96D5CA2E817A5D5
 hostname=Berlin.mjlnet.com (line 2)
London#
London#crypto pki server mjlnetca grant 1 (line 3)
!!!!!!
London#

In Example 7-24, the crypto pki server cs-label info requests command is used to verify the transaction ID of a certificate request (see highlighted line 1).

In line 2, you can see that one certificate request from Berlin.mjlnet.com is pending, and it has transaction ID (ReqID) 1.

The crypto pki server cs-label grant {all | transaction-id} command is then used in line 3 to grant the certificate.

It is also possible to automatically grant all certificate requests by specifying the grant auto command in certificate configuration mode, as demonstrated in Example 7-25.

Example 7-25. Enabling the Cisco IOS Certificate Server

London(config)#crypto pki server mjlnetca
London(cs-server)#grant auto
% This will cause all certificate requests to be automatically granted.
Are you sure you want to do this? [yes/no]: y
London(cs-server)#

Be careful when considering the use of the grant auto command to ensure that it conforms to your organization's security policy. Remember that if you do choose to use it, any and all certificates requests will be grantedwhich could lead to a serious security issue if an attacker is able to request a certificate from the certificate server.

If you want to reject a particular certificate request or all pending certificate requests, you can use the crypto pki server cs-label reject {all | transaction-id} command. Again, the cs-label parameter must match that specified when configuring the certificate server. The all keyword or transaction-id parameter can be used to specify that all pending certificate requests are rejected or that only the certificate request associated with a particular certificate request (transaction-id) is rejected.

Note

If certificate requests are not granted within an hour, they will expire.

The other method of granting certificate requests is to pre-authorize them using a preshared key (challenge password). In this case, you can use the crypto pki server cs-label password generate [minutes] command to generate a challenge password that when specified by the end entity during certificate enrollment will ensure that the request is automatically granted by the certificate server. This password is a one-time password (it cannot be used repeatedly) and will ensure only that a certificate is automatically granted if it is used within the time period specified (in minutes). If you use the crypto pki server cs-label password generate [minutes] command to generate another password before the previous password is used, the previous password becomes invalid and can no longer be used.

Example 7-26 shows the configuration of the crypto pki server cs-label password generate [minutes] command.

Example 7-26. Configuration of the crypto pki server Command

London#crypto pki server mjlnetca password generate 60
% New password is 98C5D08456937BA1, valid for 60 minutes
London#

The crypto pki server cs-label password generate [minutes] command is used in Example 7-26 to generate a password (98C5D08456937BA1) that is valid for 60 minutes.

Revoking Certificates

If for some reason (such as the compromise of an IPsec VPN gateway) a certificate needs to be revoked, you can use the crypto pki server cs-label revoke certificate-serial-number command to accomplish this, as shown in Example 7-27. Note that the cs-label must again match that specified when configuring the Cisco IOS certificate server, and the certificate serial number must be specified in hexadecimal.

Example 7-27. Using the crypto pki server Command to Revoke a Certificate

London#crypto pki server mjlnetca revoke 0x03
!!
London#

In Example 7-27, the certificate with serial number 0x03 is revoked.

You can also verify the Cisco IOS certificate server's CRL using the crypto pki server cs-label info crl command (see Example 7-28). The CRL is only published at the interval specified using the lifetime crl command (see Example 7-21), and so revoked certificates will not immediately be included on the CRL unless their revocation happens to coincide with the certificate server publishing the CRL.

Example 7-28. Using the crypto pki server Command to Verify the Cisco IOS Certificate Server's CRL

London#crypto pki server mjlnetca info crl
Certificate Revocation List:
 Issuer: c=GB,o=MJL Network Solutions,ou=Engineering,cn=mjlnetca
 This Update: 20:35:36 UTC Jul 31 2004
 Next Update: 20:35:36 UTC Aug 3 2004
 Number of CRL entries: 1 (line 1)
 CRL size: 438 bytes
Revoked Certificates:
 Serial Number: 0x03 (line 2)
 Revocation Date: 20:35:36 UTC Jul 31 2004 (line 3)
London#

Highlighted line 1 shows that there is 1 entry in the CRL, and lines 2 and 3 shows the serial number and revocation date/time of the revoked certificate.

Manually Requesting Certificates

It is possible to manually request certificates for end entities via the Cisco IOS certificate server command line. This is useful if an IPsec VPN gateway is unable to request a certificate using SCEP.

To manually request a certificate via base64-encoded (base64 encodes files into ASCII text format) or a PEM-formatted PKCS#10 certificate request, you can use the crypto pki server cs-label request pkcs10 {url url | terminal} command. Once again, the cs-label should be the same as that specified when configuring the certificate server. You can specify a file system such as FTP, TFTP, or Flash (using the url parameter) from which to import the certificate request, or you can simply specify that it should be imported via the console using cut and paste with the terminal keyword.