Worldwide [change] |Account |Register |About Cisco
Guest

Hierarchical Navigation

Cisco Catalyst 5000 Series Switches

Data Encryption Service Adapter

Downloads


Table of Contents

Catalyst 5000 Series Route Switch Module Data Encryption Service Adapter Installation and Configuration Note
 Contents
 Data Encryption Overview
 Compliance with U.S. Export Laws and Regulations Regarding Encryption
 What Is the Data ESA?
 Installation Prerequisites for the ESA
 Safety Guidelines
 Installing or Replacing a Catalyst VIP2-40-Based Service Adapter
 Data Encryption Configuration Fundamentals and Sample Configurations
 Issues to Consider Before Configuring Encryption/Authentication
 Using the show diagbus Command to Verify ESA Installation
 Essential Encryption/Authentication Configuration Tasks
 Optional Encryption/Authentication Configuration Tasks
 Testing and Troubleshooting Encryption/Authentication
 Encryption/Authentication Configuration Examples
 Related Documentation
 Cisco Connection Online
 Documentation CD-ROM

Catalyst 5000 Series Route Switch Module Data Encryption Service Adapter Installation and Configuration Note

Product Numbers: SA-Encrypt and SA-Encrypt(=)

Note      If you ordered this port adapter as a spare, Cisco has included a port adapter installation and configuration note for the Cisco 7500 series router with the Versatile Interface Processor 2 (VIP2) and the Cisco 7200 series router. Your port adapter is fully compatible with these routers.

This configuration note describes the installation and configuration of the data encryption service adapters (ESAs), which are referred to throughout this publication collectively as ESA (Product Numbers SA-Encrypt and SA-Encrypt=). The specific Catalyst VIP2 model required by the ESA is the Catalyst VIP2-40. The CSA is used in the Catalyst VIP2-40 module which is attached to the Route Switch Module (RSM) and used in the Catalyst 5000 series switches. The CSA can also be used in the following:

  • Cisco 7204 and Cisco 7206 routers
  • The VIP2-40 in all Cisco 7500 series routers, and on the VIP2-40 in Cisco 7000 series routers with the 7000 series Route Switch Processor (RSP7000) and 7000 series Chassis Interface (RSP7000CI) installed

Use this configuration note with the Route Switch Module Catalyst VIP2-15 and VIP2-40 Installation and Configuration Note (Document Number 78-4780-01), which shipped with your Catalyst VIP2-15 and Catalyst VIP2-40.

To ensure compliance with U.S. export laws and regulations for 56-bit Data Encryption Standard (DES), and to prevent future problems, see the "Compliance with U.S. Export Laws and Regulations Regarding Encryption" section on page 6.

Contents

This configuration note includes the following sections:

Data Encryption Overview

Network data encryption and router authentication can safeguard network data that travels from one Cisco router to another, across unsecured networks. Safeguarding network data has become increasingly important to many organizations as they extend or replace private networks with public, unprotected networks. For example, many organizations are using the Internet as a economical way to replace leased-line services.

Data that traverses unsecured network lines is open to many types of attack. 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 effective communications within your organization. You can minimize the vulnerability of your network data by configuring your router for network data encryption with router authentication.

Data encryption can transform intelligible information, called clear text, into an unintelligible form, called cipher text, to provide secure data and information exchanges. Data encryption is the best available data-security technique. Encryption converts data into meaningless data, converted in a manner that allows it to be reconverted into meaningful data. Data encryption assures that data sent over unsecure networks cannot be interrupted or intercepted in a readable form.

Encryption involves the use of an algorithm plus an encryption key. Different algorithms exist, each with its strengths and weaknesses, and each imposes restrictions on the minimum and maximum size of the encryption key. Encryption keys are simply large numbers used to convert the clear text into cipher text. The larger the encryption key, the more secure the data. Encryption can be applied at different levels of the protocol stack to protect against different forms of attack (for example, data protection or traffic analysis) and to allow passage through different types of networking equipment.

Encryption converts data so that recognizable patterns are removed. For example, in a simple electronic (e-mail) message, at least 70 percent of the message consists of white space. The encryption mechanism chosen must guarantee that all of the message is converted so that patterns of data cannot be interpreted. Successive white-space must be converted into different data. There can be no distinction between words or phrases that would give an attacker a clue as to the type of traffic being transmitted. Any hint of a pattern would greatly diminish the security of the data.

The secure network must allow for signatures that positively identify the parties involved. This signature must be irrevocable. No part should be able to emulate another and no party should be able to deny sending a message after the fact. No network is 100-percent secure. The encryption mechanism simply raises the cost of decrypting and acquiring the data.

Methods of Attack

Following are some of the methods of attack:

  • Brute-force attack—An intruder tries all possible combinations of a key.
  • Intruder-in-the-middle attack—An intruder sits between two hosts and intercepts the traffic.
  • Denial-of-service attack—An intruder attempts to hinder or reduce the amount of data going to and from the secure network; however, this is more detrimental to network productivity than security.
  • Replay attack—An intruder attempts to reintroduce a decipher key time after time, hoping to hit on the repeated use of this key by the secure network.
  • Network address spoofing—An intruder looks for and finds the source and destination address pairs that are allowed into a particular secure network; this form of attack attempts to break access control restrictions.

In general, true data security should provide the following:

  • Data encryption to deny access of the data to unauthorized sites or users
  • A block to prevent the intruder-in-the-middle form of attack
  • A block to prevent someone from masquerading as one of the trusted sites
  • A signature to guarantee that the sender is real and authorized
  • A signature to guarantee that the sender did in fact send the data and cannot later deny it
  • Reduction and/or elimination of the denial-of-service attack
  • Dynamic session key generation, which forces the intruder to periodically decipher the new key
  • Access controls to deny access to unauthorized sites or users

Levels of Encryption

Following are descriptions of the levels of data encryption:

  • Link-level encryption (Layer 2 and 3)

Link-level encryption provides extra protection by encrypting nearly all of the datagram. This includes the protocol header(s). The only portion of the datagram not encrypted is the link-level information. This method protects the protocol information as well as the data, and prevents a listener from obtaining information about an internal corporate network's structure. While link-level encryption allows no traffic analysis (a form of attack), it must encrypt/decrypt on every hop and every path.

  • Protocol-level encryption (Layer 3 and 4)

Protocol encryption forces the protocol data to be encrypted and leaves the protocol and link headers in the clear. This method assumes that the protocol data is sensitive, but no concern is given to the protocol headers' traffic analysis. While protocol-level encryption requires you to encrypt/decrypt data only once, and it encrypts/decrypts only those sessions that need it, headers are sent as clear text, which can allow for traffic analysis.

  • Application encryption (Layer 5 and above)

