Configuring Cisco Encryption Technology
Available Languages
Table Of Contents
Configuring Cisco Encryption Technology
Cisco's Implementation of Encryption
Where Are Packets Encrypted and Decrypted in the Network?
When Can Encrypted Packets Be Exchanged?
How Does an Encrypting Router Identify Other Peer Encrypting Routers?
What Standards Are Implemented in Cisco's Encryption?
How Does Cisco's Encryption Work?
You Enable Peer Router Authentication with a DSS Key Exchange
A Router Establishes an Encrypted Session with a Peer
Peer Routers Encrypt and Decrypt Data During an Encrypted Session
Additional Sources of Information
Prework: Before Configuring Encryption
Considering Your Network Topology
Identifying Crypto Engines Within Each Peer Router
The VIP2 Crypto Engine (Cisco RSP7000 and 7500 Series Routers Only)
The Encryption Service Adapter Crypto Engine (Cisco 7200, RSP7000, and 7500 Series Routers Only)
Understanding Implementation Issues and Limitations
Multicast of Encrypted Traffic
Restrictions for Switching Types with the VIP2
Number of Simultaneous Encrypted Sessions
Generating DSS Public/Private Keys
Enabling DES Encryption Algorithms
Defining Crypto Maps and Assigning Them to Interfaces
Setting Up Encryption Access List
Applying Crypto Maps to Interfaces
Configuring Encryption with GRE Tunnels
Encrypting Only GRE Tunnel Traffic
Encrypting GRE Tunnel Traffic and Other Traffic
Configuring Encryption with an ESA in a VIP2
Performing Additional Encryption Configuration
Configuring Encryption with an ESA in a Cisco 7200 Series Router
Performing Additional Encryption Configuration
Selecting the Cisco IOS Crypto Engine
Selecting the ESA Crypto Engine
Customizing Encryption (Configuring Options)
Defining Time Duration of Encrypted Sessions
Shortening Session Setup Times by Pregenerating DH Numbers
Changing Encryption Access List Limits
When Should the Limits Be Changed?
How Much Memory Is Preallocated If the Limits Are Changed?
Testing and Troubleshooting Encryption
Testing the Encryption Configuration
Diagnosing Connection Problems
Diagnosing Other Miscellaneous Problems
Difficulty Establishing Telnet Sessions
Invalid DSS Public/Private Keys
Password Requested When You Generate DSS Keys
Encryption Configuration Examples
Generating DSS Public/Private Keys Example
Exchanging DSS Public Keys Example
Enabling DES Encryption Algorithms Example
Changing Encryption Access List Limits Example
Configuring Encryption with GRE Tunnels Examples
Example of Encrypting Only GRE Tunnel Traffic
Example of Encrypting Both GRE Tunnel Traffic and Other Non-GRE Traffic
ESA-Specific Encryption Configuration Task Examples
Example of Enabling an ESA (Cisco 7200 Series Routers Only)
Examples of Selecting a Different Crypto Engine (Cisco 7200 Series Routers Only)
Example for a Cisco 7500 Series Router
Example for a Cisco 7200 Series Router
Testing the Encryption Connection Example
Configuring Cisco Encryption Technology
This chapter describes how to configure your router for network data encryption using Cisco Encryption Technology (CET).
In This Chapter
This chapter includes the following sections:
•
Cisco's Implementation of Encryption
•
•
•
•
•
•
•
•
Note
For a complete description of the encryption commands in this chapter, refer to the "Cisco Encryption Technology Commands" chapter in the Cisco IOS Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
Why Encryption?
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 24 illustrates the encryption of an IP packet as it travels across an unsecured network.
Figure 24 IP Packet Encryption
Cisco's Implementation of Encryption
The following sections answer these questions:
•
•
•
•
•
What Gets Encrypted?
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.
Where Are Packets Encrypted and Decrypted in the Network?
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.
When Can Encrypted Packets Be Exchanged?
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.
How Does an Encrypting Router Identify Other Peer Encrypting Routers?
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.
What Standards Are Implemented in Cisco's Encryption?
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.
How Does Cisco's Encryption Work?
The following sections provide an overview of Cisco's encryption process:
•
•
•
You Enable Peer Router Authentication with a DSS Key Exchange
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 25). 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 "Configuring Encryption" section.)
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.
Figure 25 Exchanging DSS Keys (Overview)
A Router Establishes an Encrypted Session with a Peer
An encrypted session must be established before a Cisco router can send encrypted data to a peer router. (See Figure 26.) 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.
Figure 26 Establishing an Encrypted Session
Peer Routers Encrypt and Decrypt Data During an Encrypted Session
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 27.)
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.
Figure 27 Encrypting Data
Additional Sources of Information
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
Prework: Before Configuring Encryption
You should understand and follow the guidelines in this section before attempting to configure your system for CET. This section describes the following guidelines:
•
•
•
Identifying Peer Routers
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.
Considering Your Network Topology
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.
Identifying Crypto Engines Within Each Peer Router
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 "Configuring Encryption" section.)
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.
Note
The three different crypto engines are described next.
The Cisco IOS Crypto Engine
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.)
The VIP2 Crypto Engine (Cisco RSP7000 and 7500 Series Routers Only)
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.
Note
The Encryption Service Adapter Crypto Engine (Cisco 7200, RSP7000, and 7500 Series Routers Only)
Cisco 7200, RSP7000, and 7500 series routers with an Encryption Service Adapter (ESA) have an ESA crypto engine.
Cisco 7200 Series Routers with an ESA
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.
Cisco RSP7000 and 7500 Series Routers with an ESA
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.
Understanding Implementation Issues and Limitations
Please note the following issues and limitations of encryption, described in this section:
•
•
•
Encapsulation
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 24 shows port adapter support by platform.
Multicast of Encrypted Traffic
Encrypted multicast is not supported.
IP Fragmentation
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.
Restrictions for Switching Types with the VIP2
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.
Number of Simultaneous Encrypted Sessions
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.
Performance Impacts
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.
Configuring Encryption
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:
•
•
•
•
•
Note
For examples of the configurations in this section, see the section "Encryption Configuration Examples" at the end of this chapter.
Generating DSS Public/Private Keys
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 "Identifying 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:
Note
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 "Configuring Encryption with an ESA in a VIP2" and "Configuring Encryption with an ESA in a Cisco 7200 Series Router."
Exchanging DSS Public Keys
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.
Note
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 28):
Step 1
Step 2
Step 3
Router (config)# crypto key exchange dss passive [tcp-port]
Enables a DSS exchange connection.
Step 4
Router (config)# crypto key exchange dss ip-address key-name [tcp-port]
Initiates a 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
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
The previous steps (illustrated in Figure 28) must be accomplished between your router and a peer router for every peer router with which you will be conducting encrypted sessions.
Figure 28 Exchanging DSS Public Keys
Enabling DES Encryption Algorithms
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.
Note
One DES algorithm is enabled for your router by default. If you do not plan to use the default DES algorithm, you may choose to disable it. If you are running a non-exportable image, the DES default algorithm will be basic DES with 64-bit CFB. If you are running an exportable image, the DES default algorithm will be the 40-bit variation of DES with 64-bit CFB.
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:
Defining Crypto Maps and Assigning Them to Interfaces
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:
1.
3.
Note
Setting Up Encryption Access List
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:
Router (config)# 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
Router (config)# ip access-list extended name
Follow with permit and deny statements as appropriate.
Specifies conditions to determine which IP packets will be encrypted. (Enables or disables encryption for traffic that matches these conditions.)1
1 You specify conditions using an IP access list designated by either a number or a name. The access-list command designates a numbered access list; the ip access-list extended command designates a named access list.
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 Cisco IOS 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.)
Caution
Note
Note
About Crypto Maps
Crypto maps are used to specify which DES encryption algorithm(s) will be used in conjunction with each access list defined in the previous step. Crypto maps are also used to identify which peer routers will provide the remote end encryption services.
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.
Defining Crypto Maps
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.
Note
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 Cisco IOS Security Command Reference.
Applying Crypto Maps to Interfaces
This step puts into effect the crypto maps just defined. You must apply exactly one crypto map set to each interface (physical 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:
Backing Up Your Configuration
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 Cisco IOS Configuration Fundamentals Configuration Guide.
Configuring Encryption with GRE Tunnels
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 "Configuring 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 "Configuring Encryption with GRE Tunnels Examples" later in this chapter.
Encrypting Only GRE Tunnel Traffic
To encrypt only traffic through the GRE tunnel, follow these two additional instructions:
•
•
Remember to apply a crypto map to the physical interface and tunnel interface at both ends of the GRE tunnel.
Encrypting GRE Tunnel Traffic and Other Traffic
To encrypt both GRE tunnel traffic and other specified non-GRE tunnel traffic, follow these three additional instructions:
•
–
–
•
–
–
•
Remember to apply a crypto map set to the physical interface and tunnel interface at both ends of the GRE tunnel.
Configuring Encryption with an ESA in a VIP2
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 "Configuring 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:
2.
Note
For examples of ESA-specific configuration tasks, see the section "ESA-Specific Encryption Configuration Task Examples" later in this chapter.
Resetting the ESA
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:
•
•
Router (config)# crypto key zeroize dss slot
Clears the ESA. (This deletes all DSS keys for the ESA.)
Performing Additional Encryption Configuration
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 "Configuring Encryption" for descriptions of the tasks):
•
•
•
As always, remember to back up your configuration when you are done.
Configuring Encryption with an ESA in a Cisco 7200 Series Router
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 "Configuring Encryption."
This section describes configuration for an ESA plugged into a Cisco 7200 series router.
For examples of ESA-specific configuration tasks, see the "ESA-Specific Encryption Configuration Task Examples" section later in this chapter.
Required Tasks
Complete the following tasks in this order (see following sections for descriptions):
2.
Note
Optional Tasks
You can optionally complete these additional tasks (see following sections for descriptions):
•
•
Resetting the ESA
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:
•
Router (config)# crypto card clear-latch slot
Resets the ESA by clearing the ESA hardware latch. When prompted, creates a new password for the ESA.
•
•
Note
•
Router (config)# crypto key zeroize dss slot
Clears the ESA. (This deletes all DSS keys for the ESA.)
Performing Additional Encryption Configuration
After you reset the ESA in a Cisco 7200 series router, continue configuring encryption by following the instructions in one of the following bullets:
•
•
–
–
After you generate and exchange DSS keys for the ESA crypto engine, enable the ESA as described in the next section, "Enabling the ESA."
•
–
–
–
–
Enabling the ESA
Enable an ESA in a Cisco 7200 series router by using the following command in global configuration mode:
Note
As always, remember to back up your configuration when you are done.
Selecting a Crypto Engine
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.
Note
Selecting the Cisco IOS 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.)
Caution
Select the Cisco IOS crypto engine by using the following command in global configuration mode:
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.
Selecting the ESA Crypto Engine
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.
Caution
Select the ESA crypto engine by using the following command in global configuration mode:
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.
Deleting DSS Keys
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:
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.
Customizing Encryption (Configuring Options)
This section describes options that you can configure to customize encryption on a router:
•
•
•
Defining Time Duration of Encrypted Sessions
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:
Shortening Session Setup Times by Pregenerating DH Numbers
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:
Changing Encryption Access List Limits
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.
Why Do These Limits Exist?
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.
When Should the Limits Be Changed?
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.
How Much Memory Is Preallocated If the Limits Are Changed?
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 sourcesFor 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 bytesHow Are the Limits Changed?
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:
Note
For an example of changing these values, see the section "Changing Encryption Access List Limits Example" later in this chapter.
Turning Off Encryption
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
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:
Router (config)# crypto key zeroize dss [slot]1
Deletes DSS keys for a crypto engine.
1 Only 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 "Deleting DSS Keys" earlier in this chapter.
Testing and Troubleshooting Encryption
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:
•
•
•
Testing the Encryption Configuration
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:
An example at the end of this chapter explains how to interpret the show crypto cisco connections command output.
Diagnosing Connection Problems
If you need to verify the state of a connection, you can use the following commands in privileged EXEC mode:
Diagnosing Other Miscellaneous Problems
When using encryption, you might encounter some of these problems:
•
•
•
Dropped Packets
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 "Defining 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.
Difficulty Establishing Telnet Sessions
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.
Invalid DSS Public/Private Keys
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 "Configuring Encryption."
ESA Crypto Engine Not Active
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 engineYou 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 sections "Configuring Encryption with an ESA in a VIP2" or "Configuring 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.
Password Requested When You Generate DSS Keys
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.
•
•
Select the Cisco IOS crypto engine by using the following command in global configuration mode:
•
Router Hanging
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.
Using Debug Commands
Debug commands are also available to assist in problem solving. These commands are documented in the Cisco IOS Debug Command Reference.
Encryption Configuration Examples
The following sections provide examples of configuring and testing your router for CET:
•
•
•
•
•
•
•
Generating DSS Public/Private Keys Example
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
Apricot(config)# crypto key generate dss ApricotGenerating DSS keys .... [OK]Apricot(config)#Banana
Banana(config)# crypto key generate dss BananaIOS 4Generating DSS keys .... [OK]Banana(config)# crypto key generate dss BananaESA 2% Initialize the crypto card password. You will needthis password in order to generate new signaturekeys 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.
Exchanging DSS Public Keys Example
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 (PASSIVE)
Banana(config)# crypto key exchange dss passiveEnter 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 (ACTIVE)
Apricot(config)# crypto key exchange dss 192.168.114.68 ApricotPublic key for Apricot:Serial Number 01461300Fingerprint 0F1D 373F 2FC1 872C D5D7Wait 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:
Banana (PASSIVE)
Public key for Apricot:Serial Number 01461300Fingerprint 0F1D 373F 2FC1 872C D5D7Add this public key to the configuration? [yes/no]: yNow 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]: nBananaESA? [yes]: <Return>Public key for BananaESA:Serial Number 01579312Fingerprint BF1F 9EAC B17E F2A1 BA77Banana(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.
Apricot (ACTIVE):
Public key for BananaESA:Serial Number 01579312Fingerprint BF1F 9EAC B17E F2A1 BA77Add this public key to the configuration? [yes/no]: yApricot(config)#ACTIVE accepts Apricot's DSS public key. Both administrators hang up the phone and the key exchange is complete.
Figure 29 shows complete screens of the two routers. The steps are numbered on the figure to show the sequence of the entire exchange.
Figure 29 DSS Public Key Exchange (Numbers Indicate Sequence of Events)
Enabling DES Encryption Algorithms Example
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 in global configuration mode.
Apricot
crypto cisco algorithm des cfb-8crypto cisco algorithm 40-bit-des cfb-8Banana
crypto cisco algorithm des cfb-8crypto cisco algorithm des cfb-64crypto cisco algorithm 40-bit-des cfb-8Setting Up Encryption Access Lists, Defining Crypto Maps, and Applying Crypto Maps to Interfaces Examples
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.
Example 1
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 30 shows the network topology.
Figure 30 Example 1 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
Apricot(config)#access-list 101 permit tcp 192.168.3.0 0.0.0.15 host 192.168.15.6Apricot(config)# crypto map Research 10Apricot(config-crypto-map)# set peer BananaESAApricot(config-crypto-map)# set algorithm des cfb-8Apricot(config-crypto-map)# match address 101Apricot(config-crypto-map)# exitApricot(config)# interface s0Apricot(config-if)# crypto map ResearchApricot(config-if)# exitApricot(config)#Banana
Banana(config)#access-list 110 permit tcp host 192.168.15.6 192.168.3.0 0.0.0.15Banana(config)# crypto map Rsrch 10Banana(config-crypto-map)# set peer ApricotBanana(config-crypto-map)# set algorithm des cfb-8Banana(config-crypto-map)# set algorithm des cfb-64Banana(config-crypto-map)# match address 110Banana(config-crypto-map)# exitBanana(config)# interface s3/0/2Banana(config-if)# crypto map RsrchBanana(config-if)# exitBanana(config)#Because Banana sets two DES algorithms for crypto map Rsrch, Banana could use either algorithm with traffic on the S3/0/2 interface. However, because Apricot only sets 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.
Example 2
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 31 shows the network topology used in this example.
Figure 31 Example 2 Network Topology
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
Apricot(config)#access-list 105 permit tcp 192.168.3.0 0.0.0.15 192.168.204.0 0.0.0.255Apricot(config)#access-list 105 permit udp 192.168.3.0 0.0.0.15 192.168.204.0 0.0.0.255Apricot(config)#access-list 106 permit tcp 192.168.3.0 0.0.0.15 192.168.15.0 0.0.0.255Apricot(config)#access-list 106 permit udp 192.168.3.0 0.0.0.15 192.168.15.0 0.0.0.255Apricot(config)# crypto map TXandNY 10Apricot(config-crypto-map)# set peer BananaESA.TXbranchApricot(config-crypto-map)# set algorithm 40-bit-des cfb-8Apricot(config-crypto-map)# match address 105Apricot(config-crypto-map)# exitApricot(config)# crypto map TXandNY 20Apricot(config-crypto-map)# set peer CantaloupeIOS.NYApricot(config-crypto-map)# set algorithm 40-bit-des cfb-64Apricot(config-crypto-map)# match address 106Apricot(config-crypto-map)# exitApricot(config)# interface s1Apricot(config-if)# crypto map TXandNYApricot(config-if)# exitApricot(config)#Banana
Banana(config)#access-list 110 permit tcp 192.168.204.0 0.0.0.255 192.168.3.0 0.0.0.15Banana(config)#access-list 110 permit udp 192.168.204.0 0.0.0.255 192.168.3.0 0.0.0.15Banana(config)#access-list 120 permit tcp 192.168.204.0 0.0.0.255 192.168.15.0 0.0.0.255Banana(config)#access-list 120 permit udp 192.168.204.0 0.0.0.255 192.168.15.0 0.0.0.255Banana(config)# crypto map USA 10Banana(config-crypto-map)# set peer Apricot.TokyoBranchBanana(config-crypto-map)# set algorithm 40-bit-des cfb-8Banana(config-crypto-map)# match address 110Banana(config-crypto-map)# exitBanana(config)# crypto map USA 20Banana(config-crypto-map)# set peer CantaloupeIOS.NYBanana(config-crypto-map)# set algorithm des cfb-64Banana(config-crypto-map)# match address 120Banana(config-crypto-map)# exitBanana(config)# interface s2/1/2Banana(config-if)# crypto map USABanana(config-if)# exitBanana(config)#Cantaloupe
Cantaloupe(config)#access-list 101 permit tcp 192.168.15.0 0.0.0.255 192.168.3.0 0.0.0.15Cantaloupe(config)#access-list 101 permit udp 192.168.15.0 0.0.0.255 192.168.3.0 0.0.0.15Cantaloupe(config)#access-list 102 permit tcp 192.168.15.0 0.0.0.255 192.168.204.0 0.0.0.255Cantaloupe(config)#access-list 102 permit udp 192.168.15.0 0.0.0.255 192.168.204.0 0.0.0.255Cantaloupe(config)# crypto map satellites 10Cantaloupe(config-crypto-map)# set peer Apricot.TokyoBranchCantaloupe(config-crypto-map)# set algorithm 40-bit-des cfb-64Cantaloupe(config-crypto-map)# match address 101Cantaloupe(config-crypto-map)# exitCantaloupe(config)# crypto map satellites 20Cantaloupe(config-crypto-map)# set peer BananaESA.TXbranchCantaloupe(config-crypto-map)# set algorithm des cfb-64Cantaloupe(config-crypto-map)# match address 102Cantaloupe(config-crypto-map)# exitCantaloupe(config)# interface s3/1Cantaloupe(config-if)# crypto map satellitesCantaloupe(config-if)# exitCantaloupe(config)#The previous configurations will result in DES encryption algorithms being applied to encrypted IP traffic as shown in Figure 32.
Figure 32 Example 2 DES Encryption Algorithms
Changing Encryption Access List Limits Example
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 effectApricot(config)# crypto cisco entities 5%Please reboot for the new table size to take effectEven 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.
Configuring Encryption with GRE Tunnels Examples
There are two example configurations for encryption with GRE tunnels:
•
•
Example of Encrypting Only GRE Tunnel Traffic
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.)
Apricot
crypto map BananaMap 10set algorithm 40-bit-desset peer Bananamatch address 101!interface Tunnel0no ip addressipx network 923FA800tunnel source 10.1.1.2tunnel destination 10.1.1.1crypto map BananaMap!interface Serial0ip address 10.1.1.2 255.255.255.0crypto map BananaMap!access-list 101 permit gre host 10.1.1.2 host 10.1.1.1Banana
crypto map ApricotMap 10set algorithm 40-bit-desset peer Apricotmatch address 102!interface Tunnel0no ip addressipx network 923FA800tunnel source 10.1.1.1tunnel destination 10.1.1.2crypto map ApricotMap!interface Serial0ip address 10.1.1.1 255.255.255.0clockrate 2000000no cdp enablecrypto map ApricotMap!access-list 102 permit gre host 10.1.1.1 host 10.1.1.2Example of Encrypting Both GRE Tunnel Traffic and Other Non-GRE Traffic
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.)
Apricot
crypto map BananaMapTunnel 10set algorithm 40-bit-desset peer Bananamatch address 101!crypto map BananaMapSerial 10set algorithm 40-bit-desset peer Bananamatch address 101crypto map BananaMapSerial 20set algorithm 40-bit-desset peer Bananamatch address 110!interface Tunnel0no ip addressipx network 923FA800tunnel source 10.1.1.2tunnel destination 10.1.1.1crypto map BananaMapTunnel!interface Serial0ip address 10.1.1.2 255.255.255.0crypto map BananaMapSerial!access-list 101 permit gre host 10.1.1.2 host 10.1.1.1access-list 110 permit tcp host 172.16.25.3 host 192.168.3.5Banana
crypto map ApricotMapTunnel 10set algorithm 40-bit-desset peer Apricotmatch address 102!crypto map ApricotMapSerial 10set algorithm 40-bit-desset peer Apricotmatch address 102crypto map ApricotMapSerial 20set algorithm 40-bit-desset peer Apricotmatch address 112!interface Tunnel0no ip addressipx network 923FA800tunnel source 10.1.1.1tunnel destination 10.1.1.2crypto map ApricotMapTunnel!interface Serial0ip address 10.1.1.1 255.255.255.0clockrate 2000000no cdp enablecrypto map ApricotMapSerial!access-list 102 permit gre host 10.1.1.1 host 10.1.1.2access-list 112 permit tcp host 192.168.3.5 host 172.16.25.3ESA-Specific Encryption Configuration Task Examples
This section includes examples of the following:
•
•
Examples of Resetting an ESA
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]: noESA in slot 2 not enabled.[OK]Apricot(config)#Example of Enabling an ESA (Cisco 7200 Series Routers Only)
The following example enables an ESA in the router chassis slot 2:
Apricot(config)# crypto card enable 2...switching to HW crypto engineApricot(config)#Examples of Selecting a Different Crypto Engine (Cisco 7200 Series Routers Only)
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 engineApricot(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 engineApricot(config)#Deleting DSS Keys Example
This section includes an example for a Cisco 7500 series router and an example for a Cisco 7200 series router with an installed ESA.
Example for a Cisco 7500 Series Router
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 3Warning! Zeroize will remove your DSS signature keys.Do you want to continue? [yes/no]: yKeys 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 4Warning! Zeroize will remove your DSS signature keys.Do you want to continue? [yes/no]: yKeys to be removed are named Apricot.VIP.Do you really want to remove these keys? [yes/no]: y[OK]Apricot(config)#Example for a Cisco 7200 Series Router
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.
Apricot# show crypto key mypubkey dsscrypto key pubkey-chain dss Apricot.IOS 01709642BDD99A6E EEE53D30 BC0BFAE6 948C40FB 713510CB 32104137 91B06C8D C2D5B422D9C154CA 00CDE99B 425DB9FD FE3162F1 1E5866AF CF66DD33 677259FF E5C24812quitcrypto key pubkey-chain dss Apricot.ESA 01234567866AFCF6 E99B425D FDFE3162 BC0BFAE6 13791B06 713510CB 4CA00CDE 0BC0BFAE3791B06C 154C0CDE F11E5866 AE6948C4 DD336772 3F66DF33 355459FF 2350912DquitApricot#This output shows that DSS keys exist for both the Cisco IOS crypto engine and for the ESA crypto engine.
2.
Apricot# show crypto engine configurationengine name: Apricot.IOSengine type: softwareserial number: 01709642platform: rsp crypto engineEncryption Process Info:input queue top: 44input queue bot: 44input queue count: 0Apricot#The output shows that the Cisco IOS crypto engine is the active engine.
3.
Apricot# config terminalEnter configuration commands, one per line. End with CNTL/Z.Apricot(config)# crypto card enable 2...switching to HW crypto engineApricot(config)#4.
Apricot(config)# exitApricot# show crypto engine configurationengine name: Apricot.ESAengine type: hardwareserial number: 01234567platform: esa crypto engineEncryption Process Info:input queue top: 0input queue bot: 0input queue count: 0Apricot#The output shows that the ESA crypto engine is now the active engine.
5.
Apricot# config terminalEnter configuration commands, one per line. End with CNTL/Z.Apricot(config)# crypto key zeroize dss 2Warning! Zeroize will remove your DSS signature keys.Do you want to continue? [yes/no]: yKeys to be removed are named Apricot.ESA.Do you really want to remove these keys? [yes/no]: y[OK]Apricot(config)#6.
Apricot(config)# exitApricot# show crypto key mypubkey dsscrypto key pubkey-chain dss Apricot.IOS 01709642BDD99A6E EEE53D30 BC0BFAE6 948C40FB 713510CB 32104137 91B06C8D C2D5B422D9C154CA 00CDE99B 425DB9FD FE3162F1 1E5866AF CF66DD33 677259FF E5C24812quitApricot#The output shows that the ESA crypto engine keys have been deleted.
7.
Apricot# show crypto engine configurationengine name: Apricot.IOSengine type: softwareserial number: 01709642platform: rsp crypto engineEncryption Process Info:input queue top: 0input queue bot: 0i nput queue count: 0Apricot#The output shows that the system has defaulted back to the Cisco IOS crypto engine as the active engine.
Testing the Encryption Connection Example
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 31. 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
Apricot# test crypto initiate-session 192.168.3.12 192.168.204.110 BananaESA.TXbranch 10Sending CIM to: 192.168.204.110 from: 192.168.3.12.Connection id: -1Notice the Connection id value is -1. A negative value indicates that the connection is being set up.
Step 2
Apricot# show crypto cisco connectionsPending Connection TablePE UPE Timestamp Conn_id192.168.3.10 192.168.204.100 Mar 01 1993 00:01:09 -1Connection TablePE UPE Conn_id New_id Alg Time192.168.3.10 192.168.204.100 -1 1 0 Not Setflags:PEND_CONNLook 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
Step 4
(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# show crypto cisco connectionsConnection TablePE UPE Conn_id New_id Alg Time192.168.3.10 192.168.204.100 1 0 0 Mar 01 1993 00:02:00flags:TIME_KEYSAgain, 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 Cisco IOS Security Command Reference. There you can find a description of how connection IDs are assigned during and following connection setup.
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2007 Cisco Systems, Inc. All rights reserved.
Feedback