|
|
This chapter describes how to configure your router for network data encryption using Cisco Encryption Technology (CET). This chapter includes the following sections:
For a complete description of the encryption commands in this chapter, refer to the "Cisco Encryption Technology Commands" chapter in the Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
Data that traverses unsecured networks is open to many types of attacks. Data can be read, altered, or forged by anybody who has access to the route that your data takes. For example, a protocol analyzer can read packets and gain classified information. Or, a hostile party can tamper with packets and cause damage by hindering, reducing, or preventing network communications within your organization.
Encryption provides a means to safeguard network data that travels from one Cisco router to another across unsecured networks. Encryption is particularly important if classified, confidential, or critical data is being sent.
Figure 12 illustrates the encryption of an IP packet as it travels across an unsecured network.
The following sections answer these questions:
Network data encryption is provided at the IP packet level---only IP packets can be encrypted. (If you wish to encrypt a network protocol other than IP, you must encapsulate the protocol within an IP packet.)
An IP packet is encrypted/decrypted only if the packet meets criteria you establish when you configure a router for encryption.
When encrypted, individual IP packets can be detected during transmission, but the IP packet contents (payload) cannot be read. Specifically, the IP header and upper-layer protocol headers (for example, TCP or UDP) are not encrypted, but all payload data within the TCP or UDP packet will be encrypted, and therefore not readable during transmission.
The actual encryption and decryption of IP packets occur only at routers that you configure for CET. Such routers are considered to be peer encrypting routers (or simply peer routers). Intermediate hops do not participate in encryption/decryption.
Often, peer routers are situated at the edges of unsecured networks (such as the Internet), in order to provide secure communications between two secured networks that are physically separated. Cleartext (not encrypted) traffic that enters a peer router from the secure network side is encrypted and forwarded across the unsecure network. When the encrypted traffic reaches the remote peer router, the router decrypts the traffic before forwarding it into the remote secure network.
Packets are encrypted at one peer router's outbound interface and decrypted at the other peer router's inbound interface.
Encrypted packets can be exchanged between peer routers only during encrypted sessions. When a peer router detects a packet that should be encrypted, an encrypted session must first be established. After an encrypted session is established, encrypted traffic can pass freely between peer routers. When the session expires, a new session must be established before encrypted traffic can continue to be sent.
During the setup of every encrypted session, both participating peer routers attempt to authenticate each other. If either authentication fails, the encrypted session will not be established, and no encrypted traffic will pass. Peer authentication ensures that only known, trusted peer routers exchange encrypted traffic, and prevents routers from being tricked into sending sensitive encrypted traffic to illegitimate or fraudulent destination routers.
To provide encryption services, Cisco implements the following standards: Digital Signature Standard (DSS), the Diffie-Hellman (DH) public key algorithm, and Data Encryption Standard (DES). DSS is used for peer router authentication. The DH algorithm and DES standard are used to initiate and conduct encrypted communication sessions between participating peer routers.
The following sections provide an overview of Cisco's encryption process:
Peer router authentication occurs during the setup of each encrypted session. But before peer routers can authenticate each other, you must generate Digital Signature Standard (DSS) keys (both public and private DSS keys) for each peer, and you must exchange (and verify) the DSS public keys with each peer (see Figure 13). You generate and exchange DSS keys only once per peer, and afterwards these DSS keys will be used each time an encrypted session occurs. (Generating and exchanging DSS keys are described later in the section "Configure Encryption.")
Each peer router's DSS keys are unique: a unique DSS public key, and a unique DSS private key. DSS private keys are stored in a private portion of the router's NVRAM, which cannot be viewed with commands such as more system:running-config or more nvram:startup-config. If you have a router with an Encryption Service Adapter (ESA), DSS keys are stored in the tamper resistant memory of the ESA.
The DSS private key is not shared with any other device. However, the DSS public key is distributed to all other peer routers. You must cooperate with the peer router's administrator to exchange public keys between the two peer routers, and you and the other administrator must verbally verify to each other the public key of the other router. (The verbal verification is sometimes referred to as "voice authentication.")
When an encrypted session is being established, each router uses the peer's DSS public key to authenticate the peer. The process of authenticating peers and establishing encrypted sessions is described next.
An encrypted session must be established before a Cisco router can send encrypted data to a peer router. (See Figure 14.) An encrypted session is established whenever a router detects an IP packet that should be encrypted and no encrypted session already exists.
To establish a session, two peer routers exchange connection messages. These messages have two purposes. The first purpose is to authenticate each router to the other. Authentication is accomplished by attaching "signatures" to the connection messages: A signature is a character string that is created by each local router using its own DSS private key, and verified by the remote router using the local router's DSS public key (previously exchanged). A signature is always unique to the sending router and cannot be forged by any other device. When a signature is verified, the router that sent the signature is authenticated.
The second purpose of the connection messages is to generate a temporary DES key ("session key"), which is the key that will be used to actually encrypt data during the encrypted session. To generate the DES key, Diffie-Hellman (DH) numbers must be exchanged in the connection messages. Then, the DH numbers are used to compute a common DES session key that is shared by both routers.
After both peer routers are authenticated and the session key (DES key) has been generated, data can be encrypted and transmitted. A DES encryption algorithm is used with the DES key to encrypt and decrypt IP packets during the encrypted session. (See Figure 15.)
An encrypted communication session will terminate when the session times out. When the session terminates, both the DH numbers and the DES key are discarded. When another encrypted session is required, new DH numbers and DES keys will be generated.
The following reading material can provide additional background information about network data encryption, including theory, standards, and legal requirements.
Applied Cryptography, Bruce Schneier.
Network Security: Private Communication in a Public World, Kaufman, Perlman, and Specinen.
Actually Useful Internet Security Techniques, Larry J. Hughes, Jr.
FIPS140, Federal Information Processing Standard
Defense Trade Regulations (Parts 120 to 126)
Information Security and Privacy in Network Environments, Office of Technology Assessment
You should understand and follow the guidelines in this section before attempting to configure your system for CET. This section describes the following guidelines:
You must identify all peer routers that will be participating in encryption. Peer routers are routers configured for encryption, between which all encrypted traffic is passed. These peers are usually routers within your administrative control that will be passing IP packets over an uncontrolled network (such as the Internet). Participating peer routers might also include routers not within your administrative control; however, this should only be the case if you share a trusted, cooperative relationship with the other router's administrator. This person should be known and trusted by both you and your organization.
Peer routers should be located within a network topology per the guidelines listed next.
Take care in choosing a network topology between peer encrypting routers. Particularly, you should set up the network so that a stream of IP packets must use exactly one pair of encrypting routers at a time. Do not nest levels of encrypting routers. (That is, do not put encrypting routers in between two peer encrypting routers.)
Frequent route changes between pairs of peer encrypting routers, including for purposes of load balancing, will cause excessive numbers of connections to be set up and very few data packets to be delivered. Note that load balancing can still be used, but only if done transparently to the encrypting peer routers. That is, peer routers should not participate in the load balancing: only devices in between the peer routers should provide load balancing.
A common network topology used for encryption is a hub-and-spoke arrangement between an enterprise router and branch routers. Also, Internet firewall routers are often designated as peer encrypting routers.
Encryption is provided by a software service called a crypto engine. To perform encryption at a router, you must first configure the router's crypto engine to be an encrypting peer; then you can configure any interface governed by that crypto engine to perform encryption. (To configure a crypto engine, you must at a minimum generate and exchange DSS keys for that engine, as described later in the section "Configure Encryption.")
Depending on your hardware configuration, different crypto engines will govern different router interfaces. In some instances, you may even need to configure multiple crypto engines as peers within a single router, particularly if a router has multiple interfaces that you want to use for encryption, and those interfaces are governed by different crypto engines.
There are three types of crypto engines---the Cisco IOS crypto engine, the VIP2 crypto engine, and the ESA crypto engine.
If you have a Cisco 7200, RSP7000, or 7500 series router with one or more VIP2 boards (VIP2-40 or higher) or ESA cards, your router can have multiple crypto engines. All other routers have only one crypto engine, the Cisco IOS crypto engine.
When you configure a crypto engine on a Cisco 7200, RSP7000, or 7500 series router, you must identify which engine you are configuring by specifying the engine's chassis slot number when you enter the crypto commands.
The three different crypto engines are described next.
Every router with Cisco IOS encryption software has a Cisco IOS crypto engine. For many Cisco routers, the Cisco IOS crypto engine is the only crypto engine available. The only exceptions are the Cisco 7200, RSP7000, and 7500 series routers, which can also have additional crypto engines as described in the next two sections.
If a router has no additional crypto engines, the Cisco IOS crypto engine governs all the router interfaces: you must configure the Cisco IOS crypto engine before you can configure any router interface for encryption.
The Cisco IOS crypto engine is identified by the chassis slot number of the Route Switch Processor (RSP). (For routers with no RSP, the Cisco IOS crypto engine is selected by default and does not need to be specifically identified during configuration.)
Cisco RSP7000 and 7500 series routers with a second-generation Versatile Interface Processor (VIP2) (version VIP2-40 or greater) have two crypto engines: the Cisco IOS crypto engine and the VIP2 crypto engine.
The VIP2 crypto engine governs the adjoining VIP2 port interfaces. The Cisco IOS crypto engine governs all remaining router interfaces. (These rules assume there is no ESA installed in the VIP2. If the VIP2 has an installed ESA, the interfaces are governed differently, as explained in the next section.)
The VIP2 crypto engine is identified by the chassis slot number of the VIP2.
Cisco 7200, RSP7000, and 7500 series routers with an Encryption Service Adapter (ESA) have an ESA crypto engine.
When a Cisco 7200 router has an active ESA, the ESA crypto engine---not the Cisco IOS crypto engine---governs all the router interfaces. (With an inactive ESA, the Cisco IOS crypto engine governs all the router interfaces. On the Cisco 7200, you can select which engine is active; only one engine is active at a time.)
The ESA plugs into the Cisco 7200 chassis, and the ESA crypto engine is identified by the ESA's chassis slot number.
The ESA and an adjoining port adapter plug into a VIP2 board. The ESA crypto engine---not the VIP2 crypto engine---governs the adjoining VIP2 port interfaces. The Cisco IOS crypto engine governs all remaining interfaces.
In a Cisco RSP7000 or 7500 series router, the ESA crypto engine is identified by the chassis slot number of the VIP2.
Please note the following issues and limitations of encryption, described in this section:
You can use any type of encapsulation with IP encryption, except as follows: If you have a second-generation Versatile Interface Processor (VIP2) with a serial interface, encryption will not work for traffic on the serial interface unless you use the Point-to-Point Protocol (PPP), High-Level Data Link Control (HDLC) protocol, or Frame Relay protocol. For example, you cannot use encryption if you have X.25 or SMDS configured for the serial interface of a VIP2.
Table 21 shows port adapter support by platform.
| Interface | Encapsulation | 7200 Software | 7200 ESA | 7500/VIP Distribution Software | 7500/VIP ESA |
|---|---|---|---|---|---|
4E, 8E, 5EFL |
| Yes | Yes | Yes | Yes |
FE |
| Yes | Yes | Yes | Yes |
4R |
| Yes | Yes | Yes | Yes |
FDDI |
| Yes | Yes | Yes | Yes |
100VG |
| Yes | Yes | Yes | Yes |
4T | PPP, HDLC, Frame Relay | No | No | Yes | No |
4T+, 8T | PPP | Yes | Yes | Yes | Yes |
HSSI | PPP | Yes | Yes | Yes | Yes |
CT1, CE1 | PPP | Yes | Yes | Yes | Yes |
PRI | HDLC | Yes | Yes | No | No |
BRI | HDLC | Yes | Yes | No | No |
ATM |
| Yes | Yes | Yes | No |
CT3 |
| No | No | Yes | No |
Encrypted multicast is not supported.
IP fragmentation is supported with encryption for all platforms except the VIP2. If you configure encryption for VIP2 interfaces, all IP fragments will be dropped.
If you configure encryption for VIP2 interfaces on a Cisco RSP7000 or 7500 series router, you must use distributed switching (DSW) on the source and destination encrypting/decrypting interfaces.
This restriction means that any protocol that is not compatible with DSW, such as SMDS, cannot be used on VIP2 encrypting interfaces.
Each encrypting router can set up encrypted sessions with many other routers, if these are peer encrypting routers. Encrypting routers can also set up multiple simultaneous encrypted sessions with multiple peer routers. Up to 299 concurrent encrypted sessions per router can be supported.
Because of the high amount of processing required for encryption, if you use encryption heavily there will be performance impacts such as interface congestion or slowed CPU functioning. Using an ESA crypto engine rather than the Cisco IOS crypto engine can improve overall router performance because the Cisco IOS software will not be impacted by encryption processing.
To pass encrypted traffic between two routers, you must configure encryption at both routers. This section describes the tasks required to configure encryption on one router: you must repeat these tasks for each peer encrypting router (routers that will participate in encryption).
To configure encryption on a router, complete the tasks described in the following sections:
For examples of the configuration in this section, see the section "Encryption Configuration Examples" at the end of this chapter.
You must generate DSS keys for each crypto engine you will use. If you will use more than one crypto engine, you must generate DSS keys separately for each engine. (These are the crypto engines you previously identified per the description in the earlier section "Identify Crypto Engines within Each Peer Router.")
The DSS key pair that you generate is used by peer routers to authenticate each other before each encrypted session. The same DSS key pair is used by a crypto engine with all its encrypted sessions (regardless of the peer encrypting router that it connects to).
Generate DSS keys for a crypto engine by using at least the first of the following commands in global configuration mode:
| Command | Purpose |
|---|---|
crypto key generate dss key-name [slot] | Generate DSS public and private keys. |
show crypto key mypubkey dss [slot] | View your DSS public key (private key not viewable). |
copy system:running-config nvram:startup-config | Save DSS keys to private NVRAM. (Complete this task only for Cisco IOS crypto engines.) |
If you are generating keys for an ESA crypto engine, the following occurs during DSS key generation:
Configuring encryption with an ESA is described later in the sections "Configure Encryption with an ESA in a VIP2" and "Configure Encryption with an ESA in a Cisco 7200 Series Router."
You must exchange DSS public keys with all participating peer routers. This allows peer routers to authenticate each other at the start of encrypted communication sessions.
If your network contains several peer encrypting routers, you need to exchange DSS keys multiple times (once for each peer router). If you ever add an encrypting peer router to your network topology, you will then need to exchange DSS keys with the new router to enable encryption to occur with that new router.
You must exchange the DSS public keys of each crypto engine that you will use.
To successfully exchange DSS public keys, you must cooperate with a trusted administrator of the other peer router. You and the administrator of the peer router must complete the following steps in the order given (refer to Figure 16):
Step 1 Call the other administrator on the phone. Remain on the phone with this person until you complete all the steps in this list.
Step 2 You and the other administrator decide which of you will be called "PASSIVE" and which will be called "ACTIVE."
Step 3 PASSIVE enables a DSS exchange connection by using the following command in global configuration mode:
| Command | Purpose |
|---|---|
crypto key exchange dss passive [tcp-port] | Enable a DSS exchange connection. |
Step 4 ACTIVE initiates a DSS exchange connection and sends a DSS public key by using the following command in global configuration mode:
| Command | Purpose |
|---|---|
crypto key exchange dss ip-address key-name [tcp-port] | Initiate connection and send DSS public key. |
The serial number and Fingerprint of ACTIVE's DSS public key will display on both of your screens. The serial number and Fingerprint are numeric values generated from ACTIVE's DSS public key.
Step 5 You both verbally verify that the serial number is the same on both your screens, and that the Fingerprint is the same on both your screens.
Step 6 If the displayed serial numbers and Fingerprints match, PASSIVE should agree to accept ACTIVE's DSS key by typing y at the prompt.
Step 7 PASSIVE sends ACTIVE a DSS public key by pressing <Return> at the screen prompt and selecting a crypto engine at the next prompt.
Step 8 PASSIVE's DSS serial number and Fingerprint display on both of your screens.
Step 9 As before, you both verbally verify that the PASSIVE's DSS serial number and Fingerprint match on your two screens.
Step 10 ACTIVE agrees to accept PASSIVE's DSS public key.
Step 11 The exchange is complete, and you can end the phone call.
The previous steps (illustrated in Figure 16) must be accomplished between your router and a peer router for every peer router with which you will be conducting encrypted sessions.
Cisco routers use Data Encryption Standard (DES) encryption algorithms and DES keys to encrypt and decrypt data. You must globally enable (turn on) all the DES encryption algorithms that your router will use during encrypted sessions. If a DES algorithm is not enabled globally, you will not be able to use it. (Enabling a DES algorithm once allows it to be used by all crypto engines of a router.)
To conduct an encrypted session with a peer router, you must enable at least one DES algorithm that the peer router also has enabled. You must configure the same DES algorithm on both peer routers for encryption to work.
CET supports the following four types of DES encryption algorithms:
The 40-bit variations use a 40-bit DES key, which is easier for attackers to "crack" than basic DES which uses a 56-bit DES key. However, some international applications might require you to use 40-bit DES because of export laws. Also, 8-bit CFB is more commonly used than 64-bit CFB, but requires more CPU time to process. Other conditions might also exist that require you to use one or another type of DES.
If you do not know if your image is exportable or non-exportable, you can use the show crypto cisco algorithms command to determine which DES algorithms are currently enabled.
Globally enable one or more DES algorithms by using one or more of the following commands in global configuration mode:
| Command | Purpose |
|---|---|
crypto cisco algorithm des [cfb-8 | cfb-64] | Enable DES with 8-bit or 64-bit CFB. |
crypto cisco algorithm 40-bit-des [cfb-8 | cfb-64] | Enable 40-bit DES with 8-bit or 64-bit CFB. |
View all enabled DES algorithms. |
The purpose of this task is to tell your router which interfaces should encrypt/decrypt traffic, which IP packets to encrypt or decrypt at those interfaces, and also which DES encryption algorithm to use when encrypting/decrypting the packets.
There are actually three steps required to complete this task:
Step 1 Set Up Encryption Access List (to be used in the crypto map definition)
Step 2 Define Crypto Maps
Step 3 Apply Crypto Maps to Interfaces
Encryption access lists are used in this step to define which IP packets will be encrypted and which IP packets will not be encrypted. Encryption access lists are defined using extended IP access lists. (Normally, IP access lists are used to filter traffic. Encryption access lists are not used to filter traffic but are used to specify which packets to encrypt or not encrypt.)
Set up encryption access lists for IP packet encryption by using either of the following commands in global configuration mode:
| Command | Purpose |
|---|---|
access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [log] or ip access-list extended name | Specify conditions to determine which IP packets will be encrypted. (Enable or disable encryption for traffic that matches these conditions.)1 |
Using the permit keyword will cause the selected traffic that is passed between the specified source and destination addresses to be encrypted/decrypted by peer routers. Using the deny keyword prevents that traffic from being encrypted/decrypted by peer routers.
The encryption access list you define at the local router must have a "mirror-image" encryption access list defined at the remote router, so that traffic that is encrypted locally is decrypted at the remote peer.
See the Security Command Reference for complete details about the extended IP access list commands.
The encryption access list you define will be applied to an interface as an outbound encryption access list after you define a crypto map and apply the crypto map to the interface. (These two tasks are described in the next sections.)
Crypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set. Later, you will apply these crypto map sets to interfaces; then, all IP traffic passing through the interface is evaluated against the applied crypto map set. If a crypto map entry sees outbound IP traffic that should be protected and the crypto map specifies the use of IKE, a security association is negotiated with the remote peer according to the parameters included in the crypto map entry; otherwise, if the crypto map entry specifies the use of manual security associations, a security association should have already been established via configuration. (If a dynamic crypto map entry sees outbound traffic that should be protected and no security association exists, the packet is dropped.)
The policy described in the crypto map entries is used during the negotiation of security associations. If the local router initiates the negotiation, it will use the policy specified in the static crypto map entries to create the offer to be sent to the specified IPSec peer. If the IPSec peer initiates the negotiation, the local router will check the policy from the static crypto map entries, as well as any referenced dynamic crypto map entries to decide whether to accept or reject the peer's request (offer).
If you create more than one crypto map entry for a given interface, use the seq-num of each map entry to rank the map entries: the lower the seq-num, the higher the priority. At the interface that has the crypto map set, traffic is evaluated against higher priority map entries first.
You must define exactly one crypto map for each interface that will send encrypted data to a peer encrypting router. You can apply only one crypto map set to a single interface. Multiple interfaces can share the same crypto map set if you want to apply the same policy to multiple interfaces.
To define a crypto map, use the following commands. The first command is used in global configuration mode; the other commands are used in crypto map configuration mode.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| crypto map map-name seq-num [cisco] | Name the crypto map. (Executing this command causes you to enter the crypto map configuration mode.) | ||
| set peer key-name | Specify the remote peer router. | ||
| match address [access-list-number | name] | Specify at least one encryption access list. | ||
| set algorithm des [cfb-8 | cfb-64] or set algorithm 40-bit-des [cfb-8 | cfb-64] | Specify at least one DES encryption algorithm. (This must be an algorithm you previously enabled.) |
To define an additional, different set of parameters for the same interface, repeat the steps in the previous task list, using the same map-name but use a different seq-num for the crypto map command. For more information about this, refer to the crypto map command description in the "Cisco Encryption Technology Commands" chapter of the Security Command Reference.
This step puts into effect the crypto maps just defined. You must apply exactly one crypto map set to each interface (pysical or logical) that will encrypt outbound data and decrypt inbound data. This interface provides the encrypted connection to a peer encrypting router. An interface will not encrypt/decrypt data until you apply a crypto map to the interface.
To apply a crypto map to an interface, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
crypto map map-name | Apply a crypto map to an interface. |
Cisco recommends that after you configure your router for encryption, you make a backup of your configuration. (Be careful to restrict unauthorized access of this backed-up configuration.)
You can learn how to back up your configuration in the "Modifying, Downloading, and Maintaining Configuration Files" chapter of the Configuration Fundamentals Configuration Guide.
When GRE tunnel endpoints are located at the peer encrypting routers, you can configure encryption so that all traffic through the GRE tunnel is encrypted.
Note that you cannot selectively encrypt GRE tunnel traffic: either all the GRE tunnel traffic is encrypted, or no GRE tunnel traffic is encrypted.
To configure encryption with GRE tunnels, perform the same basic tasks described previously in the section "Configure Encryption." However, you also must follow the additional instructions described next (for two cases):
For examples of configuring encryption with a GRE tunnel, see the section "Examples of Configuring Encryption with GRE Tunnels," later in this chapter.
To encrypt only traffic through the GRE tunnel, follow these two additional instructions:
To encrypt both GRE tunnel traffic and other specified non-GRE tunnel traffic, follow these three additional instructions:
To configure encryption with an Encryption Service Adaptor (ESA), there are additional instructions that you must follow, in addition to the basic encryption configuration tasks described previously in the section, "Configure Encryption."
This section describes configuration for an ESA plugged into a VIP2 on a Cisco RSP7000 or 7500 series router.
To configure encryption with an ESA plugged into a VIP2, complete these tasks in this order:
For examples of ESA-specific configuration tasks, see the section "Examples of ESA-Specific Encryption Configuration Tasks," later in this chapter.
If the ESA has never been used before, or if it has been removed and reinstalled, the ESA's "Tampered" LED is lit and it must be reset.
If you do not reset the ESA in a VIP2, the ESA crypto engine will not be used; instead, the VIP2 crypto engine will govern the adjoining VIP2 port interfaces (and the Cisco IOS crypto engine will govern the other router interfaces).
To reset an ESA, complete one of the following bulleted tasks:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| crypto card clear-latch slot | Reset the ESA by clearing the ESA hardware latch. | ||
| password | When prompted, create a new password for the ESA or type the ESA password previously assigned. |
| Command | Purpose |
|---|---|
crypto key zeroize dss slot | Clear the ESA. (This deletes all DSS keys for the ESA.) |
If the router, VIP2, and ESA were all previously configured for encryption, you might not need to complete any additional configuration. However, you will need additional configuration in at least the following cases (see the section "Configure Encryption" for descriptions of the tasks):
To configure encryption with an Encryption Service Adaptor (ESA), there are additional instructions that you must follow in addition to the basic encryption configuration tasks described previously in the section "Configure Encryption."
This section describes configuration for an ESA plugged into a Cisco 7200 series router.
For examples of ESA-specific configuration tasks, see the section "Examples of ESA-Specific Encryption Configuration Tasks," later in this chapter.
Complete the following tasks in this order (see following sections for descriptions):
You can optionally complete these additional tasks (see following sections for descriptions):
If the ESA has never been used before, or if it has been removed and reinstalled, the ESA's "Tampered" LED is lit and it must be reset.
To reset an ESA in a Cisco 7200 series router, complete one of the following bulleted tasks:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| crypto card clear-latch slot | Reset the ESA by clearing the ESA hardware latch. | ||
| password | When prompted, create a new password for the ESA. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| crypto card clear-latch slot | Reset the ESA by clearing the ESA hardware latch. | ||
| password | When prompted, type the ESA password previously assigned. | ||
| no | If prompted to enable the ESA, type no. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| crypto card clear-latch slot | Reset the ESA by clearing the ESA hardware latch. | ||
| password | When prompted, type the ESA password previously assigned. | ||
| yes | When prompted to enable the ESA, type yes. |
| Command | Purpose |
|---|---|
crypto key zeroize dss slot | Clear the ESA. (This deletes all DSS keys for the ESA.) |
After you reset the ESA in a Cisco 7200 series router, continue configuring encryption by following the instructions in one of the following bullets:
Enable an ESA in a Cisco 7200 series router by using the following command in global configuration mode:
| Command | Purpose |
|---|---|
crypto card enable slot | Enable the ESA. |
As always, remember to back up your configuration when you are done.
This is an optional task.
After encryption is configured on a Cisco 7200 series router with an ESA, you might want to change which crypto engine to use---the Cisco IOS crypto engine or the ESA crypto engine. This section describes how to switch from one crypto engine to the other.
You should only select a crypto engine if the engine is fully configured for encryption.
If you boot the router with an operational ESA installed, the ESA will be the active crypto engine upon bootup, by default. Otherwise, the Cisco IOS crypto engine will be the default active crypto engine.
If the ESA crypto engine is encrypting traffic, but you want to cause the Cisco IOS crypto engine to encrypt the traffic instead, you can switch to the Cisco IOS crypto engine without removing the ESA. (You might want to do this for testing purposes.)
Select the Cisco IOS crypto engine by using the following command in global configuration mode:
| Command | Purpose |
|---|---|
crypto card shutdown slot | Shut down the ESA. |
After you select the Cisco IOS crypto engine, the Cisco IOS crypto engine will be the active engine, governing the router interfaces. The Cisco IOS crypto engine will perform the encryption services, and the ESA will be inactive.
If the Cisco IOS crypto engine is encrypting traffic, but you want to cause an installed ESA crypto engine to encrypt the traffic instead, you can switch to the ESA crypto engine.
Select the ESA crypto engine by using the following command in global configuration mode:
| Command | Purpose |
|---|---|
crypto card enable slot | Enable the ESA. |
After you select the ESA crypto engine, the ESA crypto engine will be the active engine, governing the router interfaces. The ESA crypto engine will perform encryption services for the router, and the Cisco IOS crypto engine will be inactive.
This is an optional task.
If you ever remove or relocate the ESA or the Cisco 7200, or if the DSS keys ever become compromised, or if you want to turn encryption off at the router, you might want to delete DSS keys to reduce any potential security risk. This section describes how to delete a DSS key pair for an ESA or for a Cisco 7200 series router.
To delete DSS keys, use the following commands beginning in EXEC mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| View all existing sets of DSS keys (ESA and Cisco IOS keys). | |||
| Determine the current (active) crypto engine. | |||
| crypto card enable slot (switch to the Cisco IOS crypto engine) or crypto card shutdown slot (switch to the ESA crypto engine) | If the current engine is not the engine for which you want to delete keys, change engines. (When you delete keys, the software deletes keys for the current active engine.) | ||
| Verify that the current crypto engine is the engine for which you want to delete keys. | |||
| crypto key zeroize dss (for the Cisco IOS crypto engine) or crypto key zeroize dss slot (for the ESA crypto engine) | Delete the DSS keys for the current crypto engine. |
After you delete DSS keys for a crypto engine, if you ever want to use that engine for encryption, you must regenerate and exchange new DSS keys for that engine. For the ESA crypto engine, you must also enable the ESA.
This section describes options that you can configure to customize encryption on a router:
The default time duration of an encrypted session is 30 minutes. After the default time duration expires, an encrypted session must be renegotiated if encrypted communication is to continue. You can change this default to extend or shorten the time of encrypted sessions.
You might want to shorten session times if you believe that there is a risk of compromised session keys.
You might want to extend session times if your system has trouble tolerating the interruptions caused when sessions are renegotiated.
Change the time duration of encrypted sessions by using at least the first of the following commands in global configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| crypto cisco key-timeout minutes | Define maximum time duration of encrypted sessions. | ||
| View defined time duration of encrypted sessions. |
Diffie-Hellman (DH) numbers are generated in pairs during the setup of each encrypted session. (DH numbers are used during encrypted session setup to compute the DES session key.) Generating these numbers is a CPU-intensive activity, which can make session setup slow---especially for low-end routers. To speed up session setup time, you may choose to pregenerate DH numbers. It is usually necessary to pregenerate only one or two DH numbers.
Pregenerate DH numbers by using the following command in global configuration mode:
| Command | Purpose |
|---|---|
crypto cisco pregen-dh-pairs count [slot] | Pregenerate DH numbers. |
When you configure encryption access lists, you configure source and destination pairs in criteria statements. Any traffic that matches the criteria is then encrypted.
By default, the maximum number of distinct sources (host or subnets) that you can define in an encryption access list is 100. Also, the maximum number of distinct destinations that you can define for any given source address is 10. For example, if you define six different source addresses, you can define up to 10 destination addresses for each of the six sources, for a total of 60 access list criteria statements.
These limits exist because of the amount of memory that must be reserved for encryption connections. If there are more potential connections, there must be more memory preallocated.
For most situations, the defaults of 100 maximum sources and 10 maximum destinations per source are sufficient. Cisco recommends that you do not change the defaults unless you actually exceed the number of sources or destinations per source.
However, in some situations you might want to change one or both of these maximum values. For example, if more than 10 remote sites need to connect to one server behind your router, then you need more than 10 destination addresses (one for each remote site) to pair up with the server's source address in the local router's encryption access list. In this case, you need to change the default of 10 maximum destination addresses per source address.
When changing limits, you should consider the amount of memory that will be allocated. In general, if you increase one value, decrease the other value. This prevents your router from running out of memory because too much memory was preallocated.
The amount of memory reserved for encrypted connections changes if you change the defaults.
For every additional source, the following additional bytes of memory will be allocated:
64 + (86 x the specified number of maximum destinations)
For every additional destination, the following additional bytes of memory will be allocated:
68 x the specified number of maximum sources
For example, if you specify 5 maximum sources, and 250 maximum destinations per source, the memory allocated for encryption connections is calculated as follows:
{5 x [64 + (68 x 250)]} + {250 x (68 x 5)} = 170320 bytes
Change the default limits by using one or both of the following commands in global configuration mode, then reboot the router for the changes to take effect:
| Command | Purpose |
|---|---|
crypto cisco entities number | Change the maximum number of distinct sources (hosts or subnets) that you can define in the encryption access list statements. |
crypto cisco connections number | Change the maximum number of destinations (hosts or subnets) per source that you can define in the encryption access list statements. |
For an example of changing these values, see the section "Example of Changing Encryption Access List Limits," later in this chapter.
You can turn off encryption for certain router interfaces, or you can turn off encryption completely for the entire router.
Deleting DSS keys deconfigures encryption for the crypto engine and also reduces security risk by ensuring that the keys cannot be misused if you lose physical control over the router or ESA.
After you delete DSS keys for a crypto engine, you will not be able to perform encryption on the interfaces governed by that crypto engine.
 | Caution DSS keys cannot be recovered after they have been deleted. Use this function only after careful consideration. |