Application encryption is based on a particular application and requires that the application be modified to incorporate encryption.

Public-Key Technology

Public-Key (PK) technology operates on a pair of keys. One key is used for encryption and the other for decryption. Whichever key is used for encryption, only the other key can be used to decrypt the data. This is an asymmetric mechanism. Each key in the pair is a one-way encryption mechanism. The same key cannot be used to decrypt the message. Signing a document is fundamental to PK technology.

A signature must have the following properties:

  • Must be unforgettable.
  • Must be authenticated so that it convinces the document's recipient that the signer deliberately signed the document.
  • Must not be reusable, and should be part of the document so that another person cannot move it to a different document.
  • A signed document must be unalterable.
  • Cannot be repudiated, so that once signed and sent, the sender cannot later deny sending the message.

This signature verification mechanism is used to establish a secure connection with a remote host for the purpose of sending encrypted traffic using a more efficient encryption mechanism.

DES is an efficient mechanism for passing long strings of encrypted data. Unfortunately, you cannot use DES to authenticate the participating stations. The two mechanisms (PK and DES) are combined to create an encrypted and authenticated session between two hosts.

DES is a symmetric encryption mechanism. A single encryption key (called a session key) is used to both encrypt and decrypt the data. This key must be generated by the participating routers, without sending any meaningful data to each other, which might lead a third party (an intruder) into generating the same key value.

Securing Networks

Following are the parts essential to network security:

  • Authenticating routers—A secure network must begin with trusted security devices. To eliminate the intruder-in-the-middle attack, every encryption device in the network must be authenticated to every network device to which it will send encrypted data.
  • Setting encryption policies—Includes a declaration to networks that are to be encrypted and provision for time limits on encrypted sessions.
  • Establishing a connection setup—Provides secure connections that are as immune as possible to the effects of attackers listening in.
  • Using secure encryption keys—Defines the types of encryption to use over a secure network.

Compliance with U.S. Export Laws and Regulations Regarding Encryption

This product performs encryption and is regulated for export by the U.S. Government. Specific information follows regarding compliance with U.S. export laws and regulations for encryption products:

  • This product is not authorized for use by persons located outside the United States and Canada who do not have export license authority from the U.S. Government.
  • This product may not be exported outside the United States and Canada either by physical or electronic means without the prior written approval of the U.S. Government.
  • Persons outside the United States and Canada may not reexport, resell, or transfer this product by either physical or electronic means without prior written approval of the U.S. Government.

What Is the Data ESA?

The ESA (see Figure 1) provides the hardware-based encryption mechanisms required to perform data encryption in Cisco 7000 family routers and the RSM/VIP2 in which ESA is installed. The product number is SA-Encrypt(=), and the ESA uses a 40-bit or 56-bit Data Encryption Standard (DES), which is configurable via the Cisco IOS crypto engine (also called the software [SW] crypto engine).

The ESA provides data encryption mechanisms using PK technology based on the concept of the Protected Entity (PE), and employing the Data Encryption Standard (DES) and the Digital Signature Standard (DSS), to ensure secure data and information can be transferred between similarly equipped hosts on your network.


Figure 1   SA-Encrypt Service Adapter (Service Adapter Shown without Handle)


Service and Port Adapter Locations in the Catalyst VIP2

The ESA can be installed in port adapter slot 0 or slot 1 on the Catalyst VIP2-40; Figure 2 shows a Catalyst VIP2 with a port adapter in slot 0 and a service adapter in slot 1.

You must install a specific type of port adapter in the Catalyst VIP2-40 port adapter slot adjacent to the ESA. For specific information about the port adapters that can be used on the Catalyst VIP2-40 with an ESA, see the "Hardware, Software, and Compliance Prerequisites" section on page 9.


Figure 2   Port Adapters on the Catalyst VIP2


ESA LEDs

The ESA contains the ENABLED LED, standard on all service adapters, and four status LEDs. After system initialization, the ENABLED LED goes on to indicate that the host is enabled for operation. (The LEDs are shown in Figure 3.)


Figure 3   LEDs on the ESA (Partial Faceplate View)


The following conditions must be met before the ENABLED LED goes on:

  • The data encryption interface correctly connects to the backplane and receives power
  • The data-encryption-equipped Catalyst VIP2-40 contains a successfully downloaded, valid microcode version, and the bus recognizes the data-encryption-equipped Catalyst VIP2-40

If any of these conditions is not met, or if the router initialization fails for other reasons, the ENABLED LED does not go on.

In addition to the ENABLED LED, the ESA has the following four LED indications:

  • BOOT—This green LED is on to indicate the service adapter is booting itself, and remains on while the service adapter is in the boot process and goes off when the service adapter's boot process is complete. It is normally off.
  • ACTIVE—This green LED is on to indicate the ESA is ready for operation, and goes on when the service adapter's boot process is complete and the boot LED goes off. It is normally on.
  • ERROR—This amber LED goes on to indicate that an error was found, other than tampering, and if it remains on, it indicates the error might prevent accurate encryption. Error codes are generated by software. It is normally off.
  • TAMPERED/EXTRACTED—This amber LED goes on to indicate that either the tamper switch or the extraction switch has been activated, which means that someone attempted to remove or has extracted and replaced the ESA or has removed the tamper shield. It is normally off.

Note      The TAMPERED/EXTRACTED LED goes on and stays on if the ESA is tampered with or extraction is attempted. After extracting the service adapter and replacing it, turn off the TAMPERED/EXTRACTED LED by entering the appropriate password and the configuration command crypto clear-latch slot, where slot is the chassis slot in which the ESA is installed.

If the ESA was tampered with, the crypto clear-latch slot command will not turn off the tampered/extracted LED; use the crypto zeroize slot command instead, where slot is the chassis slot in which the ESA is installed.

If you do not know the password, you can enter the configuration command crypto zeroize slot, which removes the keys and turns off the tampered/extracted LED. You must then generate new keys for the ESA.

To determine the chassis slot in which you install an ESA, use the show crypto card command, as follows:

Router# show crypto card
Crypto card in slot: 2
Tampered: No
Xtracted: Yes
Password set: Yes
DSS Key set: No
FW version 0x5049702

Installation Prerequisites for the ESA

This section provides important hardware, software, and compliance prerequisites that we recommend you read and carefully observe, a list of parts and tools you need to perform the installation, and safety and electrostatic discharge (ESD)-prevention guidelines to help you avoid injury and prevent damage to the equipment.

Note      If tampered with, the service adapter is designed to erase all internal information. All encryption keys are stored in memory and backed up with a battery. If the card is tampered with, the memory is pulled to ground, which erases all memory and renders the service adapter useless. Further, the battery that powers memory is external to the tamper-proof shielding. If the battery is removed, memory is erased. If the service adapter is extracted from an installed system, an internal latch is set to indicate extraction. The service adapter is unusable, and the system administrator has to clear the latch with the appropriate password.

