Полезная информация

cc/td/doc/product/software/ios112/112cg_cr
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring Network Data Encryption with Router Authentication

Configuring Network Data Encryption with Router Authentication

This chapter describes how to configure your router for network data encryption with router authentication.

Network data encryption and router authentication together provide a means to 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 an economical way to replace leased line services.

Data that traverses unsecured network lines is open to many types of attacks. Data can be read, altered, or forged by anybody that 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. This chapter describes how to configure your router for network data encryption with router authentication, and includes the following sections:

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

Cisco's Implementation of 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 will be 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.

Typically, when an IP packet is initially generated at a host, it is unencrypted ("cleartext"). 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 cleartext.

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 will be 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 standard 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 process.

Enabling Router Authentication (DSS Key Exchange)

Before encrypted communication or router authentication can occur between peer routers, Digital Signature Standard (DSS) keys (public DSS keys and private DSS keys) must be generated. Also, the DSS public keys must be shared and verified (see Figure 8). The process of generating, sharing, and verifying DSS keys occurs only once, and these DSS keys will be used afterwards each time an encrypted session occurs. 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. If you have a Cisco 7500 series 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 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. (The verbal verification is sometimes referred to as "voice authentication.")


Figure 8:
Exchanging DSS Keys (Overview)

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

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 that is 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 is the key that will be used to encrypt data during this 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 9:
Establishing an Encrypted Session

Encrypting Data During a Communication Session

Now that 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 10.)

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 10:
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.

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

The Crypto Engine

Encryption and authentication are provided by a software service called a crypto engine. To use a crypto engine, you must first configure the crypto engine; then you can configure any port governed by that crypto engine to perform encryption and authentication.

The Cisco IOS Crypto Engine

A crypto engine resides in your router's Cisco IOS software, and provides encryption/authentication services for all router ports that you specify during configuration. (The crypto engine "governs" encryption/authentication for all router ports.) All Cisco routers have only one crypto engine (the Cisco IOS crypto engine) to govern all ports, except for Cisco 7500 series routers. Cisco 7500 series routers can have more than one crypto engine.

Cisco 7500 series routers have a Cisco IOS crypto engine that resides in the Route Switch Processor (RSP), but can also have additional crypto engines as described in the next sections.

The VIP2 Crypto Engine

Cisco 7500 series routers support use of the second-generation Versatile Interface Processor (VIP2). The VIP2 has its own crypto engine which governs the ports on the VIP2. So, if you have a VIP2 installed in your router, the VIP2 crypto engine will govern the VIP2 ports, and the Cisco IOS crypto engine will govern all remaining router ports.

The Encryption Service Adapter Crypto Engine

If you have a Cisco 7500 series router with an Encryption Service Adapter (ESA), your router will have an additional crypto engine associated with the ESA. The ESA and an adjoining port adapter are housed in a VIP2 board, and the ESA crypto engine provides encryption/authentication services only for ports on the adjoining VIP2 port adapter. In this case, the ESA crypto engine---not the VIP2 crypto engine---governs the VIP2 ports. The Cisco IOS crypto engine will provide encryption/authentication for all remaining ports of your router. In other words, the ESA crypto engine governs the adjoining port adapter ports, and the Cisco  IOS crypto engine governs all remaining ports. (However, during configuration you must specify which ports you want to participate in encryption/authentication.)

Configuring the Crypto Engine

You need to accomplish 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: generate DSS keys and exchange DSS keys. These two tasks are described later in this chapter, in the section "Essential Encryption/Authentication Configuration Tasks."

If you have a Cisco router other than a Cisco 7500 series router, your router will only have one crypto engine residing in the Cisco IOS software. You will need to configure only this one crypto engine.

If you have a Cisco 7500 series router with one or more VIP2 boards or ESA cards, your router will have multiple crypto engines. When you configure these crypto engines, you must identify them by a chassis slot number. The Cisco IOS crypto engine is identified by the chassis slot number of the Route Switch Processor (RSP). The VIP2 or ESA crypto engine is identified by the chassis slot number of the VIP2 board.