For all platforms other than Cisco 7200 series routers, to delete DSS public/private keys for a crypto engine, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
crypto key zeroize dss [slot]1 | Delete DSS keys for a crypto engine. |
| 1Only Cisco 7200 and 7500 series routers require the slot argument. |
For a Cisco 7200 series router, to delete DSS public/private keys for a crypto engine, refer to the section "Delete DSS Keys" earlier in this chapter.
This section discusses how to verify your configuration and the correct operation of encryption. This section also discusses diagnosing encryption problems.
You should complete all the required configuration tasks (as described earlier in this chapter) before trying to test or troubleshoot your encryption configuration.
This section includes the following topics:
If you want to test the encryption setup between peer routers, you can attempt to manually establish a session using the IP address of a local host and a remote host which have been specified in an encryption access list. (The encryption list must be specified in a crypto map definition, and that crypto map must be applied to an interface before this test will be successful.)
To test the encryption setup, use the following commands in privileged EXEC mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| test crypto initiate-session src-ip-addr dst-ip-addr map-name seq-num | Set up a test encryption session. | ||
| View the connection status. |
An example at the end of this chapter explains how to interpret the show crypto cisco connections command output.
If you need to verify the state of a connection, you can use the following commands in privileged EXEC mode:
| Command | Purpose |
|---|---|
Check status of all encryption connections. | |
Check status of a crypto map. | |
Check that connection is established and that packets are being encrypted. |
When using encryption, you might encounter some of these problems:
Packets are normally dropped while an encrypted session is being set up. If this poses a problem for your network, you should extend the length of encryption sessions as described previously in the section "Define Time Duration of Encrypted Sessions." The longer the session time, the fewer the interruptions caused by session renegotiation.
Packets might also be dropped if you switch crypto engines in a Cisco 7200 series router with an ESA. If this is a problem, you should only switch crypto engines when encrypted traffic is light.
IP fragments are always dropped on VIP2 interfaces, because IP fragmentation is not supported with encryption on VIP2 interfaces.
Hosts might experience difficulty in establishing Telnet sessions if the session uses two encrypting peer routers to create the connection. This difficulty is more likely to occur if the peer routers are low-end routers such as Cisco 2500 series routers. Telnet sessions can fail to be established when a Telnet connection attempt times out before the encrypted session setup is complete.
If a Telnet session fails to establish, the host should wait a short time (a few seconds might be sufficient), and then attempt the Telnet connection again. After the short wait, the encrypted session setup should be complete, and the Telnet session can be established. Enabling pregeneration of DH numbers (described later in this chapter) might also help by speeding up encryption session connection setup times.
If NVRAM fails, or if your ESA is tampered with or replaced, DSS public/private keys will no longer be valid. If this happens, you will need to regenerate and re-exchange DSS keys. Generating and exchanging DSS keys are described earlier in the section "Configure Encryption."
If an installed ESA is not active when you boot a router, the router displays a message similar to this message, indicating that the router switched over to the Cisco IOS crypto engine:
There are no keys on the ESA in slot 2- ESA not enabled ...switching to SW crypto engine
You can also determine if the ESA crypto engine is not active by using the show crypto engine brief command---look at the "crypto engine state" field in the output. If no crypto engine is active, the state field indicates "pending."
The ESA crypto engine will not be active if you removed and reinstalled the ESA, if the ESA was tampered with, or if encryption is not configured correctly for the ESA.
If the Cisco IOS crypto engine is active, but you want to use the ESA crypto engine instead, make sure that the ESA crypto engine is reset (crypto card clear-latch command), and for Cisco 7200 series routers, also make sure that the ESA crypto engine is enabled (crypto card enable command). You might also need to complete or verify additional configuration; refer to the instructions for configuring encryption with an ESA, in the earlier section "Configure Encryption with an ESA in a VIP2" or "Configure Encryption with an ESA in a Cisco 7200 Series Router."
To verify that the ESA has DSS keys, you can use the show crypto card command and look at the "DSS Key set" field in the output. If the field contains "Yes," the ESA has DSS keys generated and stored. In this case, you might only need to reset and enable the ESA to make it active.
If you attempt to generate DSS keys for the Cisco IOS crypto engine on a Cisco 7200 series router with an installed ESA without DSS keys, the router might assume that you are trying to generate keys for the ESA and prompt for the ESA password.
| Command | Purpose |
|---|---|
crypto card shutdown slot | Shut down the ESA. |
If you remove a configured ESA from a VIP2, you must reboot the router. If you do not, the router might hang when it tries to access the absent ESA.
Debug commands are also available to assist in problem solving. These commands are documented in the Debug Command Reference.
The following sections provide examples of configuring and testing your router for CET:
The following example illustrates two encrypting peer routers (named Apricot and Banana) generating their respective DSS public/private keys. Apricot is a Cisco 2500 series router. Banana is a Cisco 7500 series router with an RSP in chassis slot 4 and an ESA/VIP2 in chassis slot 2.
Apricot(config)# crypto key generate dss Apricot
Generating DSS keys .... [OK] Apricot(config)#
Banana(config)# crypto key generate dss BananaIOS 4
Generating DSS keys .... [OK] Banana(config)# crypto key generate dss BananaESA 2
% Initialize the crypto card password. You will need this password in order to generate new signature keys or clear the crypto card extraction latch. Password: <passwd>
Re-enter password: <passwd>
Generating DSS keys .... [OK] Banana(config)#
The password entered in this example is a new password that you create when you generate DSS keys for an ESA crypto engine for the first time. If you ever generate DSS keys a second time for the same ESA crypto engine, you must use the same password to complete the key regeneration.
The following is an example of a DSS public key exchange between two peer encrypting routers (Apricot and Banana). Apricot is a Cisco 2500 series router, and Banana is a Cisco 7500 series router with an ESA. In this example, Apricot sends its Cisco IOS DSS public key, and Banana sends its ESA DSS public key. DSS keys have already been generated as shown in the previous example.
Before any commands are entered, one administrator must call the other administrator. After the phone call is established, the two administrators decide which router is "PASSIVE" and which is "ACTIVE" (an arbitrary choice). In this example, router Apricot is ACTIVE and router Banana is PASSIVE. To start, PASSIVE enables a connection as follows:
Banana(config)# crypto key exchange dss passive
Enter escape character to abort if connection does not complete. Wait for connection from peer[confirm]<Return>
Waiting ....
PASSIVE must wait while ACTIVE initiates the connection and sends a DSS public key.
Apricot(config)# crypto key exchange dss 192.168.114.68 Apricot
Public key for Apricot: Serial Number 01461300 Fingerprint 0F1D 373F 2FC1 872C D5D7 Wait for peer to send a key[confirm]<Return>
Waiting ....
After ACTIVE sends a DSS public key, the key's serial number and Fingerprint display on both terminals, as shown previously and as follows:
Public key for Apricot: Serial Number 01461300 Fingerprint 0F1D 373F 2FC1 872C D5D7 Add this public key to the configuration? [yes/no]: y
Now the two administrators both must verbally verify that their two screens show the same serial number and Fingerprint. If they do, PASSIVE will accept the DSS key as shown previously by typing y, and continue by sending ACTIVE a DSS public key:
Send peer a key in return[confirm]<Return>
Which one? BananaIOS? [yes]: n
BananaESA? [yes]: <Return>
Public key for BananaESA: Serial Number 01579312 Fingerprint BF1F 9EAC B17E F2A1 BA77 Banana(config)#
Both administrators observe Banana's serial number and Fingerprint on their screens. Again, they verbally verify that the two screens show the same numbers.
Public key for BananaESA: Serial Number 01579312 Fingerprint BF1F 9EAC B17E F2A1 BA77 Add this public key to the configuration? [yes/no]: y
Apricot(config)#
ACTIVE accepts Apricot's DSS public key. Both administrators hang up the phone and the key exchange is complete.
Figure 17 shows complete screens of the two routers. The steps are numbered on the figure to show the sequence of the entire exchange.
In this example, a router (Apricot) globally enables two DES algorithms: the basic DES algorithm with 8-bit Cipher Feedback (CFB), and the 40-bit DES algorithm with 8-bit CFB. Another router (Banana) globally enables three DES algorithms: the basic DES algorithm with 8-bit CFB, the basic DES algorithm with 64-bit CFB, and the 40-bit DES algorithm with 8-bit CFB.
The following commands are entered from the global configuration mode.
crypto cisco algorithm des cfb-8 crypto cisco algorithm 40-bit-des cfb-8
crypto cisco algorithm des cfb-8 crypto cisco algorithm des cfb-64 crypto cisco algorithm 40-bit-des cfb-8
The following two examples show how to set up interfaces for encrypted transmission. Participating routers will be configured as encrypting peers for IP packet encryption.
In the first example, a team of researchers at a remote site communicate with a research coordinator at headquarters. Company-confidential information is exchanged by IP traffic that consists only of TCP data. Figure 18 shows the network topology.
Apricot is a Cisco 2500 series router, and Banana is a Cisco 7500 series router with an ESA/VIP2 in chassis slot 3.
Apricot(config)# access-list 101 permit tcp 192.168.3.0 0.0.0.15 host
192.168.15.6
Apricot(config)# crypto map Research 10
Apricot(config-crypto-map)# set peer BananaESA
Apricot(config-crypto-map)# set algorithm des cfb-8
Apricot(config-crypto-map)# match address 101
Apricot(config-crypto-map)# exit
Apricot(config)# interface s0
Apricot(config-if)# crypto map Research
Apricot(config-if)# exit
Apricot(config)#
Banana(config)# access-list 110 permit tcp host 192.168.15.6 192.168.3.0
0.0.0.15
Banana(config)# crypto map Rsrch 10
Banana(config-crypto-map)# set peer Apricot
Banana(config-crypto-map)# set algorithm des cfb-8
Banana(config-crypto-map)# set algorithm des cfb-64
Banana(config-crypto-map)# match address 110
Banana(config-crypto-map)# exit
Banana(config)# interface s3/0/2
Banana(config-if)# crypto map Rsrch
Banana(config-if)# exit
Banana(config)#
Because Banana set two DES algorithms for crypto map Rsrch, Banana could use either algorithm with traffic on the S3/0/2 interface. However, because Apricot only set one DES algorithm (CFB-8 DES) for the crypto map Research, that is the only DES algorithm that will be used for all encrypted traffic between Apricot and Banana.
In the second example, employees at two branch offices and at headquarters must communicate sensitive information. A mix of TCP and UDP traffic is transmitted by IP packets. Figure 19 shows the network topology used in this example.
Apricot is a Cisco 2500 series router and connects to the Internet through interface S1. Both Banana and Cantaloupe are Cisco 7500 series routers with ESA cards. Banana connects to the Internet using the ESA-governed VIP2 interface S2/1/2. Cantaloupe is already using every VIP2 interface (governed by the ESA card) to connect to several offsite financial services, so it must connect to the Internet using a serial interface (S3/1) in slot 3. (Cantaloupe's interface S3/1 is governed by the Cisco IOS crypto engine.)
Apricot will be using one interface to communicate with both Banana and Cantaloupe. Because only one crypto map can be applied to this interface, Apricot creates a crypto map that has two distinct definition sets by using two different seq-num values with the same map-name. By using seq-num values of 10 and 20, Apricot creates a single crypto map set named "TXandNY" that contains a subset of definitions for encrypted sessions with Banana, and a second distinct subset for definitions for encrypted sessions with Cantaloupe.
Banana and Cantaloupe each also use a single interface to communicate with the other two routers, and therefore will use the same strategy as Apricot does for creating crypto map sets.
In this example, we assume that Apricot has generated DSS keys with the key-name "Apricot.TokyoBranch," Banana has generated DSS keys with the key-name "BananaESA.TXbranch," and Cantaloupe has generated DSS keys with the key-name "CantaloupeIOS.NY." We also assume that each router has exchanged DSS public keys with the other two routers, and that each router has enabled each DES algorithm that is specified in the crypto maps.
Apricot(config)# access-list 105 permit tcp 192.168.3.0 0.0.0.15 192.168.204.0 0.0.0.255
Apricot(config)# access-list 105 permit udp 192.168.3.0 0.0.0.15 192.168.204.0 0.0.0.255
Apricot(config)# access-list 106 permit tcp 192.168.3.0 0.0.0.15 192.168.15.0 0.0.0.255
Apricot(config)# access-list 106 permit udp 192.168.3.0 0.0.0.15 192.168.15.0 0.0.0.255
Apricot(config)# crypto map TXandNY 10
Apricot(config-crypto-map)# set peer BananaESA.TXbranch
Apricot(config-crypto-map)# set algorithm 40-bit-des cfb-8
Apricot(config-crypto-map)# match address 105
Apricot(config-crypto-map)# exit
Apricot(config)# crypto map TXandNY 20
Apricot(config-crypto-map)# set peer CantaloupeIOS.NY
Apricot(config-crypto-map)# set algorithm 40-bit-des cfb-64
Apricot(config-crypto-map)# match address 106
Apricot(config-crypto-map)# exit
Apricot(config)# interface s1
Apricot(config-if)# crypto map TXandNY
Apricot(config-if)# exit
Apricot(config)#
Banana(config)# access-list 110 permit tcp 192.168.204.0 0.0.0.255 192.168.3.0 0.0.0.15
Banana(config)# access-list 110 permit udp 192.168.204.0 0.0.0.255 192.168.3.0 0.0.0.15
Banana(config)# access-list 120 permit tcp 192.168.204.0 0.0.0.255 192.168.15.0 0.0.0.255
Banana(config)# access-list 120 permit udp 192.168.204.0 0.0.0.255 192.168.15.0 0.0.0.255
Banana(config)# crypto map USA 10
Banana(config-crypto-map)# set peer Apricot.TokyoBranch
Banana(config-crypto-map)# set algorithm 40-bit-des cfb-8
Banana(config-crypto-map)# match address 110
Banana(config-crypto-map)# exit
Banana(config)# crypto map USA 20
Banana(config-crypto-map)# set peer CantaloupeIOS.NY
Banana(config-crypto-map)# set algorithm des cfb-64
Banana(config-crypto-map)# match address 120
Banana(config-crypto-map)# exit
Banana(config)# interface s2/1/2
Banana(config-if)# crypto map USA
Banana(config-if)# exit
Banana(config)#
Cantaloupe(config)# access-list 101 permit tcp 192.168.15.0 0.0.0.255 192.168.3.0 0.0.0.15
Cantaloupe(config)# access-list 101 permit udp 192.168.15.0 0.0.0.255 192.168.3.0 0.0.0.15
Cantaloupe(config)# access-list 102 permit tcp 192.168.15.0 0.0.0.255 192.168.204.0 0.0.0.255
Cantaloupe(config)# access-list 102 permit udp 192.168.15.0 0.0.0.255 192.168.204.0 0.0.0.255
Cantaloupe(config)# crypto map satellites 10
Cantaloupe(config-crypto-map)# set peer Apricot.TokyoBranch
Cantaloupe(config-crypto-map)# set algorithm 40-bit-des cfb-64
Cantaloupe(config-crypto-map)# match address 101
Cantaloupe(config-crypto-map)# exit
Cantaloupe(config)# crypto map satellites 20
Cantaloupe(config-crypto-map)# set peer BananaESA.TXbranch
Cantaloupe(config-crypto-map)# set algorithm des cfb-64
Cantaloupe(config-crypto-map)# match address 102
Cantaloupe(config-crypto-map)# exit
Cantaloupe(config)# interface s3/1
Cantaloupe(config-if)# crypto map satellites
Cantaloupe(config-if)# exit
Cantaloupe(config)#
The previous configurations will result in DES encryption algorithms being applied to encrypted IP traffic as shown in Figure 20.
In this example, there are 50 remote sites connecting to a single server. The connections between the server and each site need to be encrypted. The server is located behind the local router named Apricot. Each of the remote sites connects through its own router.
Because of the large number of destination addresses that must be paired with the same source address in the local encryption access list, the default limits are changed.
Apricot(config)# crypto cisco connections 60
%Please reboot for the new connection size to take effect Apricot(config)# crypto cisco entities 5
%Please reboot for the new table size to take effect
Even though there is only one server, and only 50 remote sites, this example defines 5 sources and 60 destinations. This allows room for future growth of the encryption access list. If another source or destination is added later, the limits will not have to be increased and the router rebooted again, which is a disruptive process.
There are two example configurations for encryption with GRE tunnels:
This configuration causes all traffic through the GRE tunnel to be encrypted. No other traffic at the interface will be encrypted. The GRE tunnel is from router Apricot to router Banana. (Only partial configuration files are shown for each router.)
crypto map BananaMap 10 set algorithm 40-bit-des set peer Banana match address 101 ! interface Tunnel0 no ip address ipx network 923FA800 tunnel source 10.1.1.2 tunnel destination 10.1.1.1 crypto map BananaMap ! interface Serial0 ip address 10.1.1.2 255.255.255.0 crypto map BananaMap ! access-list 101 permit gre host 10.1.1.2 host 10.1.1.1
crypto map ApricotMap 10 set algorithm 40-bit-des set peer Apricot match address 102 ! interface Tunnel0 no ip address ipx network 923FA800 tunnel source 10.1.1.1 tunnel destination 10.1.1.2 crypto map ApricotMap ! interface Serial0 ip address 10.1.1.1 255.255.255.0 clockrate 2000000 no cdp enable crypto map ApricotMap ! access-list 102 permit gre host 10.1.1.1 host 10.1.1.2
This configuration encrypts all GRE tunnel traffic, and it also encrypts TCP traffic between two hosts with the IP addresses 172.16.25.3 and 192.168.3.5. The GRE tunnel is from router Apricot to router Banana. (Only partial configuration files are shown for each router.)
crypto map BananaMapTunnel 10 set algorithm 40-bit-des set peer Banana match address 101 ! crypto map BananaMapSerial 10 set algorithm 40-bit-des set peer Banana match address 101 crypto map BananaMapSerial 20 set algorithm 40-bit-des set peer Banana match address 110 ! interface Tunnel0 no ip address ipx network 923FA800 tunnel source 10.1.1.2 tunnel destination 10.1.1.1 crypto map BananaMapTunnel ! interface Serial0 ip address 10.1.1.2 255.255.255.0 crypto map BananaMapSerial ! access-list 101 permit gre host 10.1.1.2 host 10.1.1.1 access-list 110 permit tcp host 172.16.25.3 host 192.168.3.5
crypto map ApricotMapTunnel 10 set algorithm 40-bit-des set peer Apricot match address 102 ! crypto map ApricotMapSerial 10 set algorithm 40-bit-des set peer Apricot match address 102 crypto map ApricotMapSerial 20 set algorithm 40-bit-des set peer Apricot match address 112 ! interface Tunnel0 no ip address ipx network 923FA800 tunnel source 10.1.1.1 tunnel destination 10.1.1.2 crypto map ApricotMapTunnel ! interface Serial0 ip address 10.1.1.1 255.255.255.0 clockrate 2000000 no cdp enable crypto map ApricotMapSerial ! access-list 102 permit gre host 10.1.1.1 host 10.1.1.2 access-list 112 permit tcp host 192.168.3.5 host 172.16.25.3
This section includes examples of the following:
The following example resets an ESA on a Cisco 7500 series router. The ESA is in a VIP2 that is in slot 4 of the router chassis.
Banana(config)# crypto card clear-latch 4
% Enter the crypto card password. Password: <passwd>
Banana(config)#
The following example resets an ESA without DSS keys, for a Cisco 7200 series router. The ESA is in the router chassis slot 2.
Apricot(config)# crypto card clear-latch 2
% Enter the crypto card password. Password: <passwd>
ESA in slot 2 not enabled. [OK] Apricot(config)#
The following example resets an ESA with DSS keys, for a Cisco 7200 series router; the ESA was previously in use on the same router, but was removed and reinstalled. No changes to the encryption configuration are desired by the administrator. The ESA is in the router chassis slot 2.
Apricot(config)# crypto card clear-latch 2
% Enter the crypto card password. Password: <passwd>
Keys were found for this ESA- enable ESA now? [yes/no]: yes
...switching to HW crypto engine [OK] Apricot(config)#
The following example resets an ESA with DSS keys, for a Cisco 7200 series router; the ESA was previously used in a different router, and requires new DSS keys to be generated and exchanged before the ESA can become operational. The ESA is in the router chassis slot 2.
Apricot(config)# crypto card clear-latch 2
% Enter the crypto card password. Password: <passwd>
Keys were found for this ESA- enable ESA now? [yes/no]: no
ESA in slot 2 not enabled. [OK] Apricot(config)#
The following example enables an ESA in the router chassis slot 2:
Apricot(config)# crypto card enable 2
...switching to HW crypto engine Apricot(config)#
Select a different crypto engine only if the new engine is fully configured for encryption.
The following example switches from the Cisco IOS crypto engine to the ESA crypto engine. The ESA crypto engine is in the router chassis slot 4.
Apricot(config)# crypto card enable 4
...switching to HW crypto engine Apricot(config)#
The following example switches from the ESA crypto engine to the Cisco IOS crypto engine. The ESA crypto engine is in the router chassis slot 4.
Apricot(config)# crypto card shutdown 4
...switching to SW crypto engine Apricot(config)#
This section includes an example for a Cisco 7500 series router and an example for a Cisco 7200 series router with an installed ESA.
The following example deletes all the DSS keys on a Cisco 7500 series router. The RSP is in chassis slot 3 and a VIP2 is in chassis slot 4. Deleting all the DSS keys turns off encryption completely for the router. The Cisco IOS crypto engine keys are deleted first, then the VIP2 crypto engine keys.
Apricot(config)# crypto key zeroize dss 3
Warning! Zeroize will remove your DSS signature keys. Do you want to continue? [yes/no]: y
Keys to be removed are named Apricot.IOS. Do you really want to remove these keys? [yes/no]: y
[OK] Apricot(config)# crypto key zeroize dss 4
Warning! Zeroize will remove your DSS signature keys. Do you want to continue? [yes/no]: y
Keys to be removed are named Apricot.VIP. Do you really want to remove these keys? [yes/no]: y
[OK] Apricot(config)#
The following example deletes DSS keys only for an ESA, in chassis slot 2 of a Cisco 7200 series router. The Cisco IOS crypto engine DSS keys are not deleted in this example.
1. View existing DSS keys:
Apricot# show crypto key mypubkey dss
crypto key pubkey-chain dss Apricot.IOS 01709642 BDD99A6E EEE53D30 BC0BFAE6 948C40FB 713510CB 32104137 91B06C8D C2D5B422 D9C154CA 00CDE99B 425DB9FD FE3162F1 1E5866AF CF66DD33 677259FF E5C24812 quit crypto key pubkey-chain dss Apricot.ESA 01234567 866AFCF6 E99B425D FDFE3162 BC0BFAE6 13791B06 713510CB 4CA00CDE 0BC0BFAE 3791B06C 154C0CDE F11E5866 AE6948C4 DD336772 3F66DF33 355459FF 2350912D quit Apricot#
This output shows that DSS keys exist for both the Cisco IOS crypto engine and for the ESA crypto engine.
2. Determine the Active Crypto Engine:
Apricot# show crypto engine configuration
engine name: Apricot.IOS engine type: software serial number: 01709642 platform: rsp crypto engine Encryption Process Info: input queue top: 44 input queue bot: 44 input queue count: 0 Apricot#
The output shows that the Cisco IOS crypto engine is the active engine.
3. Because we want to delete DSS keys for the ESA crypto engine, change to the ESA crypto engine:
Apricot# config terminal
Enter configuration commands, one per line. End with CNTL/Z. Apricot(config)# crypto card enable 2
...switching to HW crypto engine Apricot(config)#
4. Verify that the ESA crypto engine is the active engine:
Apricot(config)# exit
Apricot# show crypto engine configuration
engine name: Apricot.ESA engine type: hardware serial number: 01234567 platform: esa crypto engine Encryption Process Info: input queue top: 0 input queue bot: 0 input queue count: 0 Apricot#
The output shows that the ESA crypto engine is now the active engine.
5. Delete the ESA DSS keys:
Apricot# config terminal
Enter configuration commands, one per line. End with CNTL/Z. Apricot(config)# crypto key zeroize dss 2
Warning! Zeroize will remove your DSS signature keys. Do you want to continue? [yes/no]: y
Keys to be removed are named Apricot.ESA. Do you really want to remove these keys? [yes/no]: y
[OK] Apricot(config)#
6. View existing DSS keys:
Apricot(config)# exit
Apricot# show crypto key mypubkey dss
crypto key pubkey-chain dss Apricot.IOS 01709642 BDD99A6E EEE53D30 BC0BFAE6 948C40FB 713510CB 32104137 91B06C8D C2D5B422 D9C154CA 00CDE99B 425DB9FD FE3162F1 1E5866AF CF66DD33 677259FF E5C24812 quit Apricot#
The output shows that the ESA crypto engine keys have been deleted.
7. Determine the active crypto engine:
Apricot# show crypto engine configuration
engine name: Apricot.IOS engine type: software serial number: 01709642 platform: rsp crypto engine Encryption Process Info: input queue top: 0 input queue bot: 0 input queue count: 0 Apricot#
The output shows that the system has defaulted back to the Cisco IOS crypto engine as the active engine.
The following example sets up and verifies a test encryption session.
Assume the same network topology and configuration as in the previous example and shown in Figure 19.
In this example, router Apricot sets up a test encryption session with router Banana and then views the connection status to verify a successful encrypted session connection.
Step 1 Router Apricot sets up a test encryption connection with router Banana.
Apricot# test crypto initiate-session 192.168.3.12 192.168.204.110 BananaESA.TXbranch 10
Sending CIM to: 192.168.204.110 from: 192.168.3.12. Connection id: -1
Notice the Connection id value is -1. A negative value indicates that the connection is being set up.
Step 2 Router Apricot issues the show crypto cisco connections command.
Look in the Pending Connection Table for an entry with a Conn_id value equal to the previously shown Connection id value---in this case, look for an entry with a Conn_id value of -1. If this is the first time an encrypted connection has been attempted, there will only be one entry (as shown).
Note the PE and UPE addresses for this entry.
Step 3 Now, look in the Connection Table for an entry with the same PE and UPE addresses. In this case, there is only one entry in both tables, so finding the right Connection Table entry is easy.
Step 4 At the Connection Table entry, note the Conn_id and New_id values. In this case, Conn_id equals -1 (as in the Pending Connection Table), and New_id equals 1. The New_id value of 1 will be assigned to the test connection when setup is complete. (Positive numbers are assigned to established, active connections.)
Step 5 Apricot waits a few seconds for the test connection to establish and then reissues the show crypto cisco connections command.
Again, look for the Connection Table entry with the same PE and UPE addresses as shown before. In this entry, notice that the Conn_id value has changed to 1. This indicates that our test connection has been successfully established, because the Conn_id value has changed to match the New_id value of Step 4. Also, New_id has been reset to 0 at this point, indicating that there are no new connections currently being set up.
In the command output of Step 5, there is no longer a Pending Connection Table being displayed, which indicates that there are currently no pending connections. This is also a good clue that the test connection was successfully established.
The show crypto cisco connections command is explained in greater detail in the chapter "Cisco Encryption Technology Commands" in the Security Command Reference. There you can find a description of how connection IDs are assigned during and following connection setup.
|
|