There is the danger of explosion if the battery is replaced incorrectly. Replace the battery only with the same or equivalent type recommended by the manufacturer. Dispose of used batteries according to the manufacturer's instructions.

Hardware, Software, and Compliance Prerequisites

This section lists hardware, software, and compliance prerequisites.

  • The ESA requires that the host RSM runs Cisco IOS Release 11.2(14)P or later and that the supervisor engine runs Catalyst 5000 series supervisor engine software release 2.3(1) or later.
  • The specific Catalyst VIP2 model required for the ESA is Catalyst VIP2-40, which has 2-MB SRAM and 32-MB DRAM.
  • You must install the appropriate port adapter in the Catalyst VIP2-40 port adapter slot adjacent to the ESA.
  • Most of the currently available port adapters that are compatible with the Catalyst VIP2-40 can be installed on a Catalyst VIP2-40 alongside an ESA performing hardware encryption. However, the following port adapters cannot be used with hardware encryption via the ESA, unless otherwise noted:
    • PA-4T synchronous serial port adapter
    • PA-4T+ synchronous serial port adapter

This port adapter is not compatible when X.25 or SMDS are configured.

This port adapter is compatible when PPP, HDLC, or Frame Relay are configured.

    • PA-H HSSI port adapter

This port adapter is not compatible when X.25 or SMDS are configured.

This port adapter is compatible when PPP, HDLC, or Frame Relay are configured.

    • PA-8B-ST, PA-4B-U basic rate interface (BRI) port adapters
    • PA-2CE1/PRI-75, PA-2CE1/PRI-120, PA-2CT1/PRI channelized E1 and channelized T1 port adapters that can also be configured as Primary Rate Interface port adapters

These port adapters are not compatible when in channelized mode and X.25 or SMDS is configured.

These port adapters are not compatible when in PRI mode and PPP or HDLC is configured.

These port adapters are compatible when in channelized mode and PPP, HDLC, or Frame Relay is configured.

    • CT3IP-20 channelized T3 interface processor (in the same chassis as the ESA)
  • Either the distributed switching (DSW) feature or NetFlow switching feature is required on the source and destination, encrypting/decrypting interfaces.

Note      If distributed switching is on, every IP packet on the Catalyst VIP2-40 goes through a crypto map check. If Netflow switching is on, the flow cache is used, and the only packets affected by the crypto map check are those for which no flow cache entry exists. For information on enabling and configuring the NetFlow switching feature, refer to the Network Protocols Configuration Guide,
Part 1 (in the "Configuring IP" chapter) and in the Network Protocols Command Reference (in the "IP Commands" chapter). These publications are available on the Documentation CD-ROM and as printed copies.

  • Cisco IOS software does not support IP fragmentation for software (SW) and hardware (HW) encryption on the Catalyst VIP2-40.

List of Parts and Tools

You need some combination of the following tools and parts to install a service adapter on a
Catalyst VIP2-40. If you need additional equipment, contact a service representative for ordering information.

  • SA-Encrypt(=), data encryption service adapter (ESA)
  • Cisco IOS Release 11.2(14)P or later, loaded on your RSM
  • Catalyst VIP2-40(=) and one Catalyst VIP2-40-compatible port adapter in the adjacent port adapter slot on the Catalyst VIP2-40

For specific port adapter prerequisites for the Catalyst VIP2-40 and ESA, see the "Hardware, Software, and Compliance Prerequisites" section on page 9

  • A number 1 Phillips and a 3/16-inch, flat-blade screwdriver
  • Your own ESD-prevention equipment or the disposable grounding wrist strap included with all upgrade kits, field-replaceable units (FRUs), and spares

Safety Guidelines

Follow the safety guidelines in this section when working with any equipment that connects to electrical power or telephone wiring.

Safety Warnings

Safety warnings appear throughout this publication in procedures that, if performed incorrectly, might harm you. A warning symbol precedes each warning statement.

Warning    This warning symbol means danger. You are in a situation that could cause bodily injury. Before you work on any equipment, be aware of the hazards involved with electrical circuitry and be familiar with standard practices for preventing accidents. To see translations of the warnings that appear in this publication, refer to the appendix "Translated Safety Warnings" in the Catalyst 5000 Series Installation Guide.

Electrical Equipment Guidelines

Follow these basic guidelines when working with any electrical equipment:

  • Before beginning any procedures requiring access to the chassis interior, locate the emergency power-off switch for the room in which you are working.
  • Disconnect all power and external cables before moving a chassis; do not work alone when potentially hazardous conditions exist.
  • Never assume that power has been disconnected from a circuit; always check.
There is the danger of explosion if the battery is replaced incorrectly. Replace the battery only with the same or equivalent type recommended by the manufacturer. Dispose of used batteries according to the manufacturer's instructions.

Telephone Wiring Guidelines

Use the following guidelines when working with any equipment that is connected to telephone wiring or to other network cabling:

Preventing Electrostatic Discharge Damage

Electrostatic discharge (ESD) damage, which can occur when electronic cards or components are improperly handled, results in complete or intermittent failures. A processor module comprises a printed circuit board that is fixed in a metal carrier. Electromagnetic interference (EMI) shielding, connectors, and a handle are integral components of the carrier. Although the metal carrier helps to protect the board from ESD, use a preventive antistatic strap whenever handling a processor module.

Following are guidelines for preventing ESD damage:

For safety, periodically check the resistance value of the antistatic strap. The measurement should be between 1 and 10 megohms.

Installing or Replacing a Catalyst VIP2-40-Based Service Adapter

This section describes how to install a service adapter.

The steps required to install or replace a service adapter or port adapter on a Catalyst VIP2 are the same. Therefore, the term adapter in this section applies to service adapters as well as port adapters, unless noted otherwise.

Each adapter circuit board mounts to a metal carrier and is sensitive to ESD damage. We strongly recommend that the following procedures be performed by a Cisco-certified service provider; however, this is not a requirement. If a blank adapter is installed on the Catalyst VIP2 in which you want to install a new adapter, you must first remove the RSM/VIP2 from the chassis, and then remove the blank adapter.

To prevent system problems, do not remove adapters from the Catalyst VIP2, or attempt to install other adapters on the Catalyst VIP2 while the system operates. To install or replace adapters, first remove the RSM/VIP2 from the switch.

When only one adapter is installed on a Catalyst VIP2, a blank adapter must fill the empty slot to allow the Catalyst VIP2 and RSM chassis to conform to EMI emissions requirements, and to allow proper airflow through the chassis.