After you configure a crypto engine, you can configure any port governed by that crypto engine to perform encryption/authentication.

Implementation Issues

Please note the following 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 chapter) might also help by speeding up encryption session connection setup times.

Other Sources of Information

The following reading material can provide additional background information about authentication and data encryption, including theory, standards, and legal requirements. (Complete references for these materials can be found in the "References and Recommended Readings" appendix in the Configuration Fundamentals Configuration Guide.)

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

Essential Encryption/Authentication Configuration Tasks

To enable your Cisco router to establish and conduct encrypted communication sessions and to authenticate peer routers, the following essential configuration tasks must be performed 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

When to perform each task:

You must perform task 1 (Generate DSS Public/Private Keys) one time only for each crypto engine of your router that you plan to use. (For a description of crypto engines, read "The Crypto Engine" section, found earlier in this chapter.) The DSS key pair generated in task 1 will be used for every encrypted session connection (regardless of the peer encrypting router that you connect to).

You must accomplish task 2 (Exchange DSS Public Keys) for each peer encrypting router that your router will connect to for encrypted sessions. If your 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 then 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 (among other things) what DES algorithm both your routers will be using, because you must both configure the same DES algorithm for encryption to work.

Perform task 3 (Enable DES Encryption Algorithms) at any time before attempting encrypted communication. You might select to perform this step in conjunction with (or even before) task 2. However, it is recommended that you enable DES encryption algorithms before performing task 4.

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

These four essential 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 the 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. (Complete this task only for Cisco  IOS crypto engines.)

copy running-config startup-config


Note 
You must perform 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 perform a copy running-config rcp or copy running-config tftp (previously write network) command.

If you are using an ESA, any DSS keys generated for the ESA crypto engine are automatically saved to the tamper resistant memory of the ESA during the DSS key generation process.


Note If you are using an ESA, 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 11):

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

Step 2 PASSIVE enables a DSS exchange connection.

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

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 matched, PASSIVE should agree to accept ACTIVE's DSS key.

Step 6 PASSIVE sends ACTIVE a DSS public key.

Step 7 PASSIVE's DSS serial number and Fingerprint display on both of your screens.

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

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

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


Figure 11: Exchange DSS Public Keys

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

Cisco 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 which 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 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 perform the show crypto algorithms command (shown in the table that follows) 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 algorithms.

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 actually 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 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, but are not used in the same way that IP access lists are typically used. (A more typical use of access lists is described in an earlier chapter, "Configuring Traffic Filters.")

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

Specify conditions to determine which IP packets will be encrypted. (Enable or disable encryption for a specified 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]

or

ip access-list extended name
Follow with permit and deny statements as appropriate.

Using the permit keyword will cause all 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.

See the Security Command Reference for complete details about the extended ip access list commands.

The encryption access list you define will be applied to an interface as an outbound encryption access list after you define a crypto map and apply the crypto map to the interface. (These two tasks are described in the next sections.)

Caution When you create encryption access lists, we recommend against using the any keyword to specify source or destination addresses. Using 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.

Note If you view your router's access lists by using a command such as show ip access-lists, all extended IP access lists will be shown in the command output. This includes extended IP access lists that are used for traffic filtering purposes as well as those that are used for encryption. The show command output 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 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/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. The first task is performed in global configuration mode; the other tasks are performed 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.

set peer key-name

Specify the encryption access list.

match address [access-list-number | name]

Specify the DES encryption algorithm to be used. (More than one algorithm can be specified.)

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 puts into effect the crypto maps just defined. 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 the following 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 in the next sections:

Define 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 limit 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 maximum time duration of encrypted sessions.

crypto key-timeout minutes

View 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 may choose to pregenerate DH numbers. It is usually necessary to pregenerate only one or two DH numbers.

To pregenerate DH numbers, perform the following global configuration task:
Task Command

Pregenerate DH numbers.

crypto pregen-dh-pairs count [slot]

Remove all DSS Keys

If you choose to stop using encryption on a router, completely or for a specific crypto engine only, you may delete the public/private DSS key pair(s) for your router's crypto engine(s).