Use this procedure for removing and replacing any type of adapter on the Catalyst VIP2:

Step 1   Attach an ESD-preventive wrist strap between you and an unfinished chassis surface or to the ESD connector on the switch.

Step 2   For a new adapter installation or an adapter replacement, we recommend that you disconnect any interface cables from the front of the adapter.

Step 3   To remove the RSM/VIP2 from the chassis, follow the steps in the "RSM and Catalyst VIP2 Installation" section in the Route Switch Module Catalyst VIP2-15 and VIP2-40 Installation and Configuration Note (Document Number 78-4780-01), which shipped with your Catalyst VIP2.

Step 4   Place the removed RSM/VIP2 on an antistatic mat.

Step 5   Locate the screw at the rear of the adapter (or blank adapter) to be replaced. (See Figure 4.) This screw secures the adapter (or blank adapter) to its slot.


Figure 4   Location of Adapter Screw, Partial Adapter View


Step 6   Remove the screw that secures the adapter (or blank adapter).

Step 7   With the screw removed, grasp the handle on the front of the adapter (or blank adapter) and carefully pull it out of its slot, away from the edge connector at the rear of the slot. (See Figure 5.)


Figure 5   Pulling an Adapter Out of a Slot, Partial Adapter View


Step 8   If you removed a adapter, place it in an antistatic container for safe storage or shipment back to the factory. If you removed a blank adapter, no special handling is required; however, store the blank adapter for potential future use.

Step 9   Remove the new adapter from its antistatic container and position it at the opening of the slot so that the leading edges of the carrier are between upper and lower slot edges. (See Figure 5.)

To prevent jamming the carrier between the upper and lower edges of the adapter slot, and to ensure that the edge connector at the rear of the adapter seats in the connector at the rear of the adapter slot, make certain that the leading edges of the carrier are between the upper and lower slot edges, as shown in Figure 5.

Figure 6   Installing an Adapter


Step 10   Carefully slide the new adapter into the adapter slot until the connector at the rear of the adapter seats in the connector at the rear of the adapter slot.

Step 11   Install the screw in the rear of the adapter slot. (See Figure 4 for its location.) Do not overtighten this screw.

Step 12   To replace the RSM/VIP2 combination in the chassis, follow the steps in the "RSM and Catalyst VIP2 Installation" section in the Route Switch Module Catalyst VIP2-15 and VIP2-40 Installation and Configuration Note (Document Number 78-4780-01), which shipped with your Catalyst VIP2.

Step 13   Reconnect the interface cables to the port adapter ports.

This completes the procedure for installing a new port adapter or replacing a port adapter in a Catalyst VIP2-40.

Data Encryption Configuration Fundamentals and Sample Configurations

The remainder of this configuration note describes how to configure your RSM/VIP2 for network data encryption with router authentication, and includes the following sections:

For a complete description of the commands mentioned in this configuration note, refer to the "Network Data Encryption and Router Authentication Commands" section in the Security Command Reference publication.

Cisco's Network Data Encryption with Router Authentication

To safeguard your network data, Cisco provides network data encryption and router authentication services. Network data encryption is provided at the IP packet level. IP packet encryption prevents eavesdroppers from reading the data that is being transmitted. When IP packet encryption is used, IP packets can be seen during transmission, but the IP packet contents (payload) cannot be read. Specifically, the IP header and upper-layer protocol (TCP or UDP) headers are not encrypted, but all payload data within the TCP or UDP packet is encrypted and therefore not readable during transmission.

The actual encryption and decryption of IP packets occurs only at routers that you configure for network data encryption with router authentication. Such routers are considered to be peer encrypting routers (or simply peer routers). Intermediate hops do not participate in encryption/decryption.

Note      Encryption should not be enabled in the intermediate routers; otherwise, unnecessary encryption/decryption cycles might result in a subsequent reduction in overall system performance.

Typically, when an IP packet is initially generated at a host, it is unencrypted (referred to as clear text). This occurs on a secured (internal) portion of your network. Then when the transmitted IP packet passes through an encrypting router, the router determines if the packet should be encrypted. If the packet is encrypted, the encrypted packet will travel through the unsecured network portion (usually an external network such as the Internet) until it reaches the remote peer encrypting router. At this point, the encrypted IP packet is decrypted, and forwarded to the destination host as clear text.

Router authentication enables peer encrypting routers to positively identify the source of incoming encrypted data. This means that attackers cannot forge transmitted data or tamper with transmitted data without detection. Router authentication occurs between peer routers each time a new encrypted session is established.

An encrypted session is established each time an encrypting router receives an IP packet that should be encrypted (unless an encrypted session is already occurring at that time).

To provide IP packet encryption with router authentication, Cisco implements the following standards: Digital Signature Standard (DSS), the Diffie-Hellman (DH) public key algorithm, and Data Encryption Standard (DES). DSS is used in router authentication. The DH algorithm and DES are used to initiate and conduct encrypted communication sessions between participating routers.

The following sections provide an overview of Cisco's data encryption and router authentication.

Enabling Router Authentication (DSS Key Exchange)

Note      Enter the session mod_num command (mod_num is the RSM slot number) at the Catalyst switch prompt to access the RSM (router> prompt) for router configuration.

Before encrypted communication or router authentication can occur between peer routers, DSS keys (public and private) must be generated. Also, the DSS public keys must be shared and verified (see Figure 7).


Figure 7   Exchanging DSS Keys (Overview)


This process occurs only once, and the DSS keys are used each time an encrypted session occurs after that. The DSS keys are used at the beginning of encrypted sessions to authenticate the peer encrypting router (the source of encrypted data). Each peer router must generate and store two unique DSS keys: a DSS public key and a DSS private key. DSS public and private keys are stored in a private portion of the router's NVRAM, which cannot be viewed with commands such as show configuration, show running-config, or write terminal. 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 router's DSS public key is distributed to all other peer routers. After public keys are sent to peer routers, the routers' administrators must verbally verify to each other the public key's source router (sometimes called voice authentication).

Establishing an Encrypted Session

When a Cisco router wants to send encrypted data to a peer router, it must first establish an encrypted session. (See Figure 8.)

To establish the session, the two peer routers exchange connection messages. These messages have two purposes. The first purpose is to authenticate each router to the other. This is accomplished by attaching signatures to the connection messages. A signature is a character string created by each router using its DSS private key and verified by the other router using the corresponding DSS public key. A signature is always unique to the sending router and cannot be forged by any other device. When a signature is verified, the sending router is authenticated.

The second purpose of the connection messages is to generate a temporary DES key (session key), which will be used to encrypt data during this encrypted session. To generate the DES key, DH numbers must be exchanged in the connection messages. Then, the DH numbers are used to compute a common DES session key shared by both routers.


Figure 8   Establishing an Encrypted Session


Encrypting Data During a Communication Session

When both 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 9.)

Note      The TCP headers and all level-4 headers are sent unencrypted.

An encrypted communication session terminates when the session times out. When the session terminates, both the DH numbers and the DES key are discarded. When you require another encrypted session, new DH numbers and DES keys are generated.


Figure 9   Encrypting Data


Issues to Consider Before Configuring Encryption/Authentication

You should understand the issues explained in this section before attempting to configure your system for network data encryption with router authentication.

Implementation Issues

Note these issues:

If this occurs, the host should wait a short time (a few seconds might be sufficient), and then attempt the Telnet connection again. By this time the encrypted session should be set up, and the Telnet session can be established. Enabling pregeneration of DH numbers (described later in this configuration note) might also help by speeding up encryption session connection setup times.

Peer Router Identification

You must identify all peer routers which will be participating in IP packet encryption/router authentication. These are usually all routers within your administrative control that will be passing classified, confidential, or critical data using IP packets. 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 on a personal level by you, and known and trusted by your organization.

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 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 endpoint peer routers.

Cisco IOS Crypto Engine

A software-controlled crypto engine resides in your router's encryption-capable Cisco IOS software (called a crypto image) and provides encryption/authentication services for all router ports that you specify during configuration. (The Cisco IOS crypto engine governs encryption/authentication for all router ports.)

All Cisco routers have only one Cisco IOS crypto engine that governs all ports, except for Cisco 7000 series routers, Cisco 7500 series routers, and the RSM/VIP2 which can have more than one crypto engine when a VIP2-40 or ESA-equipped VIP2-40 is installed. For these routers, the Cisco IOS crypto engine resides in the Route Switch Processor (RSP) and any second-generation Versatile Interface Processors (VIP2-40s) that are installed.

Use the show version command to verify that you have a Cisco IOS crypto image loaded, as shown for a Cisco 7200 series router, Cisco 7500 series router, and the RSM:

Router# show version
Cisco Internetwork Operating System Software
--> IOS (tm) 7200 Software (C7200-IS56-M), Released Version 11.2(7a)P [biff 1145]
Copyright (c) 1986-1997 by cisco Systems, Inc.
Compiled Wed 19-Feb-97 10:17 by biff
Router# show version
Cisco Internetwork Operating System Software
--> IOS (tm) RSP Software (RSP-ISV56-M), Released Version 11.2(14)P [biff 722]
Copyright (c) 1986-1997 by cisco Systems, Inc.
Compiled Wed 19-Feb-97 16:47 by biff
Router# show version
Cisco Internetwork Operating System Software
IOS (tm) C5RSM Software (C5RSM-JSV-M), Version 11.2(14)P
Copyright (c) 1986-1997 by cisco Systems, Inc.
Compiled Tue 24-Jun-97 17:09 by shj

VIP2 Crypto Engine

Cisco 7500 series routers and Cisco 7000 series routers, with the RSP7000 installed, support the VIP2-40. The VIP2-40 has its own Cisco IOS crypto engine (if a Cisco IOS crypto image is running), which governs the ports on the port adapter that is installed adjacent to the ESA on the VIP2-40.

If you have a VIP2-40 installed in your router, the VIP2 crypto engine will govern the adjacent port adapter's ports, and the Cisco IOS crypto engine on the RSP will govern all remaining router ports. If there is no VIP2-40, the Cisco IOS crypto engine on the RSP will govern all router ports.

If there is an ESA installed on a VIP2-40, the crypto engine will be a hardware (HW) crypto engine, and the encryption/decryption functions will be executed by the ESA. In this case, the show process command will reveal three processes related to the crypto engine.

An example of the show process command follows:

Router# show process
CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0%
PID  QTy PC Runtime (ms) Invoked uSecs Stacks TTY Process
  (additional displayed text omitted from this example)
  21 Hwe 604E8C0C 0 1 0 5608/6000 0 Crypto HW Proc
22 Mwe 604BDD20 0 12168 011596/12000 0 Crypto SM
23 Hwe 607C3A38 0 1 0 5628/6000 0 Encrypt Proc
  (additional displayed text omitted from this example)
Router#

If no ESA and VIP2-40 is installed, the crypto engine will be the Cisco IOS crypto engine, and the encryption/decryption functions will be executed by the RSP and the Cisco IOS crypto image. The show process command will show only two processes related to the Cisco IOS crypto engine.

An example of the show process command follows:

Router# show process
CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0%
PID  QTy PC Runtime (ms) Invoked uSecs Stacks TTY Process
  (additional displayed text omitted from this example)
21 Hwe 604E8C0C 0 1 0 5608/6000 0 Crypto HW Proc
22 Mwe 604BDD20 0 12168 011596/12000 0 Crypto SM
 

Data Encryption Service Adapter Crypto Engine

If you have a Cisco 7000 series or Cisco 7500 series router with an ESA, your router will have an additional crypto engine associated with the ESA, called the hardware (HW) crypto engine.

If you have a Cisco 7200 series router, your router will have either the Cisco IOS crypto engine or the HW crypto engine associated with the ESA.

In the Cisco 7000 and Cisco 7500 series routers, the ESA and a compatible port adapter are attached to a VIP2-40, and the ESA's HW crypto engine provides encryption/authentication services only for ports on the adjoining VIP2-40 port adapter. Most of the currently available port adapters, which are compatible with the VIP2-40, can be installed on a VIP2-40 or in a Cisco 7200 series router with an ESA. (For specific, additional port adapter limitations for VIP2-40 and the Cisco 7200 series, see the "Hardware, Software, and Compliance Prerequisites" section on page 9.)

The Cisco IOS crypto engine will provide encryption/authentication for all remaining ports of your router. The ESA's HW crypto engine can govern the adjoining VIP2-40 port adapter's ports, and the Cisco IOS crypto engine governs all remaining ports in the router. This is also true if distributed switching is not enabled. (During configuration, you must specify which ports will participate in encryption/authentication.)

For Cisco 7200 series routers without an ESA installed, the Cisco IOS crypto engine will govern any port adapter's ports. For Cisco 7200 series routers with an ESA installed, the ESA's HW crypto engine will govern any port adapter's ports.

Configuration Guidelines for the Crypto Engine

For Cisco 7000 series, Cisco 7200 series, Cisco 7500 series routers, or the RSM/VIP2 with an ESA, you need to complete certain configuration tasks for each crypto engine of your router if you want that crypto engine to provide encryption/authentication for the ports it governs. These tasks are to generate DSS keys and to exchange DSS keys. (These tasks are described in the "Essential Encryption/Authentication Configuration Tasks" section on page 23.)