Caution 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 a specified crypto engine) from your router, perform the following global configuration task:
Task Command

Remove DSS keys from a crypto engine.

crypto zeroize [slot]

Testing and Troubleshooting Encryption/Authentication

This section discusses how to 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 earlier in the section "Essential Encryption/Authentication Configuration Tasks") before trying to test or troubleshoot your encryption configuration.

Test the Encryption/Authentication Configuration

If you want to test the encryption setup between peer routers, you can manually attempt to establish a session by specifying 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, perform the following tasks in privileged EXEC mode:
Task Command

Set up a test encryption session.

test crypto initiate-session src-ip-addr dst-ip-addr map-name seq-num

View the connection status.

show crypto connections

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

Diagnose Connection Problems

If you need to verify the state of a connection, you can perform the following tasks in privileged EXEC mode:
Task Command

Check status of all encryption connections.

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 engine connections active

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

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

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

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
   Fingerprint   0F1D 373F 2FC1 872C D5D7
Wait for peer to send a key[confirm]<Return>
Waiting ....

After ACTIVE sends a DSS public key, the key's serial number and Fingerprint display on both terminals, as shown previously and as follows:

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
 
Banana(config)#

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 12 shows complete screens of the two routers. The steps are numbered on the figure to show the sequence of the entire exchange.


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


Figure 13: 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.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 0.0.0.15
Banana(config)# crypto map Rsrch 10
Banana(config-crypto-map)# set peer Apricot
Banana(config-crypto-map)# set algorithm des cfb-8
Banana(config-crypto-map)# set algorithm des cfb-64
Banana(config-crypto-map)# match address 110
Banana(config-crypto-map)# exit
Banana(config)# interface s3/0/2
Banana(config-if)# crypto map Rsrch
Banana(config-if)# exit
Banana(config)#

Because Banana set two DES algorithms for crypto map Rsrch, Banana could use either algorithm with traffic on the S3/0/2 interface. However, because Apricot only set one DES algorithm (CFB-8 DES) for the crypto map Research, that is the only DES algorithm which 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 14 shows the network topology used in this example.


Figure 14: 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 ESA cards. Banana connects to the Internet using the ESA-governed VIP2 interface S2/1/2. Cantaloupe is already using every VIP2 port (governed by the ESA card) to connect to several offsite 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 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 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 0.0.0.15 192.168.204.0 0.0.0.255

    Apricot(config)# access-list 105 permit udp 192.168.3.0 0.0.0.15 192.168.204.0 0.0.0.255

    Apricot(config)# access-list 106 permit tcp 192.168.3.0 0.0.0.15 192.168.15.0 0.0.0.255

    Apricot(config)# access-list 106 permit udp 192.168.3.0 0.0.0.15 192.168.15.0 0.0.0.255

    Apricot(config)# crypto map TXandNY 10

    Apricot(config-crypto-map)# set peer BananaESA.TXbranch

    Apricot(config-crypto-map)# set algorithm 40-bit-des cfb-8

    Apricot(config-crypto-map)# match address 105

    Apricot(config-crypto-map)# exit

    Apricot(config)# crypto map TXandNY 20

    Apricot(config-crypto-map)# set peer CantaloupeIOS.NY

    Apricot(config-crypto-map)# set algorithm 40-bit-des cfb-64

    Apricot(config-crypto-map)# match address 106

    Apricot(config-crypto-map)# exit

    Apricot(config)# interface s1

    Apricot(config-if)# crypto map TXandNY

    Apricot(config-if)# exit

    Apricot(config)#