In Cisco 7000 series or 7500 series routers with one or more VIP2-40 and ESA, your router will have multiple crypto engines. When you configure these crypto engines, you must identify them by a chassis slot number. The HW crypto engines are identified by the chassis slot number in which the VIP2-40 and ESA is installed.

A VIP2-40 and RSP will perform encryption/decryption via software (the Cisco IOS crypto engine) if no ESA is installed on the VIP2-40. After you configure a Cisco IOS crypto engine, you can configure any port governed by that SW crypto engine to perform encryption/authentication. Most of the currently available port adapters, which are compatible with the VIP2-40, can be installed on a VIP2-40 alongside an ESA. (For specific, additional port adapter limitations for VIP2-40, see the "Hardware, Software, and Compliance Prerequisites" section on page 9.)

The ESA can be installed in either port adapter slot 0 or 1 on the VIP2-40; however, you must install the appropriate port adapter in the VIP2-40 port adapter slot adjacent to the ESA.

In the Cisco 7200 series, the router has only one active crypto engine. If an ESA is installed, you must identify it by a chassis slot number when you configure the crypto engine. You must also identify the ports that you want to use for encryption/decryption. These ports are identified by the chassis slot number(s) in which the port adapter is installed. After you configure the crypto engine, you can configure any port that is governed by the crypto engine to perform encryption/authentication.

Most currently available port adapters compatible with the Cisco 7200 series can be installed in a Cisco 7200 series router with an ESA. (For specific, additional port adapter limitations for the Cisco 7200 series, see the "Hardware, Software, and Compliance Prerequisites" section on page 9.)

Using the show diagbus Command to Verify ESA Installation

Use the show diagbus command to determine if your installed ESA is recognized by your system.

Note      The slot values displayed by some commands (such as show diag and show cont cbus) are not relevant to any physical connection. You should disregard these slot values.

Following is sample output of the show diagbus command with an ESA installed on a VIP2-40:

Router# show diag
Slot 0:
Physical slot 0, ~physical slot 0xF, logical slot 0, CBus 1
Microcode Status 0x4
Master Enable, LED, WCS Loaded
Board is analyzed
Pending I/O Status: Console I/O, Debug I/O
EEPROM format version 1
C5IP controler, HW rev 1.0, board revision A0
Serial number: 00000001 Part number: 00-0000-01
Test history: 0x00 RMA number: 00-00-00
Flags: cisco 7000 board; 7500 compatible
(display text omitted]
PA Bay 1 Information:
Encryption SA
EEPROM format version 1
HW rev 1.0, Board revision UNKNOWN
Serial number: 00000444 Part number: 73-1557-07

Essential Encryption/Authentication Configuration Tasks

To enable your RSM/VIP2 to establish and conduct encrypted communication sessions and to authenticate peer routers, you must perform the following essential configuration tasks on all participating peer routers:

1. Generate DSS Public/Private Keys

2. Exchange DSS Public Keys

3. Enable DES Encryption Algorithms

4. Define Crypto Maps and Assign Them to Interfaces

Task 1—Generate DSS Public/Private Keys: you must perform task 1 one time only for each crypto engine of the router that you plan to use. (For a description of crypto engines, see "Cisco IOS Crypto Engine" section, "VIP2 Crypto Engine" section, and the "Data Encryption Service Adapter Crypto Engine" section.) The DSS key pair generated in task 1 will be used with every peer encrypting router to which you connect.

Task 2—Exchange DSS Public Keys: task 2 must be accomplished for each peer encrypting router that your router will connect to for encrypted sessions. If the network contains several peer encrypting routers that you will be using for encrypted communication, you will 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 need to exchange DSS keys with the new router to enable encryption to occur with that new router.

Task 2 involves making a phone call to the administrator of the peer encrypting router. You need to be in voice contact with the other administrator during task 2 to voice-authenticate the source of exchanged DSS public keys. It is likely that you will confer with the peer router administrator prior to task 2, to plan your encryption strategy. When you discuss this strategy, you need to decide what DES algorithm both your routers will be using, because you must both configure the same DES algorithm if encryption is to work.

Task 3—Enable DES Encryption Algorithms: perform task 3 at any time prior to encrypted communication. You might choose to perform this step in conjunction with (or even before) task 2; however, we recommend that you enable DES encryption algorithms before performing task 4.

Task 4—Define Crypto Maps and Assign them to Interfaces: task 4 is typically performed last. You must complete task 4 to allow specific router interfaces to perform encryption/authentication.

These four tasks are described in the following sections.

Generate DSS Public/Private Keys

You must generate DSS keys so that peer routers can authenticate each other before each encrypted session. You must generate DSS keys for each crypto engine that governs ports you will use to provide encryption/authentication services. To generate DSS keys for a crypto engine, perform at least the first of the following global configuration tasks:

Task Command

Generate DSS public and private keys.

crypto gen-signature-keys key-name [slot]

View your DSS public key (private key not viewable).

show crypto mypubkey [slot]

Save DSS keys to private NVRAM (only for Cisco IOS crypto engines).

copy running-config startup-config

Note      You must enter the copy running-config startup-config (previously write memory) command to save Cisco IOS crypto engine DSS keys to a private portion of NVRAM. DSS keys are not saved with your configuration when you enter a copy running-config rcp or copy running-config tftp (previously write network) command. If you are using an ESA, DSS keys generated for the ESA crypto engine are automatically saved to the tamper-resistant memory of the ESA upon DSS key generation. You will be prompted to create a password the first time you generate DSS keys for the ESA crypto engine. If you ever need to regenerate DSS keys for the ESA, you will be required to use this same password to complete the DSS key regeneration.

Exchange DSS Public Keys

You must exchange DSS public keys with all participating peer routers. This will allow peer routers to authenticate each other at the start of encrypted communication sessions.

You must exchange the DSS public keys of each crypto engine that you will be using.

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 10 on page 26):

Step 1   You and the other administrator decide which of you will be called PASSIVE, and which will be called ACTIVE.

Phone the other person to verbally assign the PASSIVE and ACTIVE roles. You will remain on the phone with this person until you complete all the steps in this list.

Step 2   PASSIVE enables a DSS exchange connection.

The person who is assigned PASSIVE should enable DSS exchange connection by entering the crypto key-exchange passive [TCP-port] command.

Step 3   ACTIVE creates a DSS exchange connection and sends a DSS public key.

The person who is assigned ACTIVE should initiate connection and send DSS public key by entering the crypto key-exchange ip-address key-name [TCP-port] command.

Step 4   You both observe the serial number and fingerprint of ACTIVE's DSS public key. The DSS key's serial number and fingerprint are numeric values that will be displayed on both screens at this time.

Step 5   You both read to each other the DSS key serial number and fingerprint displayed on your screens. The two numbers on both screens should be identical. ACTIVE asks PASSIVE to accept the DSS key. If the numbers match, PASSIVE should agree to accept ACTIVE's DSS key.

Step 6   PASSIVE sends ACTIVE a DSS public key.

PASSIVE's screen will display a prompt to send a DSS public key in return. PASSIVE should press Return to continue. PASSIVE will be prompted to confirm a public key name. When PASSIVE accepts a name by pressing Return, the DSS public key will be sent to ACTIVE.

Step 7   PASSIVE's DSS serial number and fingerprint display on both screens.

Step 8   As before, you both verbally verify that PASSIVE's DSS serial number and fingerprint match on both screens.

Step 9   ACTIVE agrees to accept PASSIVE's DSS public key.

DSS public keys have been exchanged, so both of you can now hang up the phone.

Note      The previous nine steps (illustrated in Figure 10) must be accomplished between your router and a peer router, for every peer router with which you will conduct encrypted sessions.


Figure 10   Exchange DSS Public Keys


Enable DES Encryption Algorithms

Cisco routers use 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.

Cisco (and the ESA) 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 will require you to use one or another type of DES.

Note      If you are running an exportable image, you can only enable and use 40-bit variations of DES. You cannot enable or use the basic DES algorithms, which are not available with exportable images.

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 nonexportable image, the DES default algorithm will be 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 nonexportable, you can enter the show crypto algorithms command to determine which DES algorithms are currently enabled.

To globally enable one or more DES algorithms, perform one or more of the following global configuration tasks:

Task Command

Enable DES with 8-bit or 64-bit CFB.

crypto algorithm des [cfb-8 | cfb-64]

Enable 40-bit DES with 8-bit or 64-bit CFB.

crypto algorithm 40-bit-des [cfb-8 | cfb-64]

View all enabled DES algorigthms.

show crypto algorithms

Define Crypto Maps and Assign Them to Interfaces

The purpose of this task is to tell your router which IP packets to encrypt or decrypt, and also which DES encryption algorithm to use when encrypting/decrypting the packets.

There are three steps required to complete this task:

Step 1   Set Up Encryption Access Lists

Step 2   Define Crypto Maps

Step 3   Apply Crypto Maps to Interfaces

Set Up Encryption Access Lists

Encryption access lists define which IP packets will be encrypted and which IP packets will not be encrypted.

To set up encryption access lists for IP packet encryption, perform the following global configuration task:

Task Command

Enable or disable encryption for a network.

access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [log]

Entering the permit keyword will cause all traffic that is passed between the specified source and destination addresses to be encrypted/decrypted by peer routers. Entering the deny keyword prevents that traffic from being encrypted/decrypted by peer routers.

When you are creating encryption access lists, we recommend that you do not use the any keyword to specify source or destination addresses. Entering the any keyword could cause extreme problems if a packet enters your router and is destined for a router that is not configured for encryption/authentication. This would cause your router to attempt to set up an encryption session with a nonencrypting router.

If you enter the show extended IP access-lists command, the router will show all extended IP access lists that have been defined, including those that are used for traffic filtering purposes as well as those that are used for encryption. The output of the show command does not differentiate between the two uses of the extended access lists.

Define Crypto Maps

Crypto maps are used to specify which DES encryption algorithm(s) will be used 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/authentication services. You must define one crypto map for each interface that will send encrypted data to a peer-encrypting router.

To define a crypto map, perform the following tasks. Perform the first task in global configuration mode; perform the other tasks in crypto map configuration mode.

Task Command

Name the crypto map and enter the crypto map configuration mode.

crypto map map-name [seq-no]

Specify the remote peer router's name.

set peer key-name

Specify the encryption access list.

match address access-list

Specify the DES encryption algorithm to be used.

set algorithm des [cfb-8 | cfb-64]

or

set algorithm 40-bit-des [cfb-8 | cfb-64]

Note      If you are running an exportable image, you can only specify 40-bit variations of DES. You cannot enable or use the basic DES algorithms, which are not available with exportable images.

Apply Crypto Maps to Interfaces

This step applies the crypto maps to an interface. You must apply exactly one crypto map to each interface 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, perform this interface configuration task:

Task Command

Apply a crypto map to an interface.

crypto map map-name

Optional Encryption/Authentication Configuration Tasks

The following optional tasks are described below:

Define Time Duration of Encrypted Sessions

The default time duration of an encrypted session is 30 minutes. After the default time duration expires, you must renegotiate an encrypted session if encrypted communication is to continue. You can change this default to extend or decrease the time of encrypted sessions.

To change the time duration of encrypted sessions, perform at least the first of the following global configuration tasks:

Task Command

Define the maximum time duration of encrypted sessions.

crypto key-timeout minutes

View the defined time duration of encrypted sessions.

show crypto key-timeout

Pregenerate 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 can choose to pregenerate DH numbers.

To pregenerate DH numbers, perform this global configuration task:

Task Command

Pregenerate DH numbers.

crypto pregen-dh-pairs number [slot]

Remove all DSS Keys

If you choose to stop using encryption on a router, you can delete its public/private DSS key pair(s).

DSS keys cannot be recovered after they have been removed. Use this function only after careful consideration.

To remove your DSS public/private keys (for all crypto engines) from your router, perform this global configuration task:

Task command

Remove DSS keys from your router.

crypto zeroize

Testing and Troubleshooting Encryption/Authentication

This section discusses how you can verify your configuration and the correct operation of encryption/authentication. This section also discusses diagnosing connection problems.

You should complete all the essential configuration tasks (as described in the "Essential Encryption/Authentication Configuration Tasks" section) before trying to test or troubleshoot your encryption configuration.

Test the Encryption/Authentication Configuration

If you want to test the packet encryption setup between peers, you can manually attempt to establish a session by specifying the IP address of a local host and a remote host that have been specified in an encryption access list.

To test the encryption setup, perform these tasks in privileged EXEC mode:

Task Command

Set up a test encryption session.

test crypto initiate-session -IP-addr dst-IP-addr map-name seq-num

View the connection status.

show crypto connections

An example at the end of this configuration note explains how to interpret the show crypto connections command output.

Diagnose Connection Problems

If you need to verify the state of a connection, perform these tasks in privileged EXEC mode:

Task Command

Check status of connection setup.

show crypto connections

Check status of a crypto map.

show crypto map

Check that connection is established and that packets are being encrypted.

show crypto crypto-engine connections active

Debug commands are also available to assist in problem-solving. These commands are documented in the Debug Command Reference publication.

Encryption/Authentication Configuration Examples