Banana

    Banana(config)# access-list 110 permit tcp 192.168.204.0 0.0.0.255 192.168.3.0 0.0.0.15

    Banana(config)# access-list 110 permit udp 192.168.204.0 0.0.0.255 192.168.3.0 0.0.0.15

    Banana(config)# access-list 120 permit tcp 192.168.204.0 0.0.0.255 192.168.15.0 0.0.0.255

    Banana(config)# access-list 120 permit udp 192.168.204.0 0.0.0.255 192.168.15.0 0.0.0.255

    Banana(config)# crypto map USA 10

    Banana(config-crypto-map)# set peer Apricot.TokyoBranch

    Banana(config-crypto-map)# set algorithm 40-bit-des cfb-8

    Banana(config-crypto-map)# match address 110

    Banana(config-crypto-map)# exit

    Banana(config)# crypto map USA 20

    Banana(config-crypto-map)# set peer CantaloupeIOS.NY

    Banana(config-crypto-map)# set algorithm des cfb-64

    Banana(config-crypto-map)# match address 120

    Banana(config-crypto-map)# exit

    Banana(config)# interface s2/1/2

    Banana(config-if)# crypto map USA

    Banana(config-if)# exit

    Banana(config)#

Cantaloupe

    Cantaloupe(config)# access-list 101 permit tcp 192.168.15.0 0.0.0.255 192.168.3.0 0.0.0.15

    Cantaloupe(config)# access-list 101 permit udp 192.168.15.0 0.0.0.255 192.168.3.0 0.0.0.15

    Cantaloupe(config)# access-list 102 permit tcp 192.168.15.0 0.0.0.255 192.168.204.0 0.0.0.255

    Cantaloupe(config)# access-list 102 permit udp 192.168.15.0 0.0.0.255 192.168.204.0 0.0.0.255

    Cantaloupe(config)# crypto map satellites 10

    Cantaloupe(config-crypto-map)# set peer Apricot.TokyoBranch

    Cantaloupe(config-crypto-map)# set algorithm 40-bit-des cfb-64

    Cantaloupe(config-crypto-map)# match address 101

    Cantaloupe(config-crypto-map)# exit

    Cantaloupe(config)# crypto map satellites 20

    Cantaloupe(config-crypto-map)# set peer BananaESA.TXbranch

    Cantaloupe(config-crypto-map)# set algorithm des cfb-64

    Cantaloupe(config-crypto-map)# match address 102

    Cantaloupe(config-crypto-map)# exit

    Cantaloupe(config)# interface s3/1

    Cantaloupe(config-if)# crypto map satellites

    Cantaloupe(config-if)# exit

    Cantaloupe(config)#

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


Figure 15: Example 2 DES Encryption Algorithms

Test the Encryption Connection

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

In this example, router Apricot sets up a test encryption session with router Banana, and then views the connection status to verify a successful encrypted session connection.

Step 1 Router Apricot sets up a test encryption connection with router Banana.

Apricot# test crypto initiate-session 192.168.3.12 192.168.204.110 
BananaESA.TXbranch 10
Sending CIM to: 192.168.204.110 from: 192.168.3.12.
Connection id: -1

Notice the Connection id value is -1. A negative value indicates that the connection is being set up.

Step 2 Router Apricot issues the show crypto 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: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, so finding the right Connection Table entry is easy.

Step 4 At the Connection Table entry, note the Conn_id and New_id values. In this case, Conn_id equals -1 (as in the Pending Connection Table), and New_id equals 1. The New_id value of 1 will be assigned to the test connection when setup is complete. (Positive numbers are assigned to established, active connections.)

Step 5 Apricot waits a few seconds for the test connection to establish, and then reissues the show crypto connections command.

Apricot# show crypto connections
Connection Table
PE              UPE             Conn_id New_id  Alg     Time
192.168.3.10    192.168.204.100 1       0       0       0
                flags:TIME_KEYS

Again, look for the Connection Table entry with the same PE and UPE addresses as shown before. In this entry, notice that the Conn_id value has changed to 1. This indicates that our test connection has been successfully established, because the Conn_id value has changed to match the New_id value of Step 4. Also, New_id has been reset to 0 at this point, indicating that there are no new connections currently being set up.

In the command output of Step 5, there is no longer a Pending Connection Table being displayed, which indicates that there are currently no pending connections. This is also a good clue that the test connection was successfully established.

The show crypto connections command is explained in greater detail in the chapter "Network Data Encryption and Router Authentication Commands" in the Security Command Reference. There you can find a description of how connection id's are assigned during and following connection setup.


hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1998 © Cisco Systems Inc.