The following sections provide examples of configuring and testing your router for network data encryption with router authentication:

Generate DSS Public/Private Keys

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-40 in chassis slot 2.

Apricot
Apricot(config)# crypto gen-signature-keys Apricot
Generating DSS keys .... [OK]
Apricot(config)#
Banana
Banana(config)# crypto gen-signature-keys BananaIOS 4
Generating DSS keys .... [OK]
Banana(config)# crypto gen-signature-keys 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 the preceding example is a new password that you create when you generate DSS keys for an ESA crypto engine for the first time. If you generate DSS keys a second time for the same ESA crypto engine, you must use the same password to complete the key regeneration.

Exchange DSS Public Keys

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 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 described in this section:

Banana (PASSIVE)
Banana(config)# crypto key-exchange 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 (ACTIVE)
Apricot(config)# crypto key-exchange 192.168.114.68 Apricot
Public key for Apricot:
Serial Number 01461300
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:

Banana (PASSIVE)
Public key for Apricot:
Serial Number 01461300
Fingerprint 0F1D 373F 2FC1 872C D5D7
Add this public key to the configuration? [yes/no]: y

Now you both must verbally verify that your 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

You both observe Banana's serial number and fingerprint on your screens. Again, you verbally verify that the two screens show the same numbers.

Apricot (ACTIVE):
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 11 shows the two complete screens of the two routers. The steps are numbered on the figure to show the sequence of the entire exchange.


Figure 11   DSS Public Key Exchange


Enable DES Encryption Algorithms

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.

Apricot
crypto algorithm des cfb-8
crypto algorithm 40-bit-des cfb-8
Banana
crypto algorithm des cfb-8
crypto algorithm des cfb-64
crypto algorithm 40-bit-des cfb-8

Set Up Encryption Access Lists, Define Crypto Maps, and Assign Crypto Maps to Interfaces

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 communicates with a research coordinator at headquarters. Company-confidential information is exchanged by IP traffic that consists only of TCP data. Figure 12 shows the network topology.


Figure 12   Example 1 Network Topology


In the first example, Apricot is a Cisco 2500 series router, and Banana is a Cisco 7500 series router with an ESA/VIP2-40 in chassis slot 4.

Apricot
Apricot(config)# access-list 101 permit tcp 192.168.3.0 255.255.255.240 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
Banana(config)# access-list 110 permit tcp host 192.168.15.6 192.168.3.0 255.255.255.240
Banana(config)# crypto map Rh 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 s4/0/2
Banana(config-if)# crypto map Rh
Banana(config-if)# exit
Banana(config)#

Because Banana sets two DES algorithms for crypto map Rh, Banana could use either algorithm with traffic on the S4/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 this 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 13 shows the network topology used in this example.


Figure 13   Example 2 Network Topology


Apricot is a Cisco 2500 series router and connects to the Internet through port S1. Both Banana and Cantaloupe are Cisco 7500 series routers with ESAs. Banana connects to the Internet using the ESA-governed VIP2-40 interface S4/1/2. Cantaloupe is already using every VIP2-40 port (governed by the ESA) to connect to several off-site financial services, and so 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 the seq-no argument with the crypto map command. By using seq-no values of 10 and 20, Apricot creates a single crypto map 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 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 maps.

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 255.255.255.240 192.168.204.0 255.255.255.0
Apricot(config)# access-list 105 permit udp 192.168.3.0 255.255.255.240 192.168.204.0 255.255.255.0
Apricot(config)# access-list 106 permit tcp 192.168.3.0 255.255.255.240 192.168.15.0 255.255.255.0
Apricot(config)# access-list 106 permit udp 192.168.3.0 255.255.255.240 192.168.15.0 255.255.255.0
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
Banana
Banana(config)# access-list 110 permit tcp 192.168.204.0 255.255.255.0 192.168.3.0 255.255.255.240
Banana(config)# access-list 110 permit udp 192.168.204.0 255.255.255.0 192.168.3.0 255.255.255.240
Banana(config)# access-list 120 permit tcp 192.168.204.0 255.255.255.0 192.168.15.0 255.255.255.0
Banana(config)# access-list 120 permit udp 192.168.204.0 255.255.255.0 192.168.15.0 255.255.255.0
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 s4/1/2
Banana(config-if)# crypto map USA
Banana(config-if)# exit
Cantaloupe
Cantaloupe(config)# access-list 101 permit tcp 192.168.15.0 255.255.255.0 192.168.3.0 255.255.255.240
Cantaloupe(config)# access-list 101 permit udp 192.168.15.0 255.255.255.0 192.168.3.0 255.255.255.240
Cantaloupe(config)# access-list 102 permit tcp 192.168.15.0 255.255.255.0 192.168.204.0 255.255.255.0
Cantaloupe(config)# access-list 102 permit udp 192.168.15.0 255.255.255.0 192.168.204.0 255.255.255.0
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

The previous configurations will result in DES encryption algorithms being applied to encrypted IP traffic as shown in Figure 14.


Figure 14   Example 2 DES Encryption Algorithms


Test the Encryption Connection

This section describes how to set up and verify a test encryption session.

Assume the same network topology and configuration as in the previous example and shown in Figure 13 on page 35.

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 connections command.

Apricot# show crypto connections
Pending Connection Table
PE UPE Timestamp Conn_id
192.168.3.10 192.168.204.100 730944064 -1
Connection Table
PE UPE Conn_id New_id Alg Time
192.168.3.10 192.168.204.100 -1 1 0 0
flags:USED_NODE PEND_CONN

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.

Step 4   At the Connection Table entry, note the Conn_id and New_id values. In this case, Conn_id equals -1, 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 moment for the test connection to set up and then reissues the show crypto connections command.

Apricot# show crypto connections
Pending Connection Table
PE UPE Timestamp Conn_id
192.168.3.10 192.168.204.100 730944064 -1
Connection Table
PE UPE Conn_id New_id Alg Time
192.168.3.10 192.168.204.100 1 1 0 0
flags:USED_NODE PEND_CONN

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 the test connection has been successfully established because the Conn_id value changed to match the New_id value of Step 4. (Also, New_id has been reset to 0 at this point.)

The show crypto connections command is explained in greater detail in the chapter "Network Data Encryption and Router Authentication Commands" in the Security Command Reference. It includes a description of how connection ids are assigned during and following connection setup.

Related Documentation

Refer to the following configuration and command reference publications for your configuration:

For your Catalyst VIP2 port adapters, use this configuration note with the Route Switch Module Catalyst VIP2-15 and VIP2-40 Installation and Configuration Note (Document Number 78-4780-01), which shipped with your Catalyst VIP2.

Cisco Connection Online

Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.

Note      If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.

Documentation CD-ROM

